Use search scope selector when users must choose the corpus to search, basic search for the query input and result retrieval, filter panel for narrowing returned results by attributes, and tabs for switching visible sections or result-type views.
Use search scope selector when users must choose the corpus to search, basic search for the query input and result retrieval, filter panel for narrowing returned results by attributes, and tabs for switching visible sections or result-type views.
Practice the judgment: Imagine this situation: The search runs only within the current site or repository, but the UI looks like it searched the whole product. 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 →| Dimension | Search scope selector | Basic search | Filter panel | Tabs |
|---|---|---|---|---|
| UI or UX | UI + UX - Control that selects which corpus, location, or result source a query searches | 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 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. | 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 a search scope selector when the same query can search meaningfully different content sources and users need to control where the system looks. | 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. | Avoid tabs when users must compare panels, read panels sequentially, or complete required workflow steps. |
| Good UI | A knowledge search field includes scope buttons for All knowledge, Current workspace, Cases, and People with the active scope repeated above results. | 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 | The product silently searches the current channel while the user assumes all workspace messages were searched. | 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. | Tabs wrap unpredictably or look like unrelated buttons. |
| 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. | 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. | Keyboard users can move focus with arrows, activate with Enter or Space, and then reach the selected panel. |
| Bad UX | Switching from This repository to All GitHub clears the query and leaves users unsure whether anything ran. | 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 | The same query can search different repositories, sites, workspaces, spaces, channels, result types, teams, or organization-wide indexes. | 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 | There is only one searchable corpus and scope selection would be decorative. | 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 | Default scope state based on current location or product-wide policy. | Empty query state. | Applied state with active-filter count, result count, and removable applied criteria near the results. | Default active tab and visible panel. |
| Accessibility burden | Use a labelled fieldset, radio group, select, or tablist only when the semantics match the scope interaction. | 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 | Putting scope only in placeholder text, which disappears when users type. | 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. | Using tabs as a primary site navigation system. |