UX Patterns Guide
Back to compare picker

Search result highlighting vs Basic search vs Search suggestions vs No-results recovery

Prefer search result highlighting when users already have results and need to see the exact title, snippet, or metadata fields that matched their query.

Search result highlighting live exampleBasic search live exampleSearch suggestions live exampleNo-results recovery live example
Learn the decision

Match the interaction to the person's task

Prefer search result highlighting when users already have results and need to see the exact title, snippet, or metadata fields that matched their query.

Search result highlighting

Use it when: Results contain enough text that users need to scan for where the query matched.

Make this state clear: Submitted query with one or more highlighted result fields.

Observe the result: A user searches benefits appeal and can immediately see which result matched benefits in the title and appeal in the excerpt.

Study the full pattern →

Basic search

Use it when: Users know a word, name, or identifier.

Make this state clear: Empty query state.

Observe the result: Users can type, revise, clear, and keep context while inspecting results.

Study the full pattern →

Search suggestions

Use it when: The system can predict likely queries.

Make this state clear: Typing state with suggestions.

Observe the result: Users can keep typing, choose a suggestion, dismiss suggestions, or submit their own query.

Study the full pattern →

No-results recovery

Use it when: Search, browse, or filter controls can produce an empty result set.

Make this state clear: Zero-result state that preserves the user's criteria.

Observe the result: Users can remove one filter, clear all, edit query, or try suggested alternatives.

Study the full pattern →

Practice the judgment: Imagine this situation: A snippet contains a highlighted word but too little surrounding text to explain why the result is useful. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Search result highlightingBasic searchSearch suggestionsNo-results recovery
UI or UX UI + UX - Highlighted matching terms and snippets inside returned search resultsUI + UX - Search input and result listUI + UX - Suggested-query surfaceUI + UX - Search recovery state
UI guidance Pair highlighted fragments with field labels, match counts, result titles, and enough surrounding snippet text that users can understand why the result is present.Render a labeled search field, result count, matching rows, and clear action.Keep suggestions visually tied to the current input.Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.
UX guidance Use search result highlighting to explain relevance after a query has returned results, especially when users scan dense documents, records, tickets, messages, or logs.Help the person reach a clear task outcome.Help the person reach a clear task outcome.Help users recover when their own search or filters excluded all results.
Good UI A result card for Benefits appeal policy highlights Benefits in the title and appeal in the snippet, with a small label saying 2 highlighted fields.A clearly labeled search field with result count and results placed directly below.Suggestions appear directly below the search field with active row, readable labels, and optional matched text.Zero-result state shows query/filters, result count, and clear or broaden actions.
Bad UI Old highlighted words remain visible after the user clears the query or switches to a zero-result state.Results jump, resize, or use heavy borders that make scanning feel like reading a form.Promoted results styled the same as typed query suggestions.Huge empty state that hides active filters.
Good UX A user searches benefits appeal and can immediately see which result matched benefits in the title and appeal in the excerpt.Users can type, revise, clear, and keep context while inspecting results.Users can keep typing, choose a suggestion, dismiss suggestions, or submit their own query.Users can remove one filter, clear all, edit query, or try suggested alternatives.
Bad UX Result highlighting is implemented by injecting raw backend HTML into a card, causing unsafe or broken markup.Search silently changes unrelated filters.Auto-submitting the top suggestion.Telling users nothing exists when filters caused the state.
Best fit Results contain enough text that users need to scan for where the query matched.Users know a word, name, or identifier.The system can predict likely queries.Search, browse, or filter controls can produce an empty result set.
Avoid when The result title is the entire match and extra emphasis would add noise.The task is choosing a command with side effects.Suggestions are low quality or biased toward irrelevant content.The state is caused by an error rather than valid empty results.
Required state Submitted query with one or more highlighted result fields.Empty query state.Typing state with suggestions.Zero-result state that preserves the user's criteria.
Accessibility burden Use semantic text markup such as mark for highlighted passages when the highlight indicates relevance in the current search context.The input has a stable accessible name.Expose the suggestions list and active option.Announce result-count changes where search results update dynamically.
Common misuse Highlighting whole cards, rows, or table columns instead of the matching terms.Using placeholder text as the only label.Showing unrelated promoted results as suggestions.Resetting all criteria automatically.

Search result highlighting

UI or UX
UI + UX - Highlighted matching terms and snippets inside returned search results
UI guidance
Pair highlighted fragments with field labels, match counts, result titles, and enough surrounding snippet text that users can understand why the result is present.
UX guidance
Use search result highlighting to explain relevance after a query has returned results, especially when users scan dense documents, records, tickets, messages, or logs.
Good UI
A result card for Benefits appeal policy highlights Benefits in the title and appeal in the snippet, with a small label saying 2 highlighted fields.
Bad UI
Old highlighted words remain visible after the user clears the query or switches to a zero-result state.
Good UX
A user searches benefits appeal and can immediately see which result matched benefits in the title and appeal in the excerpt.
Bad UX
Result highlighting is implemented by injecting raw backend HTML into a card, causing unsafe or broken markup.
Best fit
Results contain enough text that users need to scan for where the query matched.
Avoid when
The result title is the entire match and extra emphasis would add noise.
Required state
Submitted query with one or more highlighted result fields.
Accessibility burden
Use semantic text markup such as mark for highlighted passages when the highlight indicates relevance in the current search context.
Common misuse
Highlighting whole cards, rows, or table columns instead of the matching terms.

Basic search

UI or UX
UI + UX - Search input and result list
UI guidance
Render a labeled search field, result count, matching rows, and clear action.
UX guidance
Help the person reach a clear task outcome.
Good UI
A clearly labeled search field with result count and results placed directly below.
Bad UI
Results jump, resize, or use heavy borders that make scanning feel like reading a form.
Good UX
Users can type, revise, clear, and keep context while inspecting results.
Bad UX
Search silently changes unrelated filters.
Best fit
Users know a word, name, or identifier.
Avoid when
The task is choosing a command with side effects.
Required state
Empty query state.
Accessibility burden
The input has a stable accessible name.
Common misuse
Using placeholder text as the only label.

Search suggestions

UI or UX
UI + UX - Suggested-query surface
UI guidance
Keep suggestions visually tied to the current input.
UX guidance
Help the person reach a clear task outcome.
Good UI
Suggestions appear directly below the search field with active row, readable labels, and optional matched text.
Bad UI
Promoted results styled the same as typed query suggestions.
Good UX
Users can keep typing, choose a suggestion, dismiss suggestions, or submit their own query.
Bad UX
Auto-submitting the top suggestion.
Best fit
The system can predict likely queries.
Avoid when
Suggestions are low quality or biased toward irrelevant content.
Required state
Typing state with suggestions.
Accessibility burden
Expose the suggestions list and active option.
Common misuse
Showing unrelated promoted results as suggestions.

No-results recovery

UI or UX
UI + UX - Search recovery state
UI guidance
Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.
UX guidance
Help users recover when their own search or filters excluded all results.
Good UI
Zero-result state shows query/filters, result count, and clear or broaden actions.
Bad UI
Huge empty state that hides active filters.
Good UX
Users can remove one filter, clear all, edit query, or try suggested alternatives.
Bad UX
Telling users nothing exists when filters caused the state.
Best fit
Search, browse, or filter controls can produce an empty result set.
Avoid when
The state is caused by an error rather than valid empty results.
Required state
Zero-result state that preserves the user's criteria.
Accessibility burden
Announce result-count changes where search results update dynamically.
Common misuse
Resetting all criteria automatically.
Decision rules
  • Prefer search result highlighting when users already have results and need to see the exact title, snippet, or metadata fields that matched their query.
  • Prefer basic search when the design problem is the query input, submission, result count, clear action, and stable result-list placement rather than match emphasis inside each hit.
  • Prefer search suggestions when users are still composing a query and need possible query phrases before the result page exists.
  • Prefer no-results recovery when the result count is zero and users need spelling, filter, scope, or query-broadening paths instead of highlighted snippets.
  • Highlight only terms or fragments that correspond to the executed query, synonym, or configured highlight query; do not highlight unrelated popularity, category, or sponsored terms as if they explain relevance.
  • Show enough surrounding snippet text to make the highlight meaningful, and use ellipsis or fragment boundaries when text was removed.
  • Use highlight styling in addition to text, match counts, field labels, or snippet placement so color is not the only way users infer why a result matched.
  • When highlighting comes from backend markup, sanitize or render it through a trusted highlighter component rather than injecting arbitrary HTML into the result card.
  • When complex boolean, fuzzy, or semantic queries produce approximate highlight fragments, avoid presenting the highlight as proof that every query condition matched exactly.
  • Do not use search result highlighting as a substitute for ranking, filtering, query correction, result grouping, or clear result titles.
Inspect live examples
Search result highlightingBasic searchSearch suggestionsNo-results recovery
Failure modes
  • Every result card receives a yellow wash, so users cannot tell which words caused the match.
  • The UI highlights sponsored terms, categories, or synonyms without explaining that they differ from the submitted query.
  • A snippet contains a highlighted word but too little surrounding text to explain why the result is useful.
  • Backend highlight HTML is inserted unsafely and can break markup or create script-injection risk.
  • The highlight uses color alone, making the match hard to perceive for users with low vision or color vision differences.
  • A zero-result state still shows old highlights from the previous query, implying matches that are no longer present.

Saved items