Browse by category vs Basic search vs Filter panel vs Tabs

Prefer browse by category when users do not know the exact term to search for but can recognize a topic, service area, product family, or content type from a curated taxonomy.

Browse by category live example Basic search live example Filter panel live example Tabs live example

Decision dimensions

Dimension	Browse by category	Basic search	Filter panel	Tabs
UI or UX	UI + UX - Taxonomy-based category navigation for exploring a collection before choosing a destination	UI + UX - Search input and result list	UI + UX - Grouped filter control panel for narrowing a current result set	UI + UX - Section-switching component
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.	Render a labeled search field, result count, matching rows, and clear action.	Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results.	Render a tablist with short tab labels, selected tab styling, visible keyboard focus, and a single associated tabpanel that is visually connected to the active tab.
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.	Help users find known content without browsing every category.	Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values.	Help users switch between sibling sections in the same page context without changing routes or losing local work.
Good UI	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 clearly labeled search field with result count and results placed directly below.	A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results.	Tab labels are short, active tab is obvious, focused tab is distinguishable, and panel content is visually attached to the selected tab.
Bad UI	A category grid uses internal teams such as Operations, CX, Growth, Platform, and Enablement without saying what users can find there.	Search input hidden behind only an icon with no label.	A filter drawer closes with no active count, leaving users unaware that filters are still hiding records.	Tabs wrap unpredictably or look like unrelated buttons.
Good UX	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.	Users can type, revise, clear, and keep context while inspecting results.	A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable.	Users switch between sibling sections without leaving page context or losing panel-local notes.
Bad UX	Users choose Customers because they need customer support, but the category contains only internal CRM configuration articles.	Search silently changes unrelated filters.	Applying a filter silently resets the query, sort order, current page, and view density.	Using tabs as primary navigation to unrelated pages.
Best fit	Users are exploring a broad catalog, service directory, help center, learning library, product collection, or content repository.	Users know a word, name, or identifier.	Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.	Users switch between sibling panels frequently.
Avoid when	The collection is small enough for a simple list.	The task is choosing a command with side effects.	The result set is small enough that scanning is faster than filtering.	The destinations are unrelated pages.
Required state	Top-level category state with clear names, descriptions, and enough examples or counts to choose.	Empty query state.	Default state with no user-applied filters and an explicit result count.	Default active tab and visible panel.
Accessibility burden	Use real links for categories that navigate and buttons only for local expansion.	The input has a stable accessible name.	Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.	Expose the active tab and associated panel.
Common misuse	Using the organization chart as the category taxonomy.	Using placeholder text as the only label.	Hiding active filters inside a closed panel with no count, chips, or result-state summary.	Using tabs as a primary site navigation system.

Browse by category

UI or UX: UI + UX - Taxonomy-based category navigation for exploring a collection before choosing a destination
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.
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.
Good UI: 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.
Bad UI: A category grid uses internal teams such as Operations, CX, Growth, Platform, and Enablement without saying what users can find there.
Good UX: 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.
Bad UX: Users choose Customers because they need customer support, but the category contains only internal CRM configuration articles.
Best fit: Users are exploring a broad catalog, service directory, help center, learning library, product collection, or content repository.
Avoid when: The collection is small enough for a simple list.
Required state: Top-level category state with clear names, descriptions, and enough examples or counts to choose.
Accessibility burden: Use real links for categories that navigate and buttons only for local expansion.
Common misuse: Using the organization chart as the category taxonomy.

Basic search

UI or UX: UI + UX - Search input and result list
UI guidance: Render a labeled search field, result count, matching rows, and clear action.
UX guidance: Help users find known content without browsing every category.
Good UI: A clearly labeled search field with result count and results placed directly below.
Bad UI: Search input hidden behind only an icon with no label.
Good UX: Users can type, revise, clear, and keep context while inspecting results.
Bad UX: Search silently changes unrelated filters.
Best fit: Users know a word, name, or identifier.
Avoid when: The task is choosing a command with side effects.
Required state: Empty query state.
Accessibility burden: The input has a stable accessible name.
Common misuse: Using placeholder text as the only label.

Filter panel

UI or UX: UI + UX - Grouped filter control panel for narrowing a current result set
UI guidance: Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results.
UX guidance: Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values.
Good UI: A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results.
Bad UI: A filter drawer closes with no active count, leaving users unaware that filters are still hiding records.
Good UX: A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable.
Bad UX: Applying a filter silently resets the query, sort order, current page, and view density.
Best fit: Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.
Avoid when: The result set is small enough that scanning is faster than filtering.
Required state: Default state with no user-applied filters and an explicit result count.
Accessibility burden: Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.
Common misuse: Hiding active filters inside a closed panel with no count, chips, or result-state summary.

Tabs

UI or UX: UI + UX - Section-switching component
UI guidance: Render a tablist with short tab labels, selected tab styling, visible keyboard focus, and a single associated tabpanel that is visually connected to the active tab.
UX guidance: Help users switch between sibling sections in the same page context without changing routes or losing local work.
Good UI: Tab labels are short, active tab is obvious, focused tab is distinguishable, and panel content is visually attached to the selected tab.
Bad UI: Tabs wrap unpredictably or look like unrelated buttons.
Good UX: Users switch between sibling sections without leaving page context or losing panel-local notes.
Bad UX: Using tabs as primary navigation to unrelated pages.
Best fit: Users switch between sibling panels frequently.
Avoid when: The destinations are unrelated pages.
Required state: Default active tab and visible panel.
Accessibility burden: Expose the active tab and associated panel.
Common misuse: Using tabs as a primary site navigation system.

Decision rules

Prefer browse by category when users do not know the exact term to search for but can recognize a topic, service area, product family, or content type from a curated taxonomy.
Prefer basic search when users can express the item with keywords, names, identifiers, or phrases and expect ranked matching results.
Prefer filter panel when users already have a list or search result set and need to narrow it by attributes such as status, date, owner, price, or type.
Prefer tabs when the choices are sibling panels inside the same page context rather than navigable category destinations.
Category pages should expose parent-child hierarchy, category descriptions, child counts or examples, current location, and an escape path to search.
Do not use browse categories as a dumping ground for organizational departments, content formats, or user types unless those are the actual user-facing taxonomy.
Keep category labels mutually distinguishable; split, merge, rename, or qualify confusing categories before treating the browse path as complete.
When a category has no current content, omit it, explain it, or route to a useful parent; do not show an empty category as a successful destination.
Use related links for a small set of optional onward links from a specific page; use browse categories for systematic exploration across many destinations.
Use advanced search when the user is constructing Boolean or fielded query logic rather than moving through a taxonomy.

Inspect live examples

Browse by category Basic search Filter panel Tabs

Failure modes

Categories mirror the organization chart instead of user language, so users must understand internal ownership to browse.
A category opens to an empty list with no parent, sibling, or search recovery path.
Labels overlap, such as Support, Help, and Services, without descriptions or disambiguation.
Category cards act like filters on the current list but navigate away without preserving user context.
Tabs are used for deep category navigation and hide the parent-child location.
Popular links replace the taxonomy without showing how they relate to the full category structure.