UI + UX Search, Browse, And Discovery standard

Browse by category

Provide a maintained category taxonomy with clear labels, descriptions, hierarchy, counts, examples, popular destinations, current-location cues, and recovery from empty or confusing categories.

Decision first

Choose this pattern when the problem matches

Use when

  • Users are exploring a broad catalog, service directory, help center, learning library, product collection, or content repository.
  • Users can choose from recognizable topic areas more easily than inventing search terms.
  • A maintained taxonomy or category model exists and can be represented with user-facing labels.
  • Users need orientation across parent and child groups before selecting a final item.

Avoid when

  • The collection is small enough for a simple list.
  • Users usually know exact names, identifiers, or phrases and search is faster.
  • The category structure reflects internal ownership rather than user mental models.
  • Categories are unstable, empty, or automatically generated with no review process.
  • The task is only narrowing an existing result set by attributes.

Problem it prevents

Users need to explore a broad collection of services, articles, products, records, or learning resources, but they may not know the exact term to search for and a flat list is too large to scan.

Pattern anatomy

What a strong implementation has to make clear

User need

The collection contains enough destinations that a flat list, global navigation, or single search box would force users to guess terms or scan too much.

Pattern promise

Provide a maintained category taxonomy with clear labels, descriptions, hierarchy, counts, examples, popular destinations, current-location cues, and recovery from empty or confusing categories.

Required state

Top-level category state with clear names, descriptions, and enough examples or counts to choose.

Recovery path

Users cannot tell whether they are browsing categories, filtering results, or switching tabs.

Access contract

Use real links for categories that navigate and buttons only for local expansion.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A services page lists Benefits, Housing and local services, Money and tax, and Driving and transport with one-line descriptions and top tasks for each category.
  • A learning catalog shows Products, Roles, Certifications, and Learning paths, each with counts and examples of what users will find inside.
  • A user who does not know the form name chooses Money and tax, sees Self Assessment and VAT subcategories, and reaches the correct service without writing a search query.
  • A user opens a category with no current matches and sees a message that the topic was merged into Benefits, with a route to the parent and a search fallback.
Weak implementation

Vague, hidden, hard to recover from

  • A category grid uses internal teams such as Operations, CX, Growth, Platform, and Enablement without saying what users can find there.
  • Cards named Support, Help, Resources, and Information overlap and provide no descriptions.
  • Users choose Customers because they need customer support, but the category contains only internal CRM configuration articles.
  • A category page lists hundreds of links alphabetically without subcategories, most-used tasks, or search recovery.
UI guidance
  • Render categories as a scannable list or grid with user-facing names, short descriptions, item counts or example contents, and clear parent-child location cues.
  • Show subcategories, popular destinations, sibling categories, and search fallback without making users open every category to understand what it contains.
UX guidance
  • Use browse by category when users can recognize a topic or service area but may not know the exact query, item name, or filter value.
  • Maintain the taxonomy with evidence from content tagging, search terms, analytics, tree testing, support questions, and editorial review so category labels stay distinct and useful.
Implementation contract

What the implementation must handle

States

  • Top-level category state with clear names, descriptions, and enough examples or counts to choose.
  • Category selected state showing parent, current category, children, and relevant destinations.
  • Subcategory state with a clear route back to parent and siblings.
  • Empty or merged category state with explanation and recovery to parent, search, or replacement category.

Interaction

  • Activating a category navigates to a category view or expands a category hierarchy, not a filter chip on an unrelated result set.
  • The selected category, parent path, and available children update together so users know where they are in the taxonomy.
  • Category descriptions accurately summarize the content behind the category and are updated when the contents change.
  • Most-viewed or popular links do not replace the full category path unless the page explicitly says they are shortcuts.

Accessibility

  • Use real links for categories that navigate and buttons only for local expansion.
  • Make category labels descriptive enough to make sense in a screen-reader link list.
  • Do not rely on icons, colors, or card position alone to communicate category meaning.
  • Expose the current category, parent path, and result or item count in text.

Review

  • Can users predict what they will find inside each category without opening it?
  • Are category labels based on user language and content meaning rather than team ownership?
  • How many choices appear at each level, and does that exceed what users can scan?
  • What happens when a category has no content, stale content, or content users cannot access?
Interactive lab

Inspect the states before you copy the pattern

Browse a category taxonomy

Choose categories, drill into child topics, and check whether labels, counts, popular tasks, and empty-category recovery stay clear.

Browse by category
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

Top-level category state with clear names, descriptions, and enough examples or counts to choose.

Keyboard / Access

Tab reaches category links, subcategory links, parent route, search fallback, and popular-task shortcuts in a predictable order.

Avoid Generating

Using the organization chart as the category taxonomy.

Evidence trail

Source-backed claims behind this guidance

GOV.UK topic taxonomy principles

Government Digital Service - checked

GOV.UK taxonomy principles document hierarchy, category naming, topic limits, browseability, and tagging accuracy.

Full agent/debug reference

