Decision time grows logarithmically with the number of equally likely choices, so the tenth option costs far less than the second.
I'm designing
Navigation
How people find out what exists and where they currently are.
What this surface turns on
- The structure, which is an information architecture question rather than a layout one.
- The labels, which come from research rather than from a meeting.
- What sits at the top level and what is one layer down.
- How the current location is signalled.
Where these usually go wrong
- Labels invented internally rather than drawn from user vocabulary.
- Hover-opened cascading menus, which are fragile to steer and impossible on touch.
- Current location marked by colour alone.
- More than seven top-level items.
- Redesigning the navigation bar when the problem is the structure beneath it.
Why these
Navigation is an architecture problem wearing a menu, so the research methods come first here. The rest cover labelling, current location and the back behaviour people expect from a browser.
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.
Items at the start and end of a list are remembered best, which makes the middle of any list the weakest position.
People spend most of their time on other products, so they expect yours to work the way those do.
Moving a pointer along a constrained path takes time proportional to the path length divided by its width, which is why nested menus are hard.
Working memory holds a small number of chunks, so the design lever is what counts as a chunk, not the raw item count.
Time to hit a target depends on how far away it is and how big it is, which makes size and distance the two levers you control.
The craft decisions
The visual and structural foundations that carry most of the weight on this surface.
The order in which elements are noticed, controlled by size, weight, colour, position and space.
Making one thing stand out, which only works if most things do not.
Using size, weight, colour and space to make the structure of text visible before it is read.
Difference is what makes anything perceivable, and it is measurable for text against its background.
Elements that look alike are assumed to behave alike, which makes visual language a promise.
A fixed set of spacing values, so every gap in the product comes from the same vocabulary.
Patterns to reach for
Solutions people already recognise, with the conditions under which each one earns its place.
The structure that tells people what exists and where they are, which is an information architecture problem before it is a layout one.
The escape hatch from navigation, and often the primary path for users who know what they want.
Show the common case first and reveal the rest on request, so complexity is available without being present.
Components you will specify
Each entry covers the states, behaviour and accessibility contract you need to define.
A list of actions revealed on demand, which is where infrequent operations belong.
Content revealed below a trigger, a term that covers three different components and causes confusion.
Parallel views in one space, which works only when users never need to compare across them.
A trail showing where you are in a hierarchy, useful when the hierarchy is deeper than two levels.
A panel that slides in from an edge, keeping context visible while offering more room than a popover.
Accessibility requirements
Not a separate pass. These are the requirements this surface raises, mapped to the decisions that produce them.
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
The visible marker showing where keyboard focus is, which must never be removed.
What assistive technology announces for a control, which must match what a user would call it.
Content that appears on hover or focus must be dismissible, hoverable and persistent.
Headings are the table of contents screen reader users navigate by, so levels must follow structure rather than appearance.
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.
Use the words, concepts and order that your users already have, not the ones your database has.
Designing so the product can be adapted to other languages and regions without being rebuilt.
How to find out
Research methods suited to the questions this surface raises.
Asking users to group content, which reveals their mental model of a domain rather than your org chart.
Testing whether people can find things in a structure, with no visual design to confound the result.
Measuring where people click first, which predicts task success better than almost any other single measure.
Organising, labelling and structuring content so people can find it, which determines navigation rather than following from it.
Check your work
Interactive checklists, with progress saved in your browser.
A structured pass across the whole product, organised by the same categories as the audit tool.
A practical WCAG 2.2 AA review pass, ordered so the checks that find the most problems come first.
Touch targets, reach, input, performance and the assumptions that only fail on a phone.
Documents you might need
Fillable templates, prefilled so they are usable rather than empty.
Every path through a task, including the error paths and the states most flows forget.
A recording sheet for expert review, with severity rated from frequency, impact and persistence.
Decisions other teams made
Worked cases, including the options that were rejected and why.
A large share of searches returned nothing, and the fix was vocabulary rather than the search engine.
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.