Back to compare picker

Advanced search vs Basic search vs Filter panel vs Search scope selector

Use advanced search when users must construct precise fielded, Boolean, grouped, or syntax-backed queries; use basic search for one query input, filter panel for narrowing a returned result set by visible controls, and search scope selector for choosing where the query runs.

Learn the decision

Match the interaction to the person's task

Use advanced search when users must construct precise fielded, Boolean, grouped, or syntax-backed queries; use basic search for one query input, filter panel for narrowing a returned result set by visible controls, and search scope selector for choosing where the query runs.

Advanced search

Use it when: Expert or repeat users need precise retrieval across fields, operators, phrases, dates, ranges, exclusions, functions, or prior search history.

Make this state clear: Empty builder state with field, operator, value, and Boolean controls labelled.

Observe the result: A user adds Author contains Patel OR Journal equals Pediatrics, previews 28 matches, and saves the finished query after confirming the generated syntax.

Study the full pattern →

Basic search

Use it when: Users know a word, name, or identifier.

Make this state clear: Empty query state.

Observe the result: Users can type, revise, clear, and keep context while inspecting results.

Study the full pattern →

Filter panel

Use it when: Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.

Make this state clear: Applied state with active-filter count, result count, and removable applied criteria near the results.

Observe the result: 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.

Study the full pattern →

Search scope selector

Use it when: The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes.

Make this state clear: Default scope state based on current location or product-wide policy.

Observe the result: A user searches appeal in Current workspace, switches to All knowledge, and sees the same query rerun with a larger result count and broader source summary.

Study the full pattern →

Practice the judgment: Imagine this situation: A product labels a filter panel as Advanced search even though every control is a simple post-result filter. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Advanced searchBasic searchFilter panelSearch scope selector
UI or UX UI + UX - Structured query builder for fielded, Boolean, grouped, or syntax-backed searchesUI + UX - Search input and result listUI + UX - Grouped filter control panel for narrowing a current result setUI + UX - Control that selects which corpus, location, or result source a query searches
UI guidance Render advanced search as a labelled query-construction surface with visible field, operator, value, and Boolean join controls, plus a readable query preview that shows what will run.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 the active search scope near the search input and result summary, using user-facing corpus names such as Current workspace, All knowledge, This repository, or People.
UX guidance Use advanced search when users need precise retrieval across multiple fields, date ranges, exact phrases, exclusions, functions, prior searches, or grouped Boolean conditions.Help the person reach a clear task outcome.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.Use a search scope selector when the same query can search meaningfully different content sources and users need to control where the system looks.
Good UI A research database builder lets users choose Title/Abstract, enter a term, add it with AND or OR, preview the generated query, and see a count before leaving the page.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.A knowledge search field includes scope buttons for All knowledge, Current workspace, Cases, and People with the active scope repeated above results.
Bad UI A button named Advanced search opens the same one-line keyword input with a larger border.Results jump, resize, or use heavy borders that make scanning feel like reading a form.A panel mixes filter options, navigation links, sort controls, and saved views under one Filters heading.The product silently searches the current channel while the user assumes all workspace messages were searched.
Good UX A user adds Author contains Patel OR Journal equals Pediatrics, previews 28 matches, and saves the finished query after confirming the generated syntax.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.A user searches appeal in Current workspace, switches to All knowledge, and sees the same query rerun with a larger result count and broader source summary.
Bad UX A user previews a query count, changes the scope selector, and the stale count remains as if the same corpus was searched.Search silently changes unrelated filters.Applying a filter silently resets the query, sort order, current page, and view density.Switching from This repository to All GitHub clears the query and leaves users unsure whether anything ran.
Best fit Expert or repeat users need precise retrieval across fields, operators, phrases, dates, ranges, exclusions, functions, or prior search history.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.The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes.
Avoid when Most users only need one keyword box and a ranked result list.The task is choosing a command with side effects.The result set is small enough that scanning is faster than filtering.There is only one searchable corpus and scope selection would be decorative.
Required state Empty builder state with field, operator, value, and Boolean controls labelled.Empty query state.Applied state with active-filter count, result count, and removable applied criteria near the results.Default scope state based on current location or product-wide policy.
Accessibility burden Label each field, operator, value input, Boolean joiner, grouping control, generated query, and validation message with stable accessible names.The input has a stable accessible name.Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.Use a labelled fieldset, radio group, select, or tablist only when the semantics match the scope interaction.
Common misuse Returning zero results for parse errors instead of showing the broken clause.Using placeholder text as the only label.Using a filter panel as a navigation drawer that sends users to different pages instead of narrowing the current data set.Putting scope only in placeholder text, which disappears when users type.

Advanced search

