Search UX in Data-Heavy SaaS: Filters, Saved Views and the Zero-Results State

The short answer

In a data-heavy B2B product, search is navigation. Design it around three jobs: finding a record you already know exists, exploring a set by narrowing it, and keeping an eye on a set that changes. Each job needs its own pattern. Known-item lookup needs a fast, forgiving search box. Exploration needs facets that show what is available and never lead to an empty set. Monitoring needs saved views that people can name, share and subscribe to, so nobody rebuilds the same filter every morning. When nothing matches, the screen should offer the next move, not a dead end.

Many products do the opposite. Search is bolted onto the header, filters reset on every visit, and "No results found" is the whole message. The rest of this page gives the decisions, a job-to-pattern table, a filter checklist, a zero-results checklist and a short list of things to measure. It covers in-product search only. Marketing-site search and the choice of search engine are out of scope; the engine matters less to the user than the interface rules below.

Three jobs, three patterns

Users arrive at a search box with different intentions, and one control cannot serve all of them equally. This table is our working synthesis of the research cited in the sections that follow, not a published taxonomy.

If you design only for the first, power users rebuild exploratory filters by hand every day. If you design only for the second, a user who knows the exact record is made to click through facets to reach it.

Scope, index and matching

One search or several? Nielsen Norman Group's intranet research recommends a single unified search over content, people and tools, because fragmented search experiences do not improve it ("Intranet-Search Essentials"). In a product, the same logic suggests one global box that returns results grouped by object type, plus scoped search inside a list or table, where the scope is obvious. The objects you can search follow your product's model; our piece on when a SaaS product needs object-oriented UX covers how to decide what those objects are.

What to index. Index what users call things, not only what the database calls them: names, identifiers, aliases, tags, owners and the labels from previous systems. A record found by a legacy code is a migration won.

Typos and synonyms. Marti Hearst reports that roughly 10 to 15 per cent of queries contain spelling or typing errors, and that web engines offer a correction as a choice, though blatant typos may be corrected automatically (Search User Interfaces, chapter 6). Her sources also show that uptake of a "did you mean" link is uneven, so correct the obvious cases quietly and keep the original query one click away. Always let users revert to their original query.

Results that explain themselves. Show the field that matched, with the matched text emphasised, and the fields people use to tell similar records apart: status, owner, last updated. Dates beside results help users judge relevance, so show recency rather than hide it.

Keyboard access. A type-ahead search is a combobox, and the W3C's combobox pattern defines the behaviour: Down Arrow moves into the suggestions, Enter accepts the focused one, Escape closes the list, and `aria-activedescendant` lets screen readers announce the highlighted option while focus stays in the input. A global shortcut to focus the box is worth having in a product people use all day.

Filters and facets

Baymard Institute's research is about ecommerce, and ecommerce is not your product. We carry it over for two reasons: the mechanics of narrowing a large set are the same, and Baymard publishes the share of sites that miss each pattern, so the findings are about interface behaviour, not about shopping. Where a rule depends on the shopping context, we say so.

Let people combine values. Baymard found that 15 per cent of benchmarked sites do not let users select several options within one filter type. Participants then repeated the filtering for each option and memorised products between steps, and some abandoned. Its recommendation is OR logic within a filter type, AND logic across types, and checkboxes to signal that several values can be chosen (Filtering UX: Combining Filter Options). In a B2B list, "region is EMEA or APAC, and status is overdue" is the normal case.

Show what is applied. Baymard reports that 28 per cent of benchmarked sites have no overview of applied filters. Without one, users had no confirmation that filters were on, no quick way to remove them, and no context for the list; a user who missed one applied filter misjudged the range. It advises showing the filter type and value ("Status: Overdue"), not only a count (Display "Applied Filters" in an Overview). In a product this matters more, because a hidden filter can make a user believe a record has been deleted.

Choose categories people recognise. Filter categories and values should cover what users actually filter on, be predictable, use plain words and be ordered by relevance to users. Interviews, search logs and analytics show which attributes matter. For a B2B product, start from the fields people already filter on in exports and spreadsheets.

Show counts, and avoid empty sets. Hearst's account of faceted navigation notes that the Flamenco interface used query previews, showing how many items sit under each label so users can see the effect before selecting, with "avoidance of empty results sets" as a design goal (chapter 8). Counts also cost computation; the trade is worth it where records number in the thousands.

Decide when filters apply. Nielsen Norman Group distinguishes exploratory users, who benefit from results updating as they select, from users who already know several criteria, who are better served by batch filtering with an Apply button, which also risks zero-result combinations. It suggests dimming the results area while new results load, so many small changes become one visible change (User Intent Affects Filter Design). That article is about shopping; the logic carries to a table, and our default would be instant on a fast list and Apply on a slow one.

Filter design checklist (our synthesis of the sources above):

• Multi-select within a type; AND across types.
• Applied filters shown as type and value, each removable in one click, with a clear-all.
• Counts beside values where you can afford them; values that would give zero are disabled or hidden, not selectable.
• Categories ordered by how often users use them, in users' words.
• Sort default stated on screen; newest first is a safe default for activity lists, relevance for text queries.
• Filter state kept in the address, so a link reproduces the view.
• Filter state kept when the user opens a record and comes back.
• Every control reachable by keyboard, with a visible focus state.

Saved views

Saved views are where the third job gets served. Two products with large record sets show what the feature includes, from their own documentation.

Linear's custom views are saved, filtered views of issues, projects or initiatives. They can be shared at workspace or team scope, starred to pin them to the sidebar, and subscribed to, so the user is notified when an issue enters or completes in the view (Linear documentation). Atlassian's saved filters in Jira can be shared, emailed on a schedule, starred, exported and shown in a dashboard (Atlassian documentation).

From those, the parts worth copying:

1. Save from where the user already is. "Save this view" sits next to the applied filters, not in a settings menu.
2. Name it, and let the name be edited. An unnamed view is a view nobody finds again.
3. Separate personal from shared. A shared view should have an owner, and everyone should be able to tell which kind they are looking at.
4. Make a view a link. If a view has an address, it can go in a message, a report or a runbook.
5. Offer a subscription, not just a bookmark. Monitoring is the job; a notification or scheduled digest is how a saved view does it.
6. Say what changed. When a shared view's definition is edited, the people who rely on it need to know.

Saved views also give you data. The views people create show which filters your default list is missing.

The zero-results state

An empty result is information about a mismatch between what the user typed and what the product holds. Treat it as a design surface.

Baymard reports that nearly half of benchmarked ecommerce sites fail to give users effective ways to recover from a search with no results, and that search tips alone are not enough. Its five recovery strategies, in its article on "no results" pages, are related categories, alternative searches, personalised recommendations, help and contact links, and popular items as a last resort. Two of those are shopping ideas. The B2B equivalents are below.

Zero-results checklist (our adaptation):

• Say what was searched and what was applied. Repeat the query and list any active filters, because a filter is the most common reason a search is empty.
• Offer to relax the filters. One button per applied filter that removes it and shows the new count, or "Clear filters" when several are on.
• Correct and broaden the query. Offer a spelling correction as a choice, and a looser version of the query with its result count.
• Search wider scopes. If the user was in one list, offer "Search everywhere" with the count from other object types. Archived and deleted records are a frequent hidden cause, so offer them explicitly.
• Explain permissions. If a record may exist but the user cannot see it, say that results can depend on access, and name who can grant it. Do not reveal the record.
• Offer to create it. In a product, "no match" can mean "this does not exist yet". Offering to create the record is useful only if you first rule out a duplicate; our piece on a search-first create flow sets out how.
• Give a route to a person. A help or feedback link, as Baymard suggests. Also review the no-result terms, alongside the most searched ones, to find gaps in what you index.
• Keep the search box filled with the query, so it can be edited, not retyped.

A case from our own work shows one version of the last-resort idea. For Eden AI, we designed a single search bar as the entry point for workflow creation, switching between template search and an AI assistant, and when a search returns no results the query becomes an AI prompt. The case page, Unifying workflow creation through intelligent search, has the detail.

Where AI changes this

Natural-language filters and semantic matching change how a query becomes a filter, and they help most in exploration: "overdue invoices over a certain size for EMEA accounts" can become the filter chips above. The interface rules do not change. The user still needs to see which filters the system applied, remove them one by one, and save the result as a view. Whether search and an assistant should share one input is a separate question, which we answer in AI search in SaaS: should search and the AI assistant be one input.

How to measure search

These measures are our suggestion for a first dashboard; none comes from the sources above, and the thresholds are yours to set from your own baseline.

• Zero-result rate: the share of searches that return nothing, and which terms they are. Read the terms, not only the rate.
• Search exits: the share of searches after which the user leaves the product or the section.
• Refinement rate: the share of searches followed by another query or a filter change. A high rate on known-item queries points at matching; on exploratory queries it is expected.
• Time to record: the time from first keystroke to opening a result, for known-item searches.
• Saved-view use: how many people open a saved view each week against how many rebuild an equivalent filter by hand.

If your product is a content or knowledge platform, our work on content and knowledge discovery platforms is the nearest page. For the structure behind these decisions, see our information architecture and workflow design service.

What we could not verify

Baymard's filter research comes from ecommerce studies, and the percentages are shares of benchmarked sites at the time of testing, not measures of B2B products. Hearst's book dates from 2009. We could not read the chapters of Morville and Callender's Search Patterns (O'Reilly, 2010), so we cite none of its details. We found no public search-volume figure for "saas search ux".