Skip to content
Back to the workshop

Defaults Are a Form of Respect

Every setting that does not need to exist should not exist

E
EugeneBuilding Cleo
4 min read

A configurable system is not the same as a flexible system. Every setting is a small tax on attention. The user has to read it, decide whether it applies to them, choose a value, and then live with the consequences of having chosen. Multiplied across a product, the cumulative cost is enormous.

The opposite of configuration is not rigidity. It is opinion. The right default is a stronger statement of what the product believes than any number of options would be.

Settings as failure modes

Most settings are a sign that the designer did not know what to recommend. A toggle on a feature usually means I could not decide whether it should be on. A choice between two options usually means I could not decide which one was better. Each undecided thing gets exported to the user as a configuration, and the framing tells me I am giving them flexibility. I am not. I am giving them my indecision.

The discipline I try to hold is to make the decision before I ship. Pick the default I believe is right. Stand behind it. Do not add a setting unless the right answer genuinely depends on the user's context, and then add only that setting, not a constellation of related ones.

What a strong default looks like

A strong default is one I am willing to defend without retreat. When a user asks why I chose it, I have a real answer that does not start with "well, you can change it in settings." I chose it because it is the best general-case behaviour for the kind of work the user is doing.

The notification settings page is a good test. Most products ship one with twenty toggles. I try to ship one with three or four. Email digest, frequency, occasional product updates. That is most of what I believe matters. The other seventeen toggles in other products exist because the company could not decide. My defaults are the decision.

When configuration is genuinely necessary

There are cases where the right answer truly depends on the user. The brand voice. The audience size. The publication cadence. The integrations connected. These are cases where no default could be correct, because the answer is contextual to the business.

For these, I surface configuration. But I surface it where the decision is being made, not in a settings menu. The brand voice lives inside the brand profile. The publication cadence lives inside the campaign builder. The integrations live inside the integrations panel. The user encounters the choice when it matters and not before.

The settings menu, in this product, is a small place. It contains the things that are genuinely about the user themselves. Account, billing, notifications, members. It does not contain dozens of toggles for product behaviour. Product behaviour is decided. The settings menu is for the user, not the product.

The compounding cost of options

Every option you add multiplies. A product with ten settings has ten configurations. A product with twenty settings has more than ten million possible configurations. You cannot test, support, or design for all of them. The combinatorial complexity grows faster than the number of settings, and most of the resulting configurations are versions of the product no one is actively curating.

This is why settings-heavy products feel inconsistent. Every user is using a slightly different product, and the product itself does not have a coherent identity, because there is no canonical experience.

I work hard to keep the canonical experience canonical. There is one Cleo. It looks the same for every user. It behaves the same way. The things that vary are the things that should vary, which are the user's data and the user's brand. Everything else is decided.

What the user gets in exchange

The user gets a product that has opinions. They can disagree with the opinions, and they can argue with me about them, and sometimes I will change my mind. But the product itself is not a configuration kit. It is a tool with a point of view.

People sometimes find this restrictive. Most people find it freeing. The cognitive load of using a configurable system is much higher than the cognitive load of using a system that has already made the small decisions for you. I try to make those decisions well, so the user can spend their attention on the work that actually requires it.

Every setting I did not ship is a setting the user does not have to think about. That is a form of respect.

E

Written by Eugene

Building Cleo, an AI marketing operating system. These posts cover the architecture decisions, technical challenges, and lessons learned along the way.

More from the workshop