UI or UX
UI + UX - Structured query builder for fielded, Boolean, grouped, or syntax-backed searches
UI guidance
Render advanced search as a labelled query-construction surface with visible field, operator, value, and Boolean join controls, plus a readable query preview that shows what will run.
UX guidance
Use advanced search when users need precise retrieval across multiple fields, date ranges, exact phrases, exclusions, functions, prior searches, or grouped Boolean conditions.
Good UI
A research database builder lets users choose Title/Abstract, enter a term, add it with AND or OR, preview the generated query, and see a count before leaving the page.
Bad UI
A button named Advanced search opens the same one-line keyword input with a larger border.
Good UX
A user adds Author contains Patel OR Journal equals Pediatrics, previews 28 matches, and saves the finished query after confirming the generated syntax.
Bad UX
A user previews a query count, changes the scope selector, and the stale count remains as if the same corpus was searched.
Best fit
Expert or repeat users need precise retrieval across fields, operators, phrases, dates, ranges, exclusions, functions, or prior search history.
Avoid when
Most users only need one keyword box and a ranked result list.
Required state
Empty builder state with field, operator, value, and Boolean controls labelled.
Accessibility burden
Label each field, operator, value input, Boolean joiner, grouping control, generated query, and validation message with stable accessible names.
Common misuse
Returning zero results for parse errors instead of showing the broken clause.

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 the person reach a clear task outcome.
Good UI
A clearly labeled search field with result count and results placed directly below.
Bad UI
Results jump, resize, or use heavy borders that make scanning feel like reading a form.
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 panel mixes filter options, navigation links, sort controls, and saved views under one Filters heading.
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
Applied state with active-filter count, result count, and removable applied criteria near the results.
Accessibility burden
Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.
Common misuse
Using a filter panel as a navigation drawer that sends users to different pages instead of narrowing the current data set.

Search scope selector

UI or UX
UI + UX - Control that selects which corpus, location, or result source a query searches
UI guidance
Render the active search scope near the search input and result summary, using user-facing corpus names such as Current workspace, All knowledge, This repository, or People.
UX guidance
Use a search scope selector when the same query can search meaningfully different content sources and users need to control where the system looks.
Good UI
A knowledge search field includes scope buttons for All knowledge, Current workspace, Cases, and People with the active scope repeated above results.
Bad UI
The product silently searches the current channel while the user assumes all workspace messages were searched.
Good UX
A user searches appeal in Current workspace, switches to All knowledge, and sees the same query rerun with a larger result count and broader source summary.
Bad UX
Switching from This repository to All GitHub clears the query and leaves users unsure whether anything ran.
Best fit
The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes.
Avoid when
There is only one searchable corpus and scope selection would be decorative.
Required state
Default scope state based on current location or product-wide policy.
Accessibility burden
Use a labelled fieldset, radio group, select, or tablist only when the semantics match the scope interaction.
Common misuse
Putting scope only in placeholder text, which disappears when users type.
Decision rules
  • Prefer advanced search when the user needs multiple clauses such as field, operator, value, Boolean joiner, exact phrase, date range, exclusion, proximity, saved syntax, or search-history combination.
  • Prefer basic search when one plain-language query and a result list are enough, and exposing field names, operators, or query syntax would slow most users down.
  • Prefer filter panel when users are already looking at a result set and need to include or exclude records through visible controls without learning a query grammar.
  • Prefer search scope selector when the same query needs to run against a different corpus, repository, site, channel, people index, or organization index before filters or clauses are interpreted.
  • Advanced search should show a readable query preview or generated syntax so expert users can inspect exactly what will run before they submit it.
  • If the builder emits syntax, validate missing values, unmatched quotes, unsupported operators, incompatible fields, and ambiguous grouping before running the query.
  • When users add, remove, or reorder clauses, preserve the raw query, selected fields, result count preview, and search history separately from filters, sort, and scope.
  • Do not collapse advanced search into a generic filter drawer; clauses can create nested logic, combine prior searches, and change query semantics in ways a normal filter panel cannot.
  • Do not use advanced search for simple browse categories or tabs; those should remain scannable navigation choices rather than requiring syntax.
  • Offer a return path from advanced search to basic search when users only need a plain keyword query, but do not silently discard expert clauses.
Inspect live examples
Failure modes
  • A product labels a filter panel as Advanced search even though every control is a simple post-result filter.
  • The query builder runs malformed syntax and returns zero results instead of explaining the broken clause.
  • Users add OR clauses but the UI hides grouping, so the system runs a broader query than intended.
  • Switching back to basic search silently deletes the fielded query and search history.
  • Advanced query examples use internal field names that do not match visible result fields.
  • The builder lets users select a field and operator combination that the search backend cannot execute.

Saved items