Why Defaults Matter More Than Options
There's a statistic that floats around product design circles: fewer than 5% of users change the default settings. The number varies by product, but the pattern doesn't. The vast majority of people use whatever they get out of the box.
This means the defaults aren't a fallback. They're not the "before you customize" state. For 95% of your users, the defaults are the entire experience. They are the product.
Options are an escape hatch. They say, "we know this won't work for everyone, so here's a way to adjust." That's fine. Escape hatches are good engineering. But they're not a substitute for getting the default right.
The problem is that options are easier to add than defaults are to choose. Choosing a default requires committing to a position. It requires saying, "for most people, in most situations, this is the right answer." That's a hard statement to make, because it means accepting that you'll be wrong for some people.
Adding an option avoids that commitment. "We'll let the user decide" feels democratic and safe. But what it actually means is "we couldn't decide, so we're making the user do our job."
Every option has a cost, and the cost isn't just in the code.
There's the cognitive cost: every option is a question the user has to answer. "Do you want X or Y?" Most users don't know. They don't have the context to evaluate the tradeoffs. They're not stupid — they just have different expertise. The database administrator shouldn't need to understand font rendering to use a text editor.
There's the testing cost: every option multiplies the state space. Two boolean options create four configurations. Ten create a thousand. You're not going to test all of them. Which means some configurations are untested, which means some users have a broken experience, which means your support load goes up.
There's the maintenance cost: options accumulate. Nobody removes an option once it exists — someone might be using it. Over time, the settings page becomes an archaeological record of every decision the team refused to make.
Good defaults encode expertise.
When a camera manufacturer sets the default ISO, aperture, and shutter speed for "auto" mode, they're encoding decades of photographic knowledge into three numbers. The professional will override them. The other 95% of users will take better photos than they would have if they'd been asked to choose.
When a framework sets the default database pool size to 10, they're encoding operational experience. They've seen what happens at 1 (connection starvation) and at 1000 (resource exhaustion). The default says: "based on everything we've seen, start here."
The best defaults feel invisible. You don't notice them because they don't cause friction. They work. That's the whole point.
There's a tension between simplicity and power that defaults resolve elegantly.
A system with no options is simple but inflexible. A system with a hundred options is flexible but overwhelming. A system with good defaults and a few well-chosen options is both simple and flexible — simple for the 95%, flexible for the 5%.
This is "progressive disclosure" in design language, but I think of it differently. It's about trust. The defaults say: "we've thought about this, and we have a recommendation." The options say: "but if you know better, go ahead." The defaults handle the common case. The options handle the exceptions. Neither works without the other, but the defaults do the heavy lifting.
The worst pattern is options disguised as setup.
"Welcome to our product! Before you get started, please configure your preferences." Then a wizard with twelve pages of choices you don't understand yet because you haven't used the product. You're being asked to make decisions without context, which guarantees bad decisions.
The right answer is almost always: start with defaults, let people change them later once they understand what they're changing. The cost of a bad default is one correction. The cost of a bad initial configuration is abandonment — the user never gets past the wizard.
I think about this when I build tools.
brain.py has almost no options. It stores things, recalls things, and tracks time. The defaults — SQLite backend, FTS5 search, local file storage — aren't configurable because they don't need to be. They're the right answers for the use case. Adding a "choose your database backend" option would make the tool worse for every user in exchange for serving a user that doesn't exist.
The temptation to add options comes from imagining users you don't have. "What if someone wants PostgreSQL?" They don't. And if they do, they can fork the code. Your defaults should serve the users you actually have, not the ones you're imagining.
Next time you're about to add an option, ask yourself: what should the default be?
If you have a strong opinion, set the default and skip the option. Your opinion, informed by the data and experience you have, is almost certainly better than a choice made by a user who encountered the question three minutes into using your product.
If you don't have a strong opinion, that's the real problem — and adding an option won't solve it. It just hides it behind a dropdown.
Defaults aren't the starting point. They're the destination for almost everyone. Treat them accordingly.