Search UX

For a long time a search box was treated as one input field. Take the characters, hand them to the database, print whatever matched. From the building side, the work was done.

From the using side it kept failing. Someone looking for a meeting record from six months ago types "meeting record" and gets zero results. The document was saved with the title "meeting notes," and the search was matching exact strings in titles only. All that stays on screen is one gray line saying no results found, and the user concludes the document was deleted and asks a colleague about it.

The same thing happened in products with well-built organization. A menu split neatly by type of work gives every document a home in the head of the person who designed it, but users arrive without having agreed to that split. Typing the word they remember is faster than clicking down five levels of menu. Search becomes the main route rather than the detour, and when that route looks like the above, users fail to find things that are sitting right there.

Search UX gets designed as a flow with five segments rather than as one query. Leave any one of them empty and the other four working well won't get the user to their destination.

1. Input — decide where the box sits and what guidance goes inside it. "Search by title or contents" tells a user what will actually be looked at, which "Search documents" does not. Autocomplete that suggests candidates while typing, and a list of recent queries, attach here.
2. Interpretation — translate what the user typed into what the product holds. Correct typos, and register words used for the same thing as one group. Put "meeting record" and "meeting notes" in the same group and either one returns the same results. In products where each team has its own vocabulary, this list decides about half of what search quality means.
3. Scope — decide whether to look at titles only or contents too, and whether comments and attachments count. Permissions ride along here. A document the user can't open appearing in results leaks information by itself, and a result that shows a title but won't open reads as a broken product.
4. Result display — decide the ordering and what one row contains. Relevance ordering or most-recently-edited ordering depends on the product, and recency usually wins where people are re-finding things they wrote. A row carries more than a title: where the document lives, who edited it last, and where in the body the query matched. When the reason for the match is visible, a user can choose without opening anything.
5. No results — the zero-result screen is where this design gets tested. Rather than ending at one line, it asks back about a likely typo, shows results from a widened scope instead, and offers a button to clear whichever filters are on, so that the screen always holds at least one next move.

Narrowing belongs to the same flow. At 800 results a user reaches for stacking conditions rather than rewriting the query, which is why a faceted filter, the control that narrows scope by stacking attribute conditions, sits on the results screen.

The first place it becomes necessary is a product where the item count has outgrown the menu. Four uses come up most often.

1. Products with many items — past 500 documents, navigation, the machinery for moving between screens, struggles to isolate one of them. Products past that mark treat search as the primary route.
2. Users who disagree with the organization — the detour for when the designer's categories don't match the categories in a user's head. Re-cutting the organization takes months; search carries the product through that stretch. It is worth knowing that this is what is happening, though, because a detour carrying most of the traffic stops being a detour.
3. A window into the product — the list of queries that ended in zero results reports both what's missing and which names are misaligned. If "meeting record" gets searched 40 times a month and returns nothing every time, that's grounds for changing labeling, the work of naming the categories.
4. Narrow screens — mobile has no room to stack deep menus, so it leans harder on search. Many products put the box on the first screen for that reason alone.

The same query can carry different expectations about what the results should be. That difference has its own term, search intent, and it gets consulted when laying out the results screen.

"Start with the zero-result screen. Right now it's one gray line and that's it."

When search fails, nothing on the screen tells the user what to do next.

"'Meeting record' was searched 40 times this month and returned nothing every time. Add it to the synonyms."

Locating a place where the user's vocabulary and the product's vocabulary diverge.

"The result row needs the location and the edit date too. A title alone isn't enough to choose from."

The information needed to pick a result is missing from the row.

At Pagedeck, Noa started with the zero-result screen when redrawing search results. It now carries a line asking back about the query, three results from a widened scope, and a button that clears the active filters. Mia keeps a monthly table of queries that ended in zero results, and when the same word shows up more than twenty times she either adds it to the synonym list or renames the item to match.

The most common mistake is reading search as a response-time problem. Complaints about slowness arrive first and they come with numbers attached. But the moment a user decides search is unusable is usually not slowness — it's the moment the thing they wanted doesn't appear. Cut response time from 200 milliseconds to 80 and, with the zero-result screen unchanged, the drop-off among users who hit that screen stays exactly where it was. Speed improves the feel of a product whose results are already right, and does nothing at all for one whose results are wrong.

Believing that search lets you care less about organization is the other one. If users go straight to the box anyway, tidying the menu looks safely deferrable. But what search finds is the words written in titles and bodies. While the same place is called a workspace in some documents and a team space in others, anything a user types matches half of them. Strengthening search in a product with inconsistent naming amounts to scanning a broken index faster. Organization and names have to settle first for search to do its job on top of them.