What makes search work in a product?

Forgiving matching and a useful empty result. Most in-product search fails on exact matching — a typo, a plural, or the user's word rather than yours returns nothing — and then offers a dead end instead of a suggestion. Both are fixable without touching the ranking.

Should search return results as you type?

Where the set is small and the query is cheap, yes: seeing results narrow teaches what the search covers. Where each query is expensive, debounce it and show a clear pending state. What must not happen is results flickering behind the typing, which makes the list unreadable.

What is the difference between search and filter?

Search matches free text against content, for when you know a word. Filters narrow by known attributes, for when you know a dimension. Products offering only search make people guess the internal vocabulary; products offering only filters make people hunt for a record they could have named.

Should search look inside collapsed or paginated content?

In-product search should, and browser find cannot. Text inside a collapsed accordion or on page seven is invisible to the browser's own search, which is why a product with substantial hidden content needs its own search rather than relying on the one people already have.

What should a search with no results show?

What was searched, why it might have failed, and a way forward: a corrected spelling, a broader scope, or the nearest matches. A bare "No results" is a dead end, and it is the screen where people conclude the product does not contain what they are looking for when usually it does.

Search (UI)

The control and the results behind it — where people go when they know what they want and cannot find it.

UI Components

Search is where people go when they know what they want and cannot find it. That makes it a fallback for information architecture and, in a large product, a primary route in its own right.

It is also the component most often shipped as a text box wired to an exact-match query, which works for the team who knows the vocabulary and fails for everyone else.

Matching has to forgive

Most in-product search fails before ranking is ever relevant.

Typos. One transposed letter returning nothing is the single most common failure. Fuzzy matching at a modest edit distance fixes the bulk of it.

Plurals and stems. "Invoices" should find "invoice".

The user's word, not yours. People search for what they call it. Synonym mapping — a short list maintained by whoever reads support tickets — closes more gaps than any algorithm change, because the gaps are specific and few.

Partial matches. Searching "acme" should find "Acme Corporation Ltd".

Identifiers, exactly. Invoice numbers, ticket references and emails should match precisely and rank first. These are the highest-intent searches in any B2B product.

The empty result is the important screen

A bare "No results" is where somebody concludes the product does not contain the thing, and usually it does.

Say what was searched. Especially after a redirect or a correction.

Offer a correction. Did you mean, with the corrected query already run.

Widen the scope. No results in this project. 12 matches across all projects turns a dead end into an answer.

Show the nearest matches rather than nothing, and label them as approximate.

Name the constraints. If a filter was active, say so and offer to drop it. See filter and empty state.

Details that decide whether people use it

Scope, stated. Searching within a project and searching everything are different questions, and the control must say which is happening.

Results as you type, where the query is cheap. It teaches what search covers. Where queries are expensive, debounce and show a pending state; never let results flicker behind the typing.

Keyboard access. A shortcut to focus search, arrow keys through results, Enter to open. In a tool people use all day this is the difference between a feature and a habit. Where the product is dense enough, this becomes a command palette.

Recent and saved searches. Most searches in a working tool repeat.

Results that are useful, not just matching. A row needs enough context to choose: what kind of thing it is, which project it belongs to, when it changed. A list of names is a second search.

Why in-product search is not the browser's

Browser find only sees what is rendered. Text inside a collapsed accordion, on page four of a table, or in a tab that has not been opened is invisible to it.

Products with substantial hidden content therefore need their own search, and the settings area is the usual case: forty groups, most collapsed, and a person who knows the setting exists but not which group holds it.

In practice

A product's search matches exactly and searches only the current project.

Support tickets accumulate in a pattern. Customers cannot find records they are certain exist, and when an agent looks, the record is there — in a different project, or spelled with a hyphen the customer omitted, or plural where they typed singular.

Three changes, none of them ranking work. Fuzzy matching at one edit distance. A synonym list seeded from a month of support tickets. And a line under an empty result: No matches in this project. 7 across all projects.

The search index did not change. What changed is that the component stopped requiring people to know how the data was entered.

Where teams get it wrong

Exact matching only. One typo and the product appears to be missing data.
A dead-end empty state. The screen where people give up.
Unstated scope. Nobody knows what was searched.
Results with no context. A list of names is a second search.
Relying on browser find. It cannot see collapsed or paginated content.
No keyboard route. In a daily tool, that decides whether it is used at all.

Learn more

UI/UX design for B2B SaaS →