How Should Search and Filtering Work in a SaaS App?

Should a SaaS app have search, filters, or both?

Both, doing different jobs. Filters are for a user who is browsing and narrowing down. Search is for a user who already knows what they want and needs to jump to it. Building only one forces half your users into the wrong mode, and they blame themselves for it.

The distinction sounds obvious and gets ignored constantly. Plenty of products ship a beautiful filter panel and a search box that only matches the exact title, so anyone searching for a phrase inside a record gets nothing.

This is how we think about designing the pair, and what the research says about where teams go wrong.

How badly do most products handle this?

Badly enough that it is the norm rather than the exception. Baymard Institute benchmarks list and filtering experiences in detail, and in research published on 22 August 2024 and updated on 9 September 2025 it found that 58 percent of desktop ecommerce sites and 78 percent of mobile ecommerce sites have poor to mediocre Product List UX performance.

That benchmark covered more than 170 leading sites across the United States and Europe, with over 21,000 manually reviewed UX parameters. These are not small teams with no budget. They are the sites most likely to have done the work.

One caveat worth stating plainly: Baymard studies ecommerce, not SaaS. We cite it because the underlying task is the same, a person narrowing a large set to find one item, and because comparable published research on internal app lists is thin. Treat the numbers as strongly suggestive rather than as measurements of your product.

What is the actual difference between a filter and a search?

A filter removes things that do not match a known attribute. A search ranks things by how well they match an unknown phrase. Those are different operations and users switch between them without thinking about it.

The practical consequence is that search has to be forgiving and filters have to be exact. A search for invoce should still find invoice. A filter for status equals open should never quietly include closed items because it seemed relevant.

Getting this backwards produces the two classic complaints. Search that behaves like a filter feels broken because a small typo returns nothing. Filters that behave like search feel untrustworthy because the result set includes things the user explicitly excluded.

Where should filters live on the screen?

Visible, not hidden behind a button, whenever the screen has room. A filter panel people can see is a filter panel people use. A filter icon on a toolbar gets ignored by everyone who did not already know it was there.

On narrow screens you have no choice, and the pattern that works is a full screen filter view with an obvious count of how many results the current selection produces. Applying filters blind and then discovering there are zero results is the worst version of this interaction.

Order the filters by how often they are used, not by how your data is structured. The filter your users reach for nine times out of ten should be first, and it is usually status, owner, or date. Our notes on SaaS dashboard UX cover the wider question of what earns screen space.

How should applied filters be shown?

Always, in one place, and each one removable on its own. This is the single most common failure in the category and it is completely avoidable. Baymard found that 20 percent of the sites in its benchmark do not display an applied filters overview at all.

Without that overview, a user looking at a short result list cannot tell whether the data is genuinely sparse or whether they filtered something out ten minutes ago. That ambiguity is where trust in the whole product starts to go, because now the numbers on screen might be wrong.

Show each active filter as its own removable chip, and give a clear way to clear everything at once. The clear all option matters more than it looks, because the fastest recovery from a confusing state is starting over.

Should filters combine within the same type?

Yes, and the fact that this needs saying is the interesting part. Baymard found that 14 percent of benchmarked sites do not allow users to combine multiple options from the same filter type. That means you can filter by one status but not by two.

Real questions are almost always multi value. Show me everything that is open or in review. Show me work owned by these three people. A filter that only accepts one value forces the user to run the query twice and merge it in their head.

The rule that works is or within a filter, and within filters across different types. Status open or in review, and owner equals Sam. That matches how people describe what they want out loud, which is a good sign you have it right.

What should happen when there are no results?

Explain why and offer a way out. An empty state that just says no results is a dead end. An empty state that says no items match these four filters, with a button to remove the most restrictive one, is a next step.

Distinguish between the two kinds of empty. A brand new account with no data at all needs onboarding and an invitation to create something. A filtered view with no matches needs the filters loosened. Using the same screen for both is confusing in exactly the moment a user is already stuck.

For search specifically, suggest something. The closest match, a spelling correction, or the same query with filters cleared. Baymard's ecommerce search research, covering 344 leading United States and European sites, noted that more than 700 search specific usability issues arose during its testing, and dead end results are a large share of that category. Our piece on empty and loading states covers the patterns in more detail.

How fast does this need to be?

Fast enough that people keep experimenting. The behaviour you want is someone trying a filter, seeing the result, and adjusting. If each adjustment takes two seconds, they stop exploring and go back to scrolling, which is the thing you built filters to avoid.

Filtering a set that is already loaded should feel instant. Anything that needs a round trip should show the previous results dimmed rather than blanking the screen, because a flash of empty space reads as an error even when it is not.

Result lists also need to stay near the top of the page. Nielsen Norman Group's eyetracking research, published 15 April 2018 from over 130,000 eye fixations, found that 74 percent of page viewing time was spent within the first two screenfuls. Pushing results below a tall filter header wastes the attention you have.

Should the filter state live in the URL?

Yes, for anything a user might want to share or return to. This is a small technical decision with a large usability payoff, because it turns a filtered view into something a person can bookmark, send to a colleague, or reach with the back button.

It also fixes a subtle irritation. Without URL state, navigating into a record and back loses the filters, so the user has to rebuild the view every time. That single frustration is enough to make people stop using filters at all.

Keep the parameters readable rather than encoding them into an opaque blob. A colleague receiving the link should be able to tell roughly what it shows. Our notes on data table design cover the same thinking applied to the results themselves.

What would we build first?

The applied filters overview, before anything clever. It is the cheapest thing on this list and it prevents the most damaging failure, which is a user trusting a number that is filtered without realising it.

Then multi value selection within each filter, then URL state, then forgiving search. That order front loads the fixes that stop people being misled, and leaves the ranking and relevance work, which is genuinely harder, for once the basics are solid.

If you are designing a list view that has become hard to navigate, or trying to work out whether your users need better filters or real search, we are happy to talk it through. You can find us at phoenix.studio.