When your search returns several similarly named cases, the list only helps if people can recognise the right one. They may need a date, owner, location or status to do that. Which details matter depends on what they already know about the case.
Establish what people are searching for
In a web application, “search” may mean finding a known record, collecting open cases or discovering unfamiliar documents about a topic. Each task needs different information.
You can derive those details from typical search situations without indiscriminately collecting personal search text. Someone who knows an identifier needs a different starting point from someone who recalls only an approximate date or business context. Those differences shape both the search inputs and the information each result should show.
If a machine name appears at two sites in an internal maintenance portal, the person searching needs a way to distinguish the results. Name, location and status can support that choice; a larger preview image would not replace the missing location.
Keep the query visible with the results
After a search, people need to know what the list represents. The U.S. Web Design System search component recommends retaining the query in the search field on the results page. An application also needs to show active filters and the area being searched.
Explain whether the search includes only open cases or the archive too. A filter should not remain active invisibly while someone tries a new term. Otherwise, a correct search may appear to have a broken index.
Check returning from a result as well: are the query, filters and list position retained? Requiring a fresh search after every opened record loses working context.
Empty results have different causes
“No results” might mean no matching record exists. But a filter may be too narrow, an identifier may be formatted differently or the role may lack access. The interface should only give explanations it can actually distinguish.
| Observable state | Useful response |
|---|---|
| A filtered search returns nothing | Show the query and filters; offer a targeted reset |
| The search connection failed | Explain the technical failure and allow retrying |
| The input does not match an allowed identifier format | Explain the expected format at the field |
The appropriate message depends on the state the backend actually reports. If it cannot distinguish a cause, a specific explanation would claim more than is known. A permissions message also needs to help without revealing that confidential records exist.
Test results through a real working task
Known search situations then let you check whether that mapping works. A unique identifier, several similar results and a justified empty state each make different demands on the interface. What matters is therefore not just whether someone opens a result, but whether it is the right one and they can continue working.
When a search fails, distinguishing an absent record from an unrecognisable result or an excluding filter helps you identify the work needed. Each finding calls for different changes to search logic, presentation or data. UX decision support can define that work; developing a web-app interface requires a clear task.
