Amey-Thakur Search result presentation
Ranking decides what is on the page; presentation decides whether the user recognises it. A correct first result that looks like every other row still costs the user time, and that time is what search was supposed to save.
Method
- Show why each result matched. A snippet containing the query terms in context, with the match highlighted, lets a user judge at a glance rather than by clicking.
- Lead with the field people scan. Usually a title, sometimes an identifier or a name. A snippet-first layout wastes the strongest signal.
- Include the metadata that decides. Date, type, author, status, or price, chosen because it is what people compare, not because it is available.
- Group when results come from different sources. Mixing documents, people, and settings in one flat list forces the user to sort the categories mentally.
- Make the whole result actionable. A large click target, keyboard navigable, with the primary action obvious (see keyboard-navigation).
- Keep pagination or infinite scroll honest. Show how many results exist, keep positions stable across loads, and preserve state when the user returns from a result.
- Handle long and empty fields gracefully. Truncate at a sensible boundary with the query term still visible, and never show a blank row for missing data (see text-expansion-layout).
Boundaries
- Presentation helps users recognise relevance; it cannot compensate for a poor ranking (see relevance-tuning).
- Highlighting must not alter the underlying text or introduce markup the user did not write, which is an injection risk.
- Dense information layouts need accessibility review, since scannable and screen-reader friendly are not automatically the same (see screen-reader-testing).