Convention Over Configuration

Often used in a development context, the goal of convention over configuration is to decrease the number of decisions the programmer has to make and eliminate the complexity of having to configure all and each of the areas of application development. The immediate result is that you can create many more things in less time.

This pattern should always be applied to development decision, but can also be applied to UX in our applications. The need for an overly complex system of configuration is frequently a signal of a fragile and untenable workflow. Every configuration option we add to an application multiplies it’s complexity, which means the application is harder to use, harder to develop, and less friendly to users.

Requests for configuration can be a proxy for trying to support a fragile workflow. Rather than enabling bad habits and incurring product debt, effort should be spent helping customers adopt best practices. Prefer choices that are well thought out and based on current best practices. Avoid unnecessary configuration. Avoid configuration to support fragile workflows.

Making features configurable is easy and lazy. It's a natural reaction to propose a big change to be configurable, as you worry it'll negatively affect certain users. However, by making a feature configurable, you've now created two problems.

Work on solutions that work for everyone, and that replace all previous solutions.

Sometimes configuration is inevitable or preferable. Our applications should work out of the box for the majority of our users. Your configuration must not make that experience worse and should always get out of the way of the user.

Encouraging behavior

Convention also implies that we're encouraging our users to do things in a certain way. This is demonstrated by how we prefer a module to use the default CSS defined by our design team. Allowing custom CSS to be applied to the module via a field that overrides default configuration allows the behavior of the application to get off of our pre-designed path. We still encourage not to use it, but with the option, it will almost always be used. Encouragement for a path with established and approved alternatives is not effective encouragement.

Encourage favorable behaviors by limiting configuration.

Deciding on configurations

Avoiding configurations is not always possible. When we have no choice, the secondary priority is to only allow the least acceptable amount of configuration as satisfies the desired functionality.