Search is such a prominent part of the Web user experience that users have developed a firm mental model for how it's supposed to work. Users expect search to have three components:
A box where they can type words
A button labeled "search" that they click to run the search
A list of top results that's linear, prioritized, and appears on a new page -- the search engine results page (SERP)
In user testing, people tell us that they want search on websites and intranets to work like X , where X is their favorite major search engine. Luckily, all three of the major engines (Google, Yahoo, and MSN) work the same: exactly as stated in the list above.
Deviating from this expected design almost always causes usability problems. Sites that separate out some search results and place them in boxes risk having these links overlooked because users often assume they're ads. Instead, such "best bets" should be the first items in the linear list. (Typically, users don't care that items are editorial, rather than algorithmic, selections.) Also, scoped search that covers only a current subsite often misleads users who rarely have to consider what's being searched.
Earlier guidelines for search usability continue to hold, and are becoming even more important with the new mental model. The dominant search engines comply with all the main usability guidelines, which is obviously a major reason that they're on top. Today, the guidelines don't just describe good search; they describe expected search.
When is a Search "Search"?
Given how ingrained it is, it's crucial that you avoid invoking a user's mental model of search for other interactions. Don't use a "Search" button for parametric search. Although often useful, such searches don't fit the design pattern for search. You should thus call them something else to avoid confusing users.
A classic parametric search example is when you search a shoe site by specifying your shoe size, width, color, brand, and style. This is a great way of identifying shoes to buy, and certainly much more useful than a keyword search. Problems arise, however, when the action button is labeled "Search."
In our experience, when users see a fat "Search" button, they're likely to frantically look for "the box where I type my words." The mental model is so strong that the label "Search" equals keyword searching, not other types of search.
Most database programmers view parametric queries and other types of retrievals as a form of search. Fine. Just call it something else in the user interface.
Currently, there's no single winning label for non-keyword search, but Find and Retrieve seem to work well. For winnowing, you can use labels like "Refine Results." But don't use such labels for keyword search -- when there's a box for users to type words, label the action button "Search."
Finally, advanced search that combines keyword searching with other search forms can be helpful, but it should be a secondary option that's only displayed when users ask for it.
Users are now forming mental models that they expect to apply across the Web, and even to their intranets. This is good. Existing knowledge of interaction techniques lets users focus on their goals, not the mechanics of operating the interface. All this breaks down, however, if your design conflicts with users' preconceived mental models. Don't commit this sin.
Share this article: Twitter | Linkedin | Google+ | Email