The best interface is a good default
Settings pages are where hard decisions go to be avoided. Four myths about options, and the quiet kindness of choosing well on a stranger's behalf.
Somewhere in every product meeting, a hard decision gets dodged with four soft words: we’ll make it configurable.
It feels like diplomacy. Both camps get their way, the roadmap moves on, and the disagreement gets quietly shipped to the settings page, where users will supposedly resolve it themselves. The feature ships, the toggle count ticks up, and the actual question, what this thing should do, never gets answered.
They won’t. A few myths keep this ritual alive, and each is worth retiring.
Myth: people customize the things they care about
Microwave clocks blinked 12:00 in kitchens for thirty years. Owners cared about the time; they just cared more about lunch. Software works the same way. People arrive with a job in mind, and the settings page is never the job, so the overwhelming majority will live their entire lives inside your product exactly as it stood on first launch. Not because they’re lazy. Because configuring software is homework nobody assigned, and your defaults are, functionally, the product.
The few who do venture into settings mostly go once, flip the one thing that was bothering them, and never return. Even tinkerers tinker briefly. What you shipped as the default is what nearly everyone will describe when they tell a friend what your product is like.
Myth: options are generosity
Handing someone a choice feels like a gift. Often it’s a transfer of labor. Every toggle is a decision the team was paid to make and didn’t, forwarded to someone with less context, less time, and no interest in the tradeoff. Thirty settings don’t say “we respect your preferences.” They say “we couldn’t agree, so you figure it out.”
There’s a place for genuine preferences: text size, notification hours, anything where people truly and durably differ. That list is shorter than any settings page we’ve ever scrolled.
Myth: the default is neutral
No default is neutral. Whatever the software does when nobody intervenes is an argument about how it should be used, and it wins almost every time by sheer inertia. An entire decade of résumés arrived in the same typeface because a word processor picked it. Meetings run thirty or sixty minutes not because work comes in those sizes but because calendars pre-fill them.
Whoever sets the default sets the norm, quietly, at scale, without a single user feeling like a decision happened.
Pretending otherwise doesn’t remove the argument. It just means the argument was made carelessly.
Myth: the power users are the audience
Power users write the forum posts, file the feature requests, and fill every feedback channel asking for more control. Listening only to them is like designing a city around the ten people who attend zoning meetings. The silent majority never posts and never toggles. They simply use what’s in front of them, and when it doesn’t work they don’t complain, they just drift to something that does and never tell you why. Build the settings page for the vocal few if you must, but build the defaults for everyone else, because everyone else is who’s actually there.
Strip the myths away and what remains is a responsibility that makes teams uncomfortable, which is probably why the toggle ritual survives.
Choosing a default means choosing on behalf of strangers. It means doing the research, having the argument, weighing the tradeoff, and then committing: no hedging, no advanced-settings escape hatch for your own indecision. That feels presumptuous to a certain temperament. We’d call it care. The same care a good host shows by setting the table before the guests arrive, instead of leaving the cutlery in a drawer with a note that says options.
None of this is guesswork, either. Watch what people actually do in the product, not what the loudest ones say they want. Pick the option that protects a beginner from harm over the one that saves an expert a click. When two choices are genuinely close, pick the quieter one; nobody ever churned because the notifications were too polite. And write the default down with its reasoning, so the next team changes it on purpose instead of by accident.
A good default is a decision made once, carefully, so a thousand strangers never have to make it badly at the worst possible moment. None of them will ever thank you, because none will ever know a decision was made. Design’s quietest kindnesses work like that.
Somewhere right now, a microwave is blinking 12:00. Your product doesn’t have to.
