Interaction Design Frameworks that Work: Search
Google is arguably the most trusted name in the world when it comes to search tools. In fact, users are frequently put off when an on-site search engine doesn’t look or work like Google, and as a result question whether it can be relied upon for high-quality results. Without knowing exactly what’s so effective about the search master, most people simply trust it. For many, it’s a fact of life—puppies are cute, bugs are icky, and Google just works.
But how did Google get to be so good, and how can we apply lessons from Google to on-site search to generate effective results and commonsense interactions? What elements do we need for a good search engine interface and how do they need to work?
At first glance, the search framework might appear simple. For example, in July 2008, Chiara Fox of Adaptive Path had this to say about one of the framework’s key elements (http://www.adaptivepath.com/blog/2008/07/14/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 Previous and Next 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... [tech-savvy] 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).
Chiara’s list is indeed a good start and should be no surprise. However, while the list of elements to include here is nothing shocking, there’s far more to designing a good search framework than the results page alone, and there’s far more to consider when adapting this framework to your own site than meets the eye. And that’s what the bulk of this chapter is about.
The true challenges of search are in understanding why people search in the first place, how they use the results, what types of results to show, what information to include in them, and how to handle each possible type of search outcome. Once again, the elements of the framework themselves aren’t meaningful until they’re put into the context of the problems they solve.
The search framework lets users locate specific content using a consolidated task flow as an alternative to traversing a site’s hierarchy via its global and local navigation. By searching for items directly, users can frequently bypass the exploration process: instead of looking through category and gallery pages, users simply pull up a set of content links related to a specific query and click straight through to content pages. There’s no need to negotiate the site’s navigation and risk making a wrong choice.
Of course, only in a perfect world with a perfect user is search really that simple. In reality, search brings a whole set of problems of its own, each of which you will need to consider when adapting the search framework to your own designs. To understand these considerations, we must first understand the psychology that makes search necessary.