Problem Context

  • The collection contains enough destinations that a flat list, global navigation, or single search box would force users to guess terms or scan too much.
  • Users can recognize meaningful topic areas, service areas, resource types, or product families if the taxonomy uses their language.
  • The category structure needs ongoing content tagging and review because categories can drift, overlap, empty out, or reflect internal ownership rather than user mental models.

Selection Rules

  • Choose browse by category when the primary task is exploratory recognition: users know the area but not the exact item name or query.
  • Use a category landing page when categories lead to multiple destinations, subcategories, or task pages that need explanation before selection.
  • Limit each visible category level enough for scanning; when there are too many children, split, group, prioritize, or add within-category search.
  • Name categories by what the content is about, not by the department, owner, content format, or backend index that produced it.
  • Add short descriptions or examples when category names could overlap or when users need help predicting the contents.
  • Show item counts, most viewed tasks, recently updated content, or representative examples only when they help users choose and stay current.
  • Provide a clear parent path, sibling categories, and back route so users can recover from the wrong category.
  • Omit or explain empty categories; do not present an empty child page as a valid browse destination.
  • Use basic search when users know words or identifiers; use filter panel after users already have a result set; use tabs only for sibling panels in one page context.
  • Review tagging accuracy by spot-checking category contents and correcting misplaced items.

Required States

  • Top-level category state with clear names, descriptions, and enough examples or counts to choose.
  • Category selected state showing parent, current category, children, and relevant destinations.
  • Subcategory state with a clear route back to parent and siblings.
  • Empty or merged category state with explanation and recovery to parent, search, or replacement category.
  • Popular or most-viewed destination state that remains visibly secondary to the taxonomy.
  • Long category list state with grouping, prioritization, or search-within-category.
  • Mobile compact state where hierarchy and descriptions remain scannable.
  • Mis-tagged or stale category review state for editors or maintainers.
  • Deep-linked category state that restores location and content.

Interaction Contract

  • Activating a category navigates to a category view or expands a category hierarchy, not a filter chip on an unrelated result set.
  • The selected category, parent path, and available children update together so users know where they are in the taxonomy.
  • Category descriptions accurately summarize the content behind the category and are updated when the contents change.
  • Most-viewed or popular links do not replace the full category path unless the page explicitly says they are shortcuts.
  • Search fallback preserves the selected category only when it genuinely searches within that category and labels that scope.
  • Empty categories explain whether content moved, no content exists, or the user lacks permission, and provide a next route.
  • Changing category clears stale item selections, counts, and previews that belonged to the previous category.

Implementation Checklist

  • Define the category taxonomy, parent-child relationships, category labels, descriptions, item ownership, and tagging rules before building the UI.
  • Use analytics, search logs, support queries, card sorting, tree testing, and content audits to validate category names and hierarchy.
  • Show category descriptions, example items, counts, or popular links where labels need disambiguation.
  • Render category links with normal navigation semantics and preserve the hierarchy in URL, breadcrumb, or page heading.
  • Keep categories mutually exclusive enough for discovery, and add cross-links only where users reasonably expect content in more than one place.
  • Spot-check category contents after imports, migrations, or automated tagging.
  • Design empty, merged, permission-limited, and stale category states before launch.
  • Test keyboard navigation, screen reader link lists, mobile wrapping, long labels, and categories with few or many children.

Common Generated-UI Mistakes

  • Using the organization chart as the category taxonomy.
  • Showing category cards without descriptions when labels overlap.
  • Treating categories as filters while navigating away and losing result context.
  • Leaving empty categories visible because the schema still has a category record.
  • Adding popular links without preserving the complete category path.
  • Putting the same content into many parent categories to avoid making taxonomy decisions.
  • Using icons or colors as the only way to distinguish category meaning.

Critique Questions

  • Can users predict what they will find inside each category without opening it?
  • Are category labels based on user language and content meaning rather than team ownership?
  • How many choices appear at each level, and does that exceed what users can scan?
  • What happens when a category has no content, stale content, or content users cannot access?
  • Do category pages show the parent path, sibling choices, and a route back to search?
  • How are tagging errors found and corrected after launch?
Accessibility
  • Use real links for categories that navigate and buttons only for local expansion.
  • Make category labels descriptive enough to make sense in a screen-reader link list.
  • Do not rely on icons, colors, or card position alone to communicate category meaning.
  • Expose the current category, parent path, and result or item count in text.
  • Keep descriptions concise so keyboard users are not forced through repeated long card text.
  • Use headings and landmarks to separate top-level categories, subcategories, popular tasks, and search fallback.
Keyboard Behavior
  • Tab reaches category links, subcategory links, parent route, search fallback, and popular-task shortcuts in a predictable order.
  • Enter activates category links with normal navigation behavior.
  • If categories expand inline, Enter or Space toggles expansion and focus remains near the expanded category.
  • After choosing a category, focus should land on the new category heading or status summary.
  • Escape closes local category overlays or drawers without changing the selected category.
  • Browser back and forward restore category location and selected child state.
Variants
  • Top-level category directory
  • Topic browse page
  • Service category page
  • Product category grid
  • Learning catalog taxonomy
  • A to Z category browse
  • Most-viewed category shortcuts
  • Category with child topics
  • Search within category
  • Merged category recovery

Verification

Last verified: