Search and filter interfaces should show what was searched, which constraints apply and what the user can change when no records appear. Separate no matching results from missing permission, unavailable data and a failed request. Those states need different explanations and recovery actions.
Let’s plan your search experience.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Define the searchable population
Identify record types, fields, access scope and freshness. Tell users enough to form a useful query without revealing restricted records. A search over active orders should not appear to search the entire organisation's history.
Specify exact, partial and identifier matching where relevant. Do not promise intelligent search without examples of supported behaviour and a testable acceptance boundary.
Design a result-state matrix
| Result state | What users need to know | Useful next step |
|---|---|---|
| Matches found | Scope, count and ordering | Inspect or refine results |
| No matches | Query and active constraints | Adjust relevant terms or filters |
| Empty collection | No eligible records exist yet | Create or import where authorised |
| Access limited | Search respects the user's permitted scope | Appropriate access-request route |
| Data stale | Results may not reflect recent changes | Refresh or explain update timing |
| Request failed | Search did not complete | Retry without losing input |
Do not automatically call every empty view No results found. That wording can mislead users when the service never answered.
Make filters visible and reversible
For a hypothetical service-request queue, a hidden Closed status exclusion may make an existing reference seem missing. Show active constraints and provide a clear way to remove them.
Decide whether changing a filter resets pagination and selection. Preserve the query when users return from a record. Avoid unexpectedly discarding their workspace after a browser Back action.
Test queries users actually use
Include identifiers, abbreviations, punctuation, long names and likely mistakes. Use authorised examples and review the result ordering with domain users. A relevance score is less useful than observing whether the intended task succeeds.
Check large datasets and server errors as well as the tidy demonstration state. Define how the interface handles a query that is still processing when another query starts, so old results do not overwrite newer intent.
Search UX questions
Should the interface always suggest creating a record after no results?
Only if creation is permitted and appropriate. Otherwise it can encourage duplicates or bypass an expected lookup.
Should all filters persist forever?
Choose a predictable persistence rule and make retained constraints visible. Users should not have to remember a hidden setting from a previous session.
Connect the result view to data table interaction rules. Bring sample searches to Drema's UI/UX design team.
