Recognising something on screen is far easier than remembering it, so keep the information visible.
I'm designing
A Search Experience
The input, the suggestions, the results and everything that happens when there are none.
What this surface turns on
- What is searched: titles only, or content, tags and aliases too.
- How much fuzziness you allow.
- What appears before anything is typed.
- What happens when nothing matches.
Where these usually go wrong
- Exact matching only, so any synonym or typo returns nothing.
- The query cleared on the results page.
- An empty box with no suggestions, popular queries or recent searches.
- A bare 'no results' with no correction and no next step.
- Result counts that never reach assistive technology.
Why these
Search is judged on its worst result, not its best. This selection covers query understanding, the zero-result screen, filtering and the vocabulary problem that causes most failed searches.
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.
Below roughly 400 milliseconds of system response, people stop waiting on the machine and productivity rises sharply.
Decision time grows logarithmically with the number of equally likely choices, so the tenth option costs far less than the second.
Working memory holds a small number of chunks, so the design lever is what counts as a chunk, not the raw item count.
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.
Using size, weight, colour and space to make the structure of text visible before it is read.
How much information occupies a given area, which should follow the user's expertise and task rather than a house style.
Making one thing stand out, which only works if most things do not.
Empty space is a design element that groups, emphasises and sets pace, not leftover area.
Patterns to reach for
Solutions people already recognise, with the conditions under which each one earns its place.
The escape hatch from navigation, and often the primary path for users who know what they want.
Suggestions as the user types, which turns recall into recognition when it is fast enough.
Narrowing a large set by attributes, which is what makes large catalogues navigable at all.
Reordering a set, where the default order is the decision that matters most.
The screen before there is anything to show, which is a teaching opportunity rather than a gap.
Three ways to handle long result sets, each with a different cost, and the right choice depends on the task.
Components you will specify
Each entry covers the states, behaviour and accessibility contract you need to define.
Free-form entry, where the label, the hint and the error placement do most of the work.
A small marker of status, category or count, which must not look like something you can press.
Splitting results into pages, which preserves position and keeps the footer reachable.
A container that groups content about one object, and the most over-applied component in modern UI.
Accessibility requirements
Not a separate pass. These are the requirements this surface raises, mapped to the decisions that produce them.
Telling assistive technology that something changed, when focus did not move to say so.
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.
Deliberately moving focus when the interface changes, so keyboard and screen reader users are not stranded.
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.
Deciding what content a user needs and in what order, which is a design activity rather than a writing one.
Use the words, concepts and order that your users already have, not the ones your database has.
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.
Testing whether people can find things in a structure, with no visual design to confound the result.
Watching people attempt real tasks, which is the most direct evidence available about whether a design works.
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.
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.
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.