Practice / The mechanism

Who carries the complexity

Every feature comes with some complexity, and somebody ends up holding it: the product team, the engineering team or the person using the software. The best products leave as little of it as possible with the person.

A minute a day#

In the mid-1980s, a computer scientist at Xerox PARC named Larry Tesler did a small piece of arithmetic. A million people each lose a minute a day to complexity an engineer could have removed in a week.

Those people are paying so one engineer doesn’t have to.

Complexity left unhandled settles with whoever has the least room to say no, which is usually the person with the least context and the least time.

Defaults are the experience#

Most people never change a default. In a Cornell study Jakob Nielsen wrote about, the top search result still drew 34% of clicks after researchers secretly swapped the order.

A new setting usually keeps the value it ships with, so the default deserves design time before any customization does.

Opinions over options#

A toggle is often a sign that the team couldn’t decide. It earns its place when people need both behaviors and neither is clearly right. Otherwise, the team can pick one.

Joel Spolsky wrote in 2000 that handing the user a choice the designer couldn’t make is a kind of arrogance. Linear, the project-tracking company, describes flexible software as letting everyone invent their own workflow, which turns into chaos as a team grows.

Convention over configuration#

A product can often work out what it needs from what’s already there. The Ruby on Rails framework is built on that idea. Vercel applies it to deployment, reading a project’s shape with no config file.

For a new feature, the first question is what the system can infer from what the customer already has. An account with facilities, teams and staff already holds enough to produce a working default without asking anyone.

Existing state is sacred#

People have years invested in how their current setup works. Figma rebuilt Auto Layout with migration code that kept every existing document behaving as before. When Notion added teamspaces, every existing page moved into a General teamspace with its permissions intact.

The test for any rollout is what an existing customer sees the morning after it ships. Everything should work, filled in with their own data, as though the feature had always been there.

The vendor absorbs#

Stripe has shipped roughly 100 backward-incompatible API changes without forcing a single client to upgrade. Each account stays on the version of its first request, and compatibility layers translate between versions.

When a team says a feature needs an administrator to configure it first, that usually describes the path the team can see today. A path that absorbs the setup inside the product is usually there to be found, and it’s worth funding.

Safety policy says the same#

Australia’s eSafety Commissioner built the same idea into Safety by Design. Its first principle, service provider responsibility, says “the burden of safety should never fall solely upon the user.”

What it changes in the work#

Most of this comes down to one question a team can ask about every feature.

Ask who will hold each new piece of complexity: the team, or the person using the product
Spend design time on the default before the customization
Add a setting only when people need both behaviors and neither is clearly right
Work out what the product can infer from what the customer already has
Check what an existing customer sees the morning after a release

Back to the minute#

Each item on that list gives a minute back to every one of those people.