Most people accept whatever is preselected, which makes defaults the most powerful control in an interface.
BIAS·004
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.
LAW·001
Every system has irreducible complexity. The only question is whether the user absorbs it or the product does.
LAW·005
Working memory holds a small number of chunks, so the design lever is what counts as a chunk, not the raw item count.
LAW·004
Among competing solutions that meet the requirement, prefer the one with fewest assumptions and moving parts.
PRIN·001
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.
FND·004
A fixed set of spacing values, so every gap in the product comes from the same vocabulary.
FND·042
Using size, weight, colour and space to make the structure of text visible before it is read.
FND·032
Lines that separate, which should be the second choice after space rather than the first.
FND·047
How much information occupies a given area, which should follow the user's expertise and task rather than a house style.
FND·016
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.
PRIN·003
The escape hatch from navigation, and often the primary path for users who know what they want.
PAT·002
An interruption that should be reserved for genuinely irreversible actions, because it stops being read when it is routine.
PAT·008
Actions that remove or destroy, which need separation in space, distinct styling and a recovery path.
PAT·009
Reversing the last action, which is the single highest-value safety mechanism in most products.
PAT·022
Components you will specify
Each entry covers the states, behaviour and accessibility contract you need to define.
Choosing one option from a known set, which is the wrong control below about five options.
CMP·004
Collapsible sections that shorten a page, at the cost of hiding content from scanning and from search.
CMP·017
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.
A11Y·017
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
A11Y·002
What assistive technology announces for a control, which must match what a user would call it.
A11Y·008
Single-character shortcuts must be switchable off, remappable, or active only on focus.
A11Y·019
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.
WRT·001
Writing that does not exclude, misgender or make assumptions about the person reading it.
WRT·005
Voice is who you are and stays constant. Tone is how you speak in a moment and must change with the situation.
WRT·003
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.
RES·010
Asking users to group content, which reveals their mental model of a domain rather than your org chart.
RES·005
Structured conversations about what people actually did, which is far more reliable than what they say they will do.
RES·003
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.
CHK·010
A practical WCAG 2.2 AA review pass, ordered so the checks that find the most problems come first.
CHK·002
Accounts, teams, permissions, billing and the surfaces every SaaS product needs and few design well.
CHK·007
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.
TPL·011
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.
CASE·004
Every team that added a feature added a notification, and users responded by turning all of them off.
CASE·007
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.