Three settings we deliberately don’t add
Every app accumulates settings the way a house accumulates clutter — slowly, invisibly, one well-meaning addition at a time. The result is a Settings screen no one reads and a product that means slightly different things to every user.
Each setting looks harmless on its own. It’s one switch, it defaults to off, nobody is forced to touch it. But every switch doubles the number of ways the app can behave, and someone has to test all of them, on every platform, in every language. For a small team shipping on iPhone, Android, Windows and the browser, that multiplication is the difference between a careful release and a hopeful one.
Three settings we’ve consistently refused to add, even when asked:
1. A choice between two onboarding flows
If we can’t decide which one is better, neither is good enough to ship.
The request usually comes from inside the team rather than from users: two people prefer two versions, and a setting looks like a diplomatic solution. It isn’t. A new user doesn’t know enough about the app to choose how they’d like to be introduced to it. So we keep working until one flow is clearly better, and we ship that one.
2. A toggle for the new design
Either the redesign is an improvement and the old version goes, or the redesign isn’t ready. A toggle is a way to avoid making the call — and it doubles our QA surface forever.
We understand why people ask. A redesign changes muscle memory, and that’s genuinely disruptive. Our answer is to make the transition gentler rather than optional: keep things in the same places where we can, explain what moved, and give the new version time before judging it. If the redesign is still worse for most people after that, the honest move is to fix it or roll it back — not to maintain two apps inside one.
3. A “reduce animations” option
iOS already has one, system-wide, that we honor. Adding a second one in our settings is duplication and a tacit admission that our default animations are annoying. Better to fix the animations.
The same goes for our other platforms. Android, Windows and the browsers each have their own system-level preference for reduced motion, and our job is to respect it rather than invent a parallel one. A person who has turned motion down once, for the whole device, shouldn’t have to do it again in every app they install.
What we do add
This isn’t a rule against settings. We add one when people genuinely need different behavior for reasons we can’t design around — units of measurement, the first day of the week, the keyboard layout someone is learning on. The question we ask is whether a setting reflects a real difference between people, or just a decision we haven’t made yet.
Where we’ve slipped
We haven’t always held the line. We’ve shipped settings that started as a quick answer to a single request and stayed long after anyone remembered why. Clearing those out later is harder than not adding them, because by then someone relies on each one.
Refusing settings is its own kind of work. It just doesn’t show up in any commit message.