UI + UX Search, Browse, And Discovery established

No-results recovery

Explain that no matches were found, preserve the user's query or filters, and offer specific ways to broaden or correct the search.

Decision first

Choose this pattern when the problem matches

Use when

  • Search, browse, or filter controls can produce an empty result set.
  • Users can modify criteria, browse alternatives, or start over.

Avoid when

  • There is genuinely no possible next action and the system should instead explain availability.
  • The state is caused by an error rather than valid empty results.

Problem it prevents

A search or filter returns nothing, leaving users without a path forward.

Pattern anatomy

What a strong implementation has to make clear

User need

A valid search, filter, or browse action produces zero visible items.

Pattern promise

Explain that no matches were found, preserve the user's query or filters, and offer specific ways to broaden or correct the search.

Required state

Zero-result state that preserves the user's criteria.

Recovery path

Blank result areas with no explanation.

Access contract

Announce result-count changes where search results update dynamically.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Zero-result state shows query/filters, result count, and clear or broaden actions.
  • Recovery suggestions are visually close to the empty result area.
  • Users can remove one filter, clear all, edit query, or try suggested alternatives.
  • The system distinguishes no results from load failure.
Weak implementation

Vague, hidden, hard to recover from

  • No results text alone with no criteria shown.
  • Huge empty state that hides active filters.
  • Telling users nothing exists when filters caused the state.
  • Resetting all criteria without confirmation when users only meant to remove one.
UI guidance
  • Render zero-result copy, active criteria, remove-filter actions, and alternative suggestions.
  • Keep query and filters visible so users know what caused the state.
UX guidance
  • Help users recover when their own search or filters excluded all results.
  • Suggest narrower, broader, or reset paths without implying system failure.
Implementation contract

What the implementation must handle

States

  • Zero-result state that preserves the user's criteria.
  • Recovery state with clear filters, broaden query, or browse alternatives.
  • Recovered state after criteria are changed.
  • Unavailable state if no alternatives exist.

Interaction

  • The UI must explain that no matches were found and identify the active constraints.
  • Recovery actions must be specific and immediately usable.
  • Clearing filters or changing search must update results and count predictably.

Accessibility

  • Announce result-count changes where search results update dynamically.
  • Keep recovery actions reachable near the empty state.
  • Focus should remain predictable after filters are cleared.
  • Recovery actions should be reachable in normal tab order.

Review

  • Does the user have a clear next action that can produce results again?
Interactive lab

Inspect the states before you copy the pattern

Recover from no results

Create an empty result set and inspect whether the recovery path is obvious.

No-results recovery
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Zero-result state that preserves the user's criteria.

Keyboard / Access

Focus should remain predictable after filters are cleared.

Avoid Generating

Showing a blank list with no explanation.

Evidence trail

Source-backed claims behind this guidance

Maersk Design System Handling No Results

Maersk Design System - checked

Maersk guidance identifies causes of no-results states and recommends clear feedback plus recovery actions for search and filtering.

GOV.UK Design System Patterns

Government Digital Service - checked

Service guidance emphasizes helping users recover from validation and task dead ends.

Full agent/debug reference

Problem Context

  • A valid search, filter, or browse action produces zero visible items.
  • The user may be able to broaden, correct, or redirect their task.

Selection Rules

  • Choose no-results recovery whenever search or filters can produce an empty set.
  • Prefer an error state when the absence is caused by system failure rather than valid criteria.
  • Prefer an empty-state onboarding pattern when the user has not created or received any data yet.

Required States

  • Zero-result state that preserves the user's criteria.
  • Recovery state with clear filters, broaden query, or browse alternatives.
  • Recovered state after criteria are changed.
  • Unavailable state if no alternatives exist.

Interaction Contract

  • The UI must explain that no matches were found and identify the active constraints.
  • Recovery actions must be specific and immediately usable.
  • Clearing filters or changing search must update results and count predictably.

Implementation Checklist

  • Show the query or filters that caused zero results.
  • Offer at least one direct recovery action.
  • Do not erase the user's input without consent.
  • Distinguish zero results from network or permission errors.

Common Generated-UI Mistakes

  • Showing a blank list with no explanation.
  • Resetting all criteria automatically.
  • Offering generic help that does not change the result set.

Critique Questions

  • Does the user have a clear next action that can produce results again?
Accessibility
  • Announce result-count changes where search results update dynamically.
  • Keep recovery actions reachable near the empty state.
Keyboard Behavior
  • Focus should remain predictable after filters are cleared.
  • Recovery actions should be reachable in normal tab order.
Variants
  • Clear all filters
  • Suggested query
  • Spell correction
  • Browse categories
  • Contact support

Verification

Last verified: