UX Patterns Guide

Foundation · lesson 2 of 20 · Search, Browse, And Discovery

Basic search

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.

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

Start with the decision

Does this fit your task?

Users know a word, name, or identifier.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
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.

01 / Recognize the need

What the person is doing

The content set is larger than users can comfortably scan.

02 / Design the response

What the interface must communicate

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

Empty query state.

03 / Judge the outcome

What to look for

Can users predict what content the search covers?

Typing or submitting a query changes the visible result set predictably.

Practice this pattern: Sketch basic search for this situation: Users know a word, name, or identifier. Include this state: Empty query state. Review your sketch with this question: Can users predict what content the search covers?

Study the Search, Browse, And Discovery family →Read the underlying principle →
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

The content set is larger than users can comfortably scan.

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
  • 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.

Failure to inspect

Destroying the query after opening a result.

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.
Weak implementation

Vague, hidden, hard to recover from

  • 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.
  • Destroying the query after opening a result.
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.

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.
  • 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