The Anatomy of a Good Default
Defaults are the most powerful design decision you make and the least discussed.
Kestrel is an analytics tool. Its date range picker defaults to Last 30 days. In a support review someone notices that a quarter of the questions that reach support are variations of why do these numbers not match finance. Finance works in calendar months. Kestrel's default is a rolling window. Nobody ever decided that, it was the first thing someone typed while building the component in 2021.
Most defaults in most products arrive this way. They then determine the behaviour of the large majority of users forever, because almost nobody changes them.
How hard to think about a default
How strong the effect is
Johnson and Goldstein published a paper in Science in 2003 comparing organ donation consent rates across European countries. Countries where citizens are registered as donors unless they opt out showed consent rates far above countries requiring an opt-in, and the gap was enormous, not marginal. The stated preferences of the populations were not that different. The forms were.
You do not need to accept any particular account of why to take the operational point. A default is a recommendation with the friction removed, and it will be accepted by most people who encounter it. That makes choosing one an act of responsibility, not a convenience.
Four tests for a default
- Right for the median case
- Not the average of all cases, the most common single case. A default tuned to a blend of power users and beginners usually fits neither.
- Safe when wrong
- Ask what happens if the default is wrong and the user does not notice. Wrong date range means confusing numbers. Wrong sharing setting means a leak. The cost of being wrong sets how conservative the default should be.
- Visible
- The user should be able to see the default is in effect without hunting. A picker reading Last 30 days is visible. A hidden setting that quietly rounds your numbers is not.
- Cheap to change and to keep changed
- If a user overrides it, remember that. Re-imposing a default the user has rejected every session is the difference between a default and a nag.
Default choices that cause work
- Date range: Last 30 days (rolling)
- Notify: All activity, email and push, on by default
- New document sharing: Anyone with the link can edit
- Export format: JSON
- Sort: Recently updated
Default choices that fit the job
- Date range: This month (1 Sep to today), with Last 30 days one click away
- Notify: Mentions and direct messages only. Turn on activity digests in Settings.
- New document sharing: People in Kestrel Ltd can view. Change to edit or link sharing per document.
- Export format: CSV, because the next step is almost always a spreadsheet
- Sort: Recently updated, and we remember if you change it
Row three is the one worth arguing about in your own product. Anyone with the link can edit is a lovely default for collaboration demos and a terrible one for a company handling client data. When the failure mode is a leak, the default belongs at the conservative end and the looser option belongs one click away with its consequence stated.
Row four shows a different principle: default to the next step in the user's workflow, not to the format that is most technically general. JSON is more expressive. CSV is what happens next.
Worked example
Kestrel picks a side
They change the default to This month and add one line under the picker: Calendar month, matches your finance reports. Last 30 days stays as a preset. Support questions about mismatched numbers drop sharply. One power user complains, is offered a saved view, and stops complaining. The team writes a short note in the design system: our date defaults follow the finance calendar, because reconciliation is the most common downstream task.
That last sentence is the durable part. A good default is a decision with a reason attached, recorded somewhere the next person building a date picker will see it. Without the reason, defaults drift back to whatever the component library ships with.
- Write down the assumed user for each default. If you cannot name them, you have not chosen a default, you have inherited one.
- Never default to the option that is best for you and worst for the user. Pre-ticked marketing consent is the canonical example and it is now illegal in several jurisdictions.
- Smart defaults beat clever ones. Prefilling a currency from the user's country is smart. Guessing their intent from their scrolling is clever, and clever defaults are hard to trust.
- Audit your defaults once a year. The median user in 2026 is not the median user the default was chosen for in 2021.
Quick check
Which factor should most influence how conservative a default is?
The takeaway
A default is a recommendation almost everyone accepts, so choose it for the most common job, size it by the cost of being wrong, and record the reason.
Try this tomorrow
List every default on one high-traffic screen, name the user each was chosen for, and change the one whose failure mode is most expensive.
Answer the check above, then bank the day.
Where this comes from
- Do Defaults Save Lives? (2003), Eric Johnson and Daniel Goldstein
- The Design of Everyday Things, Don Norman
- 10 Usability Heuristics for User Interface Design, Jakob Nielsen, NN Group
Craft is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.