Designing Search Checklist
Recently on projects I’ve found myself designing a number of search results pages. While each project has its own set of requirements and nuances, I think there are a handful of elements that should be included in most all result page interfaces. If you start out with this list, and then tweak as your situation requires, I think you’ll end up with a pretty good page.
Here are the items on my checklist, in no particular order:
- Highlight the query term in the results.
- Restate the query on the results page.
- Show the number of results that were found.
- Include next and previous buttons, as well as links to additional pages, to move through results. These should be smartly linked; no link on previous if you are on the first page and so on.
- Include a query box so the user can search again.
- Don’t show the URLs of the result pages, unless your audience is techy enough to derive meaning from the URL.
- Have meaningful page titles and descriptions for each result.
- The page title should be the link to the result.
- Allow sorting and refinement tools if appropriate for your users and content.
- Indicate if a result is not a regular page (e.g., a PDF file).
What items do you have on your checklist?
There are 17 comments on this idea.
Good list, though I think that if additional meaning could be given by displaying the URL then perhaps you should extract that meaning and display it for all audiences rather than encoding it in a URL for the techies?
I can’t check it here at work but I think that eBay displays the category hierarchy with each search result breadcrumb-style giving users context to each search result; the same could be achieved with clean/friendly URLs like www.domain.com/parent_category/child_category/item but if that information is available then an attempt should be made to present it in a readable format for all users?
That list is pretty much the same as mine, but I’d add:
* Directory crowding - don’t let one source of hits crowd out the results, show a sample and link to more.
* Spellchecking - no longer a luxury, it allows users to get close enough to a search result, especialy proper nouns.
* Keymatch results - for those times when you can infer from the query what users are most likely looking for.
Interestingly, if you add the Page Rank algorithm to your list, you’ve got Google.
I often show breadcrump trails above the result’s title. This gives a quick info where the result page is hierarchically nested.
Give the user great feedback when no results are found. I prefer a short sentence for this. Give the user some links to top searches or most popular articles in stead of the expected search results.
[...] Search result page checklist Chiara Fox posted a very insightful checklist for designing search result pages in Adaptive Path’s blog: [...]
I will add one to yout list:
Make sure you are using different colors for visited and unvisited links.
Similar to not showing the URL, don’t show the file size of each result, as most people don’t really care. Also, don’t show it’s ranking as any value other than the order it appears in the results.
These are great everyone! Keep them coming!
“Include a query box so the user can search again.”
…prefilled with the query just run so the user can edit, rather than starting from scratch.
When search results are documents (pdf’s etc) give introductory text (e.g., the abstract) to the document.
Thanks for the list,
Implementing changes on my current design now!
Chiara it seems you are on the road to create a pattern :) Erin Malone is without doubt smiling somewhere in her vacation :).
We have the following list for our results, I’ve generalized it to match a general SERP instead of an specific one (docs, products, etc).
1. Navigation Artifacts
BreadCrumb: Searched Terms + Categorie or paths followed (via facets or traditional breadcrumbs usage depending on the artifacts placed to filter and navigate the SERPS)
Search form with searched terms
Number of items/pages in SERP
2. Specification Artifacts
Clusters and/or Filters to narrow down SERP
3. Related searches
Semantic or grammatical corrections suggestions
Releated search terms (to narrow via specification SERPs)
4. Manipulation artifacts
Sorting
Comparison of results
5. Expanded navigation artifacts
Visited results
Related results
Related goals
Advertising spaces
6. Results artifact
Depends on what you are implementing. But in every problem we have faced on our different portals we decide to select data that can help user understand what she would find out on the result once it is clicked and help her decide on which results might prove interesting goals to follow and which don’t. For example on a retail site we’ve decided to place a brief item description, photograph, geographical location and price, since we have been able to discern through ethnographic studies this are the variables that our users use to inform their purchase decision.
7. Alternate revenue artifacts
Result highlighting or special treatment
Advertising spaces
We also take into account the default sorting of the results, and it varies on what kind of implementation you are working on, always treating only the results that correctly matches user expectations. On some sites we’ve decided to give better placements to the results that have payed for special treatment, results through which we know we can have higher take rates, ranking based on proximity against search expectation, etc.
Hi Chiara,
That’s a good list, and it certainly matches our experience. We’ve also written a little on this: What to include in search results. That says pretty much the same thing…
Cheers, James
Great list!
I’d add a few more that I’ve found to be important and inspired by some of the nuances of Google’s UI:
1) I’d modify “Allow sorting and refinement tools if appropriate for your users and content” to reveal some hierarchy within the results themselves rather than cluttering things up with more options, when possible. Do this by building a bit of default sorting with sublists and grouping related items together.
This sounds more complicated than it is and is visually simply to understand. For example, if results two and three are subsections of the first result, then indent them and move closer to their “parent”. A good example is an ego search for my name - the first two results from my site are grouped together, then the next two from flickr, then two more from some w3 list I posted to ages ago, etc.
2) give sneak peeks of other types of searches for the same term by giving snippets above the “real” results and a link to more, or even modifying the look of a single result to get across that it’s a different media. For example, searching for Obama will have the results you’d expect and also some snippets of recent news, a thumbnail and rating next to the youtube clip, etc.
This last one is actually more relevant than you might think, this isn’t just a problem for search companies with various flavors of engines. Depending on what kind of site you’re building or working on, it’s worth questioning when a page of mainly text with a long list of links is the best fit for the type of thing being searched and what to do when it isn’t, whether to make modifications to a single search result UI to highlight the differences or have a separate type of search for a particular type of data rather than trying to have only one search result UI to rule them all. Context over consistency - sounds simple, often isn’t :)
[...] Designing Search Checklist [...]
[...] the publication of a brief article on Search results design by Adaptive Path, I decided that revising my database search script was a valuable goal. [...]
nice list, I think I’ll have to remember those items when I redesign my search page later!
[...] Designing Search Checklist from adaptive path. [...]
Add to the conversation.
Commenting is not available in this channel entry.