The Default Settings Problem
The most important settings are the ones you never open.
Not because you decided on them. Because you didn’t. You installed the tool, clicked through setup, and started using it. Now six months later, you’re building things that were quietly shaped by someone else’s assumptions about what you’d want.
That’s the default settings problem. It’s not that defaults are bad — defaults are thoughtful, usually. It’s that they’re written for a median user, and you are not that user. The options you never changed are still making decisions. They’re just making them without you.
Where this shows up
It’s obvious in Notion, where the default properties on a new database — and the default sorts, and the default views — end up as permanent infrastructure because nobody went back to reconsider them. You start tracking clients in a table. Two years later you’ve got twelve properties, eight of which were auto-added, and you’re not sure which three you’re actually using.
It shows up in code. Framework defaults, boilerplate generator settings, ESLint configs copied from someone’s GitHub repo. The defaults were good for whoever wrote them. They might not be right for what you’re building.
But it’s most insidious in design. Default spacing, default type scale, default border radius. Most products look the way they look not because someone made those decisions — but because someone never unmade them. The design is a museum of deferred choices.
The reset isn’t the answer
The instinct is to go back and customize everything. Audit every default, make every option deliberate. That’s the wrong move, for two reasons:
- Most defaults are fine. Fighting every one of them is entropy. The goal is to find the ones that are actually shaping your outcomes in ways you didn’t intend.
- A fully customized environment is a maintenance burden. You now own those decisions — you have to update them when the context changes.
The right approach is more surgical: when something in your output bothers you, trace it backward. Is this a decision I made, or a setting I never changed? That’s the question.
The actual move
Open your most-used tool. Not to change anything — just to look at the settings you’ve never visited.
You’ll find a few that are actively shaping your work. Probably the notification settings (which affect how often you’re pulled out of flow). Probably something about what’s visible by default (which affects how you prioritize). Possibly something about how data is sorted or filtered (which affects what you actually see vs. what’s actually there).
Change the ones working against you. Leave the rest alone.
The goal isn’t to own every setting. It’s to know which settings own you.
Defaults are assumptions. Some of them are your assumptions, made early when you didn’t know better. Some of them were never your assumptions at all — they were the product designer’s best guess about what you’d probably want.
The only meaningful difference between a tool and a tool that fits how you actually work is whether you’ve taken the time to figure out which is which. Most people never do. They just keep building — shaped by options they never chose.