Findability
Search and filter UX: test the path back from no results
UxerProof Editorial · · 3 min read
“No results” can mean the record does not exist, the query is too narrow, a filter is still active or the system failed to load the data. A useful search experience helps someone distinguish these possibilities.
Test the route from a known item to a successful find, then deliberately narrow the view until it has no matches. The recovery path often reveals more than the first successful search.
Prepare known records
Use synthetic records with names and attributes the reviewer can verify. Include enough variation to exercise the product's documented search and filter behavior, but avoid assuming capabilities such as fuzzy matching or synonym support unless they are part of the specification.
For an illustrative project list, prepare active and archived items with different owners. Define which fields are searchable and what the filters mean. Otherwise, the test may incorrectly report an unsupported search behavior as a defect.
Follow the active constraints
Search for a known item, add a filter and inspect the resulting set. Can the person see which constraints are active? Does the displayed count refer to the filtered set or something else?
Then create a no-result combination. Check whether the screen preserves the query and filters, explains the empty state and offers an understandable way to broaden the view.
“Clear all” may be useful, but inspect what it actually resets. A control that clears a text query while leaving an invisible date filter can return the person to the same confusing state.
Test returning to the list
Open a result, then navigate back. Review whether the search context behaves as intended: query, filters, sort order and page position. The right persistence model depends on the task, but the behavior should be coherent.
Also reload the page and follow a saved link if the product supports one. Record whether the visible state matches the link's meaning. Do not assume a search is shareable simply because its result is on screen.
Separate no matches from failed retrieval
Use a controlled failure to inspect the loading-error state. An unavailable search service should not silently produce the same message as a valid search with zero matches.
For each finding, record the known fixture, query, constraints, expected matching rule and actual result. This gives engineering a reproducible case without needing a copy of customer data.
Verify the useful outcome
The task is not complete when a row appears. Open the intended record and confirm that the person can continue the action that motivated the search.
A successful review demonstrates findability for the tested data and matching rules. It does not establish that every query, permission combination or dataset size behaves correctly. Keep those coverage boundaries visible.
Next step: Use the Golden Journey Test Contract to specify the known item and the outcome beyond finding it.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.