Search
A box that takes what someone already knows and returns what they wanted.
The problem it solves
Past a few hundred items, browsing stops working. People arrive knowing roughly what they want and need a way to say it in their own words rather than in the product's taxonomy.
Search is three systems pretending to be one box: what the box accepts, how results are ranked, and what happens when nothing matches. Teams build the first, buy the second, and forget the third, which is the one users remember.
The query is not the problem statement
People type fragments, misspellings, product codes, and half-remembered phrases. A search that only matches exact strings makes the user responsible for guessing your vocabulary. Handle synonyms, stemming, and typos before you handle anything clever, because those three cover most of the failures.
- Search across the fields people actually think in, including titles, tags, author names, and body text, not just the title field.
- Show suggestions as they type, and make the suggestions selectable with the keyboard. This is recognition beating recall, and it costs one component.
- Keep the query visible in the results view so people can edit rather than retype.
- Rank recency and personal history above raw text relevance for tools where users search for their own work.
- Log queries that return nothing. That log is the cheapest product research in the building.
The zero-results state does the most work per pixel. A blank page ends the session. A page that says what was searched, offers a corrected spelling, drops the least important term, and shows a few plausible alternatives keeps the person moving.
Zero results, dead end
- No results found.
- 0 items match your search.
Zero results, next move
- Nothing matched invocies. Showing results for invoices instead. Search invocies anyway
- No files match budget 2026 in Finance. 12 files match budget 2026 across all folders. Search everywhere
Worked example
A hypothetical null-query review
A team exports a month of searches that returned nothing. They find a cluster of queries using a word their taxonomy does not contain, because customers call the thing something else. Two fixes are available: add the word as a synonym, which takes an afternoon, or rename the feature, which takes a quarter. The log made a naming problem visible that no interview had surfaced.
Decide early whether search is the primary navigation or the escape hatch. If it is primary, it deserves the top of every page, a keyboard shortcut, and real ranking work. If it is the escape hatch, keep it simple and spend the effort on the browse structure instead. Products that hedge get a weak search and a weak hierarchy.
When it fits
- The catalogue or workspace is large enough that scanning a list has stopped being viable.
- Users arrive with a specific target in mind rather than an intention to browse.
- Items carry enough text, metadata, or history to rank against each other meaningfully.
- You can instrument queries and act on the ones that fail.
When it backfires
- The corpus is small, so a box replaces a list that would have been faster to read.
- Ranking is untuned, so the right answer sits on page two and people conclude the item does not exist.
- Results appear without the query visible, forcing a retype to refine.
- Search is used to excuse a broken hierarchy, which pushes the cost of your structure onto the user.
Products using it
Notion
Weights recently visited and recently edited pages in results, because a user's own history predicts their target better than text matching.
Airbnb
Treats the search box as the primary entry to the whole product, with structured inputs for place and dates rather than free text alone.
GitHub
Accepts qualifiers such as repo and language inside the query string, letting expert users filter without leaving the box.
The psychology under it
The takeaway
Rank well, accept messy queries, and treat the zero-results page as a feature rather than an error.
Finished the teardown? Bank it and the day counts toward your run.