UX Patterns Guide

Application · lesson 8 of 20 · Search, Browse, And Discovery

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

Expose filter dimensions near the result set, let users combine constraints, and make applied filters visible and removable.

Start with the decision

Does this fit your task?

The data set has structured attributes users understand.

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

A result set is too large to scan directly.

02 / Design the response

What the interface must communicate

Expose filter dimensions near the result set, let users combine constraints, and make applied filters visible and removable.

Unfiltered state with result count and available facets.

03 / Judge the outcome

What to look for

Can the user see exactly why the current results are being shown or excluded?

Applying or removing a facet updates the result count and preserves visible applied filters.

Practice this pattern: Sketch faceted search for this situation: The data set has structured attributes users understand. Include this state: Unfiltered state with result count and available facets. Review your sketch with this question: Can the user see exactly why the current results are being shown or excluded?

Study the Search, Browse, And Discovery family →Read the underlying principle →
Decision first

Choose this pattern when the problem matches

Use when

  • The data set has structured attributes users understand.
  • Users need to explore, compare, or progressively narrow results.

Avoid when

  • The result set is small enough that filtering adds complexity.
  • The available facets are system-centric rather than user meaningful.

Problem it prevents

A result set is too large to scan directly.

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 Faceted search in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

A result set is too large to scan directly.

Pattern promise

Expose filter dimensions near the result set, let users combine constraints, and make applied filters visible and removable.

Required state

Unfiltered state with result count and available facets.

Failure to inspect

Hiding applied filters.

Access contract

Filter groups need clear labels and state.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Facet groups, counts, selected chips, result count, and clear controls are visually grouped.
  • Filters use consistent spacing and avoid heavy borders around every option.
  • Users can add, remove, combine, and clear facets while understanding result count changes.
Weak implementation

Vague, hidden, hard to recover from

  • Facet panel overwhelms the results with dense unchecked options.
  • Selected filters are hidden inside collapsed menus.
  • Changing filters resets unrelated query or sort silently.
  • Hiding applied filters.
UI guidance
  • Render filter controls, active chips, counts, result list, clear controls, and no-results state.
  • Keep selected facets visible while results update.
UX guidance
  • Help users progressively narrow a large result set without losing orientation.
  • Support recovery when filter combinations become too restrictive.
Implementation contract

What the implementation must handle

States

  • Unfiltered state with result count and available facets.
  • Filtered state with applied constraints visible.
  • Zero-result state with clear recovery actions.
  • Facet loading or disabled state when counts are recalculating.

Interaction

  • Applying or removing a facet updates the result count and preserves visible applied filters.
  • Users can remove individual filters and clear all filters.

Accessibility

  • Filter groups need clear labels and state.
  • All filter controls must be keyboard reachable.
  • Applying or clearing filters should preserve a predictable focus position.

Review

  • Can the user see exactly why the current results are being shown or excluded?
Evidence trail

Source-backed claims behind this guidance

MOJ Design System Filter

Ministry of Justice - checked

MOJ filter guidance supports visible selected filters, clear filters, apply behavior, and filtering lists or search results.

Carbon Design System Filtering Pattern

IBM Carbon Design System - checked

Carbon filtering guidance supports multi-category filters, batch or instant updates, visible applied-filter indicators, and reset behavior.

GOV.UK Design System Patterns

Government Digital Service - checked

Service patterns distinguish task-oriented narrowing and recovery from raw visual filtering.

Full agent/debug reference

Problem Context

  • A result set is too large to scan directly.
  • Items have structured attributes that users understand and can combine.

Selection Rules

  • Choose faceted search when users need to progressively narrow a large set by multiple attributes.
  • Prefer basic search when users usually know the exact item or query.
  • Prefer category browse when users are exploring broad groups rather than combining constraints.

Required States

  • Unfiltered state with result count and available facets.
  • Filtered state with applied constraints visible.
  • Zero-result state with clear recovery actions.
  • Facet loading or disabled state when counts are recalculating.

Interaction Contract

  • Applying or removing a facet updates the result count and preserves visible applied filters.
  • Users can remove individual filters and clear all filters.
  • Facet labels should be user-facing concepts, not internal system names.

Implementation Checklist

  • Show applied filters near the results.
  • Provide clear-one and clear-all actions.
  • Keep the result count visible after filtering.
  • Prevent combinations from becoming dead ends without recovery.

Common Generated-UI Mistakes

  • Using internal database labels as facets.
  • Hiding applied filters in a collapsed drawer.
  • Letting filters produce zero results without a path to broaden.

Critique Questions

  • Can the user see exactly why the current results are being shown or excluded?
Accessibility
  • Applied filters should be announced and removable without pointer-only interaction.
  • Filter groups need clear labels and state.
Keyboard Behavior
  • All filter controls must be keyboard reachable.
  • Applying or clearing filters should preserve a predictable focus position.
Variants
  • Sidebar facets
  • Filter drawer
  • Filter chips
  • Batch-applied filters
  • Instant filters

Verification

Source trail checked:

Saved items