Presenting Results
What a result shows decides whether somebody finds what they wanted or gives up.
Where to find it
Architect Panel → Searching:
- Site Searching — the indexed datastores and their output
Architect Panel → Layout & Pages:
- Browse Views — where a searcher often ends up next
A result must be distinguishable
The single most important thing. Five results all reading "J Smith" force the searcher to open each one — which is slower than not having searched.
Include whatever separates them: a town, a reference, a date, an organisation. One extra field usually turns an unusable result list into an obvious choice.
Say what kind of thing it is
Where several datastores are indexed, a result should make clear whether it is a case, a person or a document. Without that, a mixed list is confusing and people click the wrong things.
The first three results decide everything
People look at the top of the list and, if the answer is not there, conclude search does not work — rather than scrolling. So relevance at the top matters far more than completeness further down.
If the right answer is consistently fourth, that is a problem worth fixing even though the search is technically working.
Show enough, not everything
A result carrying six fields is as hard to scan as one carrying one. Two or three well-chosen pieces of information — the identifier, something distinguishing, and the type — is usually right.
Handle no results properly
An empty list is a dead end. Say plainly that nothing matched, and give a route onward — a suggestion to broaden the term, a link to browse, or a way to create the thing they were looking for.
Without that, somebody who searched for a customer who is not there will type the name into a free-text field and carry on, which is how unlinked data appears.
Take them somewhere useful
Clicking a result should open the thing, at the place they need. A search that lands somebody on a record and leaves them to navigate has done most of the work and stopped short.
Test as somebody who does not know the data
The person who built the index knows exactly what to type. Watch somebody else search for something — it is the fastest way to find that your results are indistinguishable or your vocabulary is wrong.
Worked example
A results list showed only names, so "Smith" returned nine indistinguishable rows. Adding the town and account number made the right one obvious, and the "no results" message now offers to create a customer — after several were found typed into notes fields instead.
Recommendations
- Include a distinguishing field in every result.
- Show the record type where several are indexed.
- Give no-result searches a route onward.
- Watch somebody else search before deciding it works.