UX Patterns Guide
UI + UX Search, Browse, And Discovery standard

Basic search

Provide a labeled search field, run the query against relevant content, and show result count, matches, and recovery paths.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users know a word, name, or identifier.
  • The result set can be meaningfully ranked or filtered.

Avoid when

  • The task is choosing a command with side effects.
  • The content set is tiny and easier to scan.

Problem it prevents

Users need to find matching content without browsing every category or page.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • 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.
Launch Basic search in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The content set is larger than users can comfortably scan.

Pattern promise

Provide a labeled search field, run the query against relevant content, and show result count, matches, and recovery paths.

Required state

Empty query state.

Recovery path

Searching the wrong scope without telling users.

Access contract

The input has a stable accessible name.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A clearly labeled search field with result count and results placed directly below.
  • Matched rows use calm highlighting and stable spacing so scanning stays easy.
  • Users can type, revise, clear, and keep context while inspecting results.
  • No-results state offers query correction, clearing, or broader search.
Weak implementation

Vague, hidden, hard to recover from

  • Search input hidden behind only an icon with no label.
  • Results jump, resize, or use heavy borders that make scanning feel like reading a form.
  • Search silently changes unrelated filters.
  • Opening a result destroys the query and makes returning impossible.
UI guidance
  • Render a labeled search field, result count, matching rows, and clear action.
  • Keep result updates visually close to the query that caused them.
UX guidance
  • Help users find known content without browsing every category.
  • Preserve query context while users inspect, refine, or recover from no results.
Implementation contract

What the implementation must handle

States

  • Empty query state.
  • Loading or updating results state.
  • Matching results state.
  • No matches state with recovery.

Interaction

  • Typing or submitting a query changes the visible result set predictably.
  • The user can clear or revise the query.
  • Result labels explain what will open or happen.

Accessibility

  • The input has a stable accessible name.
  • Result count changes are communicated without excessive announcements.
  • Enter submits when search is explicit.
  • Escape or a clear button can reset the query when provided.

Review

  • Can users predict what content the search covers?
Evidence trail

Source-backed claims behind this guidance

MOJ Design System Search

Ministry of Justice - checked

MOJ search guidance supports a labeled search field, submit action, hints, and no-results recovery for search tasks.

GOV.UK Design System Patterns

Government Digital Service - checked

GOV.UK patterns emphasize task-oriented search, filtering, and recovery states.

Full agent/debug reference

Problem Context

  • The content set is larger than users can comfortably scan.
  • Users can describe what they need with words or identifiers.

Selection Rules

  • Choose basic search when the task is content retrieval.
  • Show results and counts close to the search input.
  • Preserve the query while users inspect or refine results.

Required States

  • Empty query state.
  • Loading or updating results state.
  • Matching results state.
  • No matches state with recovery.

Interaction Contract

  • Typing or submitting a query changes the visible result set predictably.
  • The user can clear or revise the query.
  • Result labels explain what will open or happen.

Implementation Checklist

  • Provide a visible label or accessible name.
  • Show result count and matching items.
  • Keep filters and sort behavior clear.
  • Provide no-results recovery.

Common Generated-UI Mistakes

  • Using placeholder text as the only label.
  • Returning no feedback while results update.
  • Making search change unrelated filters silently.

Critique Questions

  • Can users predict what content the search covers?
Accessibility
  • The input has a stable accessible name.
  • Result count changes are communicated without excessive announcements.
Keyboard Behavior
  • Enter submits when search is explicit.
  • Escape or a clear button can reset the query when provided.
Variants
  • Submit search
  • Live search
  • Scoped search

Verification

Source trail checked:

Saved items