I once opened a configuration screen with 47 empty fields and a primary button labelled Save. The product had achieved the rare feat of being both completely flexible and immediately hostile. Every decision was mine, including several I did not understand and two that appeared to require a working knowledge of international tax law.

The team described this as giving users control. The users described it with shorter words.

Defaults are often treated as minor interface details: the preselected radio button, the suggested date, the initial sort order. In reality, a default is the product making a decision before the user has to. It expresses what the team believes is common, safe and useful. That makes defaults part of product strategy.

Flexibility has a cost

Enterprise software loves configuration because every customer is different. This is true, but not always in the way a settings page suggests. Customers often share a common job and differ around the edges. If the product begins with every possible variation exposed, it makes the common case pay for the exceptional one.

Each blank field transfers work from the product team to the user. Somebody must discover the option, understand it, decide on a value and live with the consequences. One choice is manageable. Forty-seven choices create an implementation project.

The answer is not to remove flexibility. It is to sequence it. Give people a credible starting point and let them adapt when reality requires it. A good default preserves control while reducing the cost of reaching usefulness.

Defaults reveal what the product thinks

A default cannot be neutral. Preselecting “send notification” changes behaviour. Sorting by newest rather than most urgent changes attention. Setting a quote validity period influences commercial risk. Even leaving a field blank is a default: it says the user must decide before continuing.

That is why defaults deserve explicit discussion. What evidence supports this starting value? Who benefits? Who carries the risk if it is wrong? Can it be reversed? Is the choice visible?

The GOV.UK guidance on making services simple to use emphasises understanding the whole problem and removing unnecessary complexity rather than merely making individual screens easier. Defaults support that goal when they encode known, repeated decisions instead of asking every user to rediscover them.

Start with the common safe case

I use two tests for a default. First, is it common enough to save meaningful effort? Second, is it safe enough that an unnoticed choice will not cause disproportionate harm?

The common case alone is not sufficient. If 70% of users usually send an invoice immediately, preselecting “send now” may still be risky when the remaining 30% need internal approval. Consequence matters. Low-risk, reversible choices can be more assertive. High-risk choices should be visible, confirmed or deliberately left for the user.

This creates a useful hierarchy. Formatting, sorting and display preferences can often default quietly. Commercial commitments, permissions and destructive actions need more care. A product that treats both categories identically is not consistent; it is avoiding judgement.

Use progressive configuration

Many products demand configuration before users have enough context to make good decisions. The setup wizard asks about advanced workflow rules before anyone has processed a single real item. People guess, copy another account or accept whatever is selected. Six months later, the organisation treats those guesses as policy.

Progressive configuration moves decisions closer to the moment they become meaningful. Start with a working baseline. Introduce advanced options when the user encounters the relevant scenario. Explain the consequence in the language of the job, not the architecture.

In complex platforms such as the work shown in my Aerios case study, pricing, documents and workflow can vary by carrier. A scalable experience cannot pretend those differences do not exist. It can, however, offer a sensible operating model and make exceptions deliberate rather than forcing every customer to assemble the product from spare parts.

Defaults should be legible

Users should be able to tell what the product chose for them. Hidden defaults create mystery later: notifications arrive, records move or fees appear with no visible decision behind them.

Legibility does not require a warning banner around every preselected control. It means showing the chosen value where it matters, explaining unusual consequences and making changes straightforward. A phrase such as “We’ll use your organisation’s standard payment terms: 30 days” carries more trust than an invisible value inherited from a settings table.

This also supports recognition rather than recall, one of the established usability heuristics. Users should not need to remember what was configured elsewhere to understand the current task.

Personalisation is not always the answer

When defaults underperform, teams often reach for personalisation. The system will learn each user, reorder everything and make the interface magically relevant. Sometimes this helps. Sometimes it creates a product that behaves differently for every colleague and cannot explain why.

Shared operational products need a degree of predictability. If one person’s “urgent” queue differs from another’s, handover becomes harder. Personal defaults are most useful for harmless preferences or clearly individual work patterns. Shared business rules should remain visible and governable.

Machine-learned defaults need the same discipline. Show the suggestion, preserve the ability to change it and avoid presenting probability as policy. If the system cannot explain why a consequential option was chosen, it should probably not choose it silently.

Measure the work removed

The success of a default is not the percentage of users who leave it unchanged. People may accept a poor choice because changing it is difficult or because they never noticed it.

Measure whether setup time falls, errors reduce and users reach their first meaningful outcome faster. Look for repeated corrections later in the workflow. Review support requests and implementation workarounds. If every customer changes the same default on day one, the product has received unusually clear research feedback.

A/B testing can help with low-risk interface choices, but strategic defaults need qualitative evidence too. Watch how teams explain the choice, when they override it and what happens afterwards. The best default often comes from understanding the operating model, not optimising a click-through rate.

Design the escape route

Every default needs an escape route proportionate to its impact. Users should be able to change it before committing, understand what the change affects and reverse it where possible. Organisation-wide changes may need permission and audit; personal preferences should not require a support ticket and three ceremonial approvals.

Be careful with “reset to default” when the default itself can change. Tell users what they are returning to. If new regulations or commercial policies alter the baseline, do not quietly rewrite existing records unless that is genuinely intended.

A useful opinion

Good products have opinions. They know what a successful first run looks like, which choices are routine and where caution is necessary. Defaults are how those opinions become practical.

Choose the common safe case. Make the choice visible. Delay complexity until it has context. Preserve a clear route out. Then measure whether the product removed work rather than merely moving it into a settings page.

Giving users 47 blank fields is not freedom. It is outsourcing the product strategy to whoever happened to create the account.