When a SaaS search returns no results, keep the query and selected filters visible. Explain that nothing matches the current search, then let the user widen it on purpose. Do not silently clear their choices and show unrelated records as if the original search worked.
The empty result is part of the workflow. A user needs to understand what was searched and which change might help, especially in a product with dates, owners, and status filters.
Keep the search the user actually made
Leave the typed query in the search field. Show selected filters near the result area, with a clear way to remove each one.
For a hypothetical invoice tool, a message could read: “No invoices match ‘Acme’ with Status: Paid and Date: This month.” The wording describes this combination. It does not claim that Acme has no invoices anywhere.
Algolia’s filter guidance recommends showing result counts that update as filters change. Use those counts when your search can provide them accurately. They can help a person see which choice is narrowing the list.
Offer one clear way to widen the search
Start with a small, relevant action: remove the date filter, clear the query, or reset all filters. Label each action with what it changes.
“Clear date filter” should leave the query and status alone. “Clear all filters” should keep the typed query unless the label says the query will also be removed.
Do not promise that removing a filter will find matches unless you know that it will. A button can offer a new search without predicting the result. If you show an accurate count, explain what that count refers to.
Make broader results visibly different
A product may offer related results or suggestions after an empty search. Algolia’s examples of no-results pages describe ways to provide a next step, including suggestions and revised search paths.
In a SaaS workspace, label the broader set clearly: “Other invoices for Acme outside this month.” Preserve the original message above it. A person should not mistake suggested records for exact matches.
Avoid quietly relaxing an owner or workspace filter. Those choices may be important to the task. Showing records outside the intended scope can be confusing even when the user is allowed to see them.
Separate empty results from a failed search
Use a no-results message only after the search completed successfully. A timeout, a disconnected network, or a permissions error needs its own state.
For a failed request, say that the search could not be completed and offer Retry. Keep the query and filters so retrying does not require entering them again.
Also guard against old responses replacing newer results. If a person changes the query while a request is running, the final list should belong to the current query. Tie the displayed result state to the search that produced it.
Check the behavior with a small set of cases
Walk through the whole interaction with realistic sample records:
- A query matches records until one filter removes them all.
- Removing one filter keeps the other selections.
- Resetting filters preserves the query as labelled.
- A failed request shows an error, not zero matches.
- A slower earlier request cannot replace the latest result.
- A person using the keyboard can reach each recovery action. Check the page again after following a result and returning. If the product preserves search state, the query, filters, and result list should agree. If it does not, make that behavior clear rather than leaving mismatched controls.
Use an empty-result screen to help someone adjust a specific search. The goal is a clear next action while keeping the work they already did.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)