Search page design: where search results lose the user
A user who didn't find what they needed via search rarely returns to the catalog — they leave for external search results.
Search page design is not about "the beauty of the form" but about the number of steps from query to result: input field, suggestions, filters, and sorting must converge into one predictable set of results.
Typical failures repeat from project to project. Irrelevant results — when internal site search works by exact string match and ignores typos, synonyms, and word forms: the user gets dozens of cards, none of which answer the query.
Empty search results with no alternatives — a dead end: no similar items, no popular sections, no reset of conditions.
Extra steps to the goal — a separate results page that doesn't preserve conditions in the URL: the link can't be forwarded, and going back resets the selection.
Filters that diverge from the results and offer values that aren't in the current selection force users to start over — this is a second round of frustration instead of refining the query.
The cost to business is user abandonment of the results page. They don't reach the product page, which means they don't submit a request.
Measurements across catalogs show: the further the results are from the query, the higher the share of returns to external search and the lower the transitions to the target action.
We break down how this is addressed: query and synonym processing, meaningful empty results, filters synchronized with the selection, and an addressable page state.
The effect of a redesigned results page: what changes for the user
The redesign of search results is evaluated not by appearance but by behavior: the share of successful search sessions grows — those where the person reached the target object and did not return with a new query.
We take the baseline from logs of the search engine and interface before changes: repeated refinements per session, time to the desired result, share of clicks from results, share of empty results.
First consequence — fewer repeated query refinements. When synonyms, word forms, and typos are handled by the search engine, and filters and sorting reset predictably, some refinements move into the interface and stop being separate queries. In measurements, this shows up as a decrease in the number of queries per session.
Second — a shorter path to the target object. If a card immediately provides key characteristics and leads to the right page, the session is shortened from several iterations to one or two: the gap between the first query and the last click decreases. It is exactly this that determines time to the desired result.
Third — a higher share of clicks from results. A clear snippet and honest sorting raise the click-through rate of top positions, so more sessions close with a result rather than leaving to the catalog manually or to external search.
Fourth — a lower share of empty results. Handling typos, transliteration, and partial matches plus meaningful options on the "nothing found" screen remove the main class of failures from which the user no longer returns.
We take all four metrics on the same stream of queries before and after — otherwise the comparison is incorrect.
Approaches to designing search results: comparison of options
The scope of work is determined not by catalog size but by the divergence between current results and real queries.
A growing share of sessions without a click on results and queries going to empty results indicate a scenario, not layout; complaints about typos and vague wording indicate the quality of suggestions and synonyms.
| Option | When it fits | Limitations of the option |
|---|---|---|
| Fixing current results | Search logic is satisfactory, but individual defects get in the way: filter reset, sorting, loss of query during pagination | The scenario doesn't change: if the user searches differently, the fix only masks the problem |
| Ready-made results template | Need a quick launch on a typical catalog, own requirements haven't been formed yet | The template sets a fixed set of filters and card structure; compatibility matching and document search don't fit it |
| Mobile version of search | The main share of sessions is from smartphones, filters and sorting don't work there | It solves layout but not ranking; without a shared data source, results diverge from desktop |
| Reworking the search scenario | Queries don't match the data model: people search by task, while the system searches by name | Requires rebuilding the index, synonym dictionaries, and query analytics; timelines depend on data readiness |
The options are not mutually exclusive: the mobile branch and defect fixes are handled in parallel, scenario rework as the next stage, when query statistics confirm the hypothesis.
We close the fork after analyzing search logs: what people enter, where they abandon, what they find.
Order of work on search results: from queries to mockups
Search is not an input field with a button but a set of behavior branches, and almost all failures in mockups happen where the design was drawn based on guesses: suggestions don't match real wording, and on zero results a person hits a dead end. Therefore, the order of work is structured so that the mockup is validated with data before layout.
- Collecting search queries. We export real wording: long tails, typos, mixed languages, zero results. We get frequency distribution and understand which branches are even worth designing.
- Search scenario map. We mark up the branches: exact match, expanded query, search by filters, empty result, input error. For each, we record what the person sees and where the next step leads.
- Results scheme. We lay out the result by layers: suggestions, filters, refinement block, cards, pagination. Separately, we describe behavior for zero results and for incomplete data in a card.
- Results prototype. We assemble a clickable mockup on data close in structure to production: long names, nested categories, missing images. We check that the grid doesn't break at extreme values.
- Validation on real data. We run a sample of queries and look for where scenarios break: suggestions don't work, refinements don't narrow the results, the path to a result is longer than three actions. We make edits before handoff to development.
- Handoff of mockups. We deliver a component library with states, responsive rules, placeholder texts, and loading behavior. Then we support it: we edit based on actual people's behavior, not taste-based comments.
Project composition: mockups, states, and rules for results
Mockups of search results are not one picture of "what the result looks like" but a set of states in which the search page actually finds itself.
We fix them before development starts so engineers don't invent behavior for an empty result or a truncated response from the search service. The client receives:
- Mockups of all results states: full result, partial (some conditions produced no matches), empty, loading state, search service failure, and results without access to part of the catalog.
- Sorting rules: what is shown first when relevance is equal, whether the selected order affects the order of blocks, and whether sorting is preserved in the link on page reload.
- Filter rules: which conditions combine, what happens with an empty intersection, how reset works, and how the found counter is displayed for each condition.
- Behavior for incomplete results: a prompt to remove an extra condition, a block of similar items, and wording — what keeps a visitor instead of leaving an empty page.
- Card markup in results: required fields, behavior of a long title, missing image, and unfilled characteristics.
- Results documentation: a table of URL parameters so that any state can be reproduced via link, and a description of the search service response fields for development.
- Support rules: which filter and sorting edits are safe, what requires rebuilding the search index, and a checklist for checking results before release.
Case: how an online store's search results stopped losing queries
The client is an online store with a catalog of tens of thousands of items. Search returned results "as is": it found matches by exact name but didn't understand typos, synonyms, or a different keyboard layout. Support requests grew faster than orders, and the owner attributed this to weak traffic.
What the measurement before showed
We started not with a mockup but with metrics. The share of empty results — 23% of queries: a person entered "wireless headphones" and got an empty screen without a single suggestion.
41% of visitors left from the first screen, average browse depth of results — 1.4 cards, meaning most didn't even scroll the list.
What we changed
The search logic was rewritten on Elasticsearch: typo parsing, a synonym dictionary, linking product groups, and attribute weighting instead of pure string matching.
The search page design was assembled around the result — filters only by attributes relevant to the category, live results under the input, a separate refinement block instead of an empty screen.
What happened after launch
The share of empty results — 6%, while the empty screen now always offers a refinement or a similar product group. Exits from the first screen — 22%, browse depth of results — 3.1 cards, the number of refining queries doubled.
Transitions from search to a product card increased 1.8 times with the same traffic — the search case was closed not by a redesign but by analyzing exactly where the results were losing the query.
What to do if search results already work but people don't use them
The first signal is a discrepancy between demand and actual usage. We look at the share of sessions where search was opened at all, the share of queries with zero results, and the share of reformulations within one session.
If people enter search and leave to the menu or scroll the catalog manually — the problem is not traffic but that the results don't confirm the intent.
An audit begins with query logs, not a mockup. We export top wording, long phrases, typos, and queries with zero or one result. We compare what the person typed with what they got and where they went next: click on the first position, abandonment, re-entry with different words. Re-entry is the most honest indicator: the user believes the system didn't understand them.
Quick improvements close most of the losses. We add synonyms and typo correction, raise the weight of fields people actually search by — SKU, name, characteristic — configure empty query behavior and suggestions by first characters.
We separately fix the empty state: instead of "nothing found", we show close categories and removal of extra conditions.
Scenario rework is needed where the query doesn't match the task. A person searches by a feature that isn't in indexed fields, or they need parameter-based selection rather than string input.
Then the data model and search logic change: search stops being a separate field and becomes part of filtering, and the result is assembled from several sources.
The order of work is therefore: first an audit of existing results and user behavior in search, then quick improvements, and only then scenario rework for those branches where edits are insufficient. Describe the task — we'll get back with an estimate and plan for your search.
Clarifications on scope, timelines, and results edits
Clients ask five questions almost always: scope of mockup edits, design timelines, mobile version, result validation, and handoff. Below are short answers to remove uncertainty before estimating work.
How many mockup edits are included in the work?
Two rounds of edits at the design stage are included immediately — they concern the structure of results, filters, and cards. After that, changes go through a log: you can see what changed and why, so the scope doesn't grow unnoticed.
What do timelines for search page design look like?
Timelines are broken down by stages: results scheme, card states, responsive grids, handoff to layout. Each stage closes with approval, so a shift is visible in advance, not at the end.
What changes in the mobile version?
Filters move to a separate panel, results — to compact cards with key fields. We separately work through states: empty results, loading, query error — on a phone they occur more often.
How can we make sure the interface works before launch?
We conduct user testing: 5–8 people go through the scenario "found and opened what they needed". We look at time to first result and the share of completed scenarios, and correct disputed points before layout.
Can the search engine be replaced later?
Yes. The presentation layer is separated from the data source: markup and styles don't depend on which engine returns results. Replacement doesn't require redrawing the results.
What do we get at handoff and what about support?
Interface accessibility is placed in a separate checklist based on WCAG, accompanied by component documentation and edit rules. Then — support: updating results states and handling requests as the catalog grows.
Let's discuss the task: we'll get back with an estimate and plan
An accurate estimate of the scope of work on search page design comes not "by eye" but from input data: the more specific the examples, the fewer assumptions in the project plan and the more predictable the timelines.
Below is what is enough to send for us to get back with team composition and stages, rather than general wording.
- Current results: how the search page looks now — with filters, sorting, suggestions, loading and empty result states. Screenshots or a link to a working environment.
- Query examples: 20-30 real wording, including long ones, with typos and Latin characters — they determine the logic of suggestions and the markup of result blocks.
- Analytics or export: share of queries without results, share of refinements after the first results, distribution by filters. This will show which scenarios to fix first.
- Timeline and compatibility constraints: hard dates, supported browsers and devices, accessibility requirements, what cannot be changed in the current design and URL structure.
- Existing materials: logo, palette, fonts, component library, if there is one. Otherwise we'll include a separate stage in the project plan to describe it.
- Decision-makers: who approves mockups and who is responsible for acceptance. This affects not cost but the number of iterations and how quickly stages close.
In response, we send a staged project plan with acceptance points, team composition for the specific scope of work, and a list of scenarios that will be included in the first cycle. Describe the task — we'll get back with an estimate and plan.
