What the person is doing
A valid search, filter, or browse action produces zero visible items.
Foundation · lesson 5 of 20 · Search, Browse, And Discovery
No-results recovery
Underlying principle: Discovery supports several starting points: a known term, a broad category, a partial memory, or a set of constraints. The interface helps people refine their understanding while they search.
Help users recover when their own search or filters excluded all results.
Study the interaction
Follow the task before choosing the component
Discovery supports several starting points: a known term, a broad category, a partial memory, or a set of constraints. The interface helps people refine their understanding while they search.
What the interface must communicate
Help users recover when their own search or filters excluded all results.
Zero-result state that preserves the user's criteria.
What to look for
Does the user have a clear next action that can produce results again?
Recovery actions must be specific and immediately usable.
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
- The state is caused by an error rather than valid empty results.
Problem it prevents
A valid search, filter, or browse action produces zero visible items.
Test the behavior
Try strong and weak versions of the interaction
Open the working example, try its controls, and compare the behavior against the decision guidance.
In the lab you can
Launch No-results recovery in the lab - switch between strong UI, weak UI, strong UX, and weak UX;
- trigger required, empty, loading, error, and recovery states;
- inspect keyboard and accessibility expectations beside the demo.
Pattern anatomy
What a strong implementation has to make clear
A valid search, filter, or browse action produces zero visible items.
Help users recover when their own search or filters excluded all results.
Zero-result state that preserves the user's criteria.
Suggesting irrelevant alternatives.
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.
Weak implementation
Vague, hidden, hard to recover from
- Huge empty state that hides active filters.
- Telling users nothing exists when filters caused the state.
- Suggesting irrelevant alternatives.
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.
Interaction
- 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?
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.
Carbon Design System Empty States Pattern
IBM Carbon Design System - checked
Carbon distinguishes user-action empty states such as no search results from first-use empty states and system issue states.
Scottish Government Design System Search Filters
Scottish Government Design System - checked
Scottish Government guidance supports visible search tags, removing one filter, clear-all filters, and understandable screen-reader labels.
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
Source trail checked: