Most people accept whatever is preselected, which makes defaults the most powerful control in an interface.
I'm designing
Settings
Preferences, account and configuration, where the defaults matter more than the controls.
What this surface turns on
- Which settings exist at all, versus decisions the product should make.
- What each default is, and whose interest it serves.
- How settings are grouped and named.
- Whether changes apply immediately or need saving.
Where these usually go wrong
- A toggle in a form that has a save button, so nobody knows when the change took effect.
- Three settings that are never set independently, which are one setting with a good default.
- Defaults chosen for implementation convenience.
- Settings that cannot be searched, in a list long enough to need it.
- Destructive account actions adjacent to routine ones.
Why these
Settings are where products accumulate. These entries cover grouping by intent, save conventions and defaults, because defaults are what most people will actually live with.
Why it works the way it does
The reasoning layer. Read these when a decision needs justifying, or when something is failing and you cannot say why.
Decision time grows logarithmically with the number of equally likely choices, so the tenth option costs far less than the second.
Every system has irreducible complexity. The only question is whether the user absorbs it or the product does.
Working memory holds a small number of chunks, so the design lever is what counts as a chunk, not the raw item count.
Among competing solutions that meet the requirement, prefer the one with fewest assumptions and moving parts.
The craft decisions
The visual and structural foundations that carry most of the weight on this surface.
Things placed close together are read as belonging together, before anything is read.
A fixed set of spacing values, so every gap in the product comes from the same vocabulary.
Using size, weight, colour and space to make the structure of text visible before it is read.
Lines that separate, which should be the second choice after space rather than the first.
How much information occupies a given area, which should follow the user's expertise and task rather than a house style.
Patterns to reach for
Solutions people already recognise, with the conditions under which each one earns its place.
Show the common case first and reveal the rest on request, so complexity is available without being present.
The escape hatch from navigation, and often the primary path for users who know what they want.
An interruption that should be reserved for genuinely irreversible actions, because it stops being read when it is routine.
Actions that remove or destroy, which need separation in space, distinct styling and a recovery path.
Reversing the last action, which is the single highest-value safety mechanism in most products.
Components you will specify
Each entry covers the states, behaviour and accessibility contract you need to define.
An immediate on or off setting, which must actually take effect immediately.
Choosing one option from a known set, which is the wrong control below about five options.
One choice from a small visible set, where seeing all the options is the point.
Independent on or off choices, where the label is part of the target.
Collapsible sections that shorten a page, at the cost of hiding content from scanning and from search.
Accessibility requirements
Not a separate pass. These are the requirements this surface raises, mapped to the decisions that produce them.
Every input needs a persistent label, and format requirements must be stated before the user types.
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
What assistive technology announces for a control, which must match what a user would call it.
Single-character shortcuts must be switchable off, remappable, or active only on focus.
Language and content
The words do more work here than most teams budget for.
The small pieces of text that do most of the work: labels, hints, empty states, errors and confirmations.
Writing that does not exclude, misgender or make assumptions about the person reading it.
Voice is who you are and stays constant. Tone is how you speak in a moment and must change with the situation.
How to find out
Research methods suited to the questions this surface raises.
Measuring what people do at scale, which tells you where problems are and never why they exist.
Asking users to group content, which reveals their mental model of a domain rather than your org chart.
Structured conversations about what people actually did, which is far more reliable than what they say they will do.
Check your work
Interactive checklists, with progress saved in your browser.
Whether the design serves the user's interest, including where that now overlaps with legal obligation.
A practical WCAG 2.2 AA review pass, ordered so the checks that find the most problems come first.
Accounts, teams, permissions, billing and the surfaces every SaaS product needs and few design well.
Documents you might need
Fillable templates, prefilled so they are usable rather than empty.
A feature specification that covers states, edge cases and accessibility rather than only the happy path.
Decisions other teams made
Worked cases, including the options that were rejected and why.
A generous, modern-looking redesign made a dashboard slower for the people who used it all day.
Every team that added a feature added a notification, and users responded by turning all of them off.
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.