This chapter is from the book
This chapter is from the book
This chapter is from the book
Elements
The elements of the search framework are few but powerful, and they facilitate the search process from beginning to end for users who find themselves in need of alternative pathways to information when site navigation proves insufficient.
The search framework is comprised of the Quick Search, Search Results, Advanced Search, Filters, and Pagination design patterns. Unlike many patterns, however, these patterns can subdivide into multiple types depending on the purpose and scope of the solutions they address.
Quick Search
Quick Search is frequently nothing more than a simple input field with an adjacent button for submitting search queries, placed on the page where it can be found quickly and easily. But it's also frequently more complicated, and there are quite a few factors to consider when designing one.
)
Figure 4.1 Cancer.gov's Quick Search implementation is representative of the most typical form of the design pattern.
Most important is to understand why users jump to Quick Search in the first place: this insight should serve as the basis for all subsequent search-related design decisions. As we've already discussed, users don't rely on search simply because they are search-dominant people, but rather because some content lends itself to search very well, or because a site otherwise lacks a user's trigger words. To put this in context, consider the difference between sites such as Amazon.com and Cancer.gov.
Amazon has one of the best on-site search capabilities on the web. But surprisingly, the reason it works so well is the same reason that search may not work so well on your site.
Amazon's vast collection of books, CDs, DVDs, and videos make up what we call uniquely-identified content, which users easily search for simply by entering specific information—which they frequently already know. That is, people identify books by title and author, and they identify CDs by artist, title, and song titles. Almost every time a shopper looks for a specific book or a CD on Amazon, she types in one of these identifiers.
For instance, when a book shopper in UIE's study entered Sum of All Fears, Amazon returned seven different editions of the Tom Clancy book. Amazon didn't suggest any other books containing the words sum or fear in the title—just seven editions of that single book.
When users search for uniquely-identified content and the users know what those identifiers are, then search works very precisely. In a UIE study conducted with thirty-five online shoppers, the search returned useful results ninety-nine percent of the time for CDs and videos.
But this process of searching for uniquely-identified content is the exception to the rule. In most cases, users are looking for content for which they don't already know the name. Consider the behaviors most likely put in practice on these four sites:
- Amazon.com contains mostly uniquely-identified content, and users are very likely to know (and therefore search by) a product's name, or some reasonable facsimile.
- BestBuy.com contains mostly uniquely-identified content, but because electronic equipment often features meaningless model numbers, users are less likely to know or search for these products by their exact names (like Mitsubishi WD-65735) and therefore more likely to search by category or product type (such as hi-def television).
- Gap.com contains some uniquely-identified content, but since clothing items frequently have nonspecific names, users are very likely to search by category or product type, with occasional exceptions.
- Cancer.gov contains mostly non–uniquely identified content, and since it's unlikely users know the names of articles on the site, users are very likely to search by topic rather than by the name of a piece of content.
On Amazon, you can search for a Harry Potter book by its title, its author, or a variety of other identifiers, but this is only true because Harry Potter–related items have identifiers. In UIE's study, however, for non–uniquely-identified content such as toys, apparel, or pet supplies, search only worked thirty-one percent of the time. Most web content lacks these memorable identifiers, making it very difficult to produce a decent set of search results. And indeed, this is where Amazon starts to get into trouble. In addition to selling books, the site offers electronics (among a huge variety of other types of products). What terms did users in UIE's study enter when searching for a DVD player? Well, they didn't enter Panasonic DVD-RV31K DVD Player (Black) (the product's actual name). They didn't even enter Panasonic (the manufacturer). When users sought DVD players, they typed DVD player.
This is typical for non–uniquely-identified content. When looking for a pair of Frye boots, one user typed boots. Another user, looking for colored pencils, entered craft supplies. A user looking for pearl earrings typed not earrings, just the very generic jewelry.
While there are non–e-commerce sites that have uniquely-identified content, they are rare. The United States Patent and Trademark Office (PTO), for example, lets users look up trademarks by attributes such as name, trademark holder, and the attorney of record. Search for James Spool under the attorney of record, for example, and you'll get a peek into Jared's father's work. But the PTO is the exception, not the rule. It is more likely that the majority of content on your site will fall into the non–uniquely-identified category.
And even on sites full of uniquely-identified content, there are exceptions when users want to find something by a means other than using the identifiers. For example, one user who had been listening to Celtic music every morning on the radio wanted to purchase a good introductory CD to the genre. Typing celtic into Amazon's Search box revealed 889 results, but provided no sense as to which CD would be a good introduction.
In other words, although designers are often incredibly tempted to follow Amazon's lead, the site you should probably pay the most attention to from the list above is the one that matches the model of most sites: Cancer.gov.
)
Figure 4.2 Non-uniquely-identified content makes for more complicated search result requirements.
When trying to locate non–uniquely-identified content, site navigation (such as category links) is the way to go. On Cancer.gov, when searching for an article on, say, brain cancer, users will be more satisfied using the site navigation rather than by searching. A user is unlikely to know an article by its name or author when visiting the site for the first time (or even the tenth), and therefore will locate content one page at a time, one link at a time. And this isn't a bad thing; UIE's research indicates that, contrary to popular opinion, users don't mind clicking a few more times as long as they believe each click draws them closer to reaching their intended goal. And increasing the number of pages a user views creates opportunities for businesses to expose that user to more content, including ads.
The caveat, of course, is that this approach only works when a site provides the right trigger words. Users turn to search functionality when they can't spot their trigger words—when site navigation fails them. In other words, when people use search systems, they're trying to find links to content they couldn't find otherwise. They're trying to create links that aren't already there.
(For an in-depth look at trigger words and how they affect a user's ability to locate content, Jared's report "Designing for the Scent of Information" is available for purchase at http://www.uie.com/reports/scent_of_information.)
You can safely rely on your site's search system when you meet all three of the following conditions:
- Your content is uniquely identified.
- Your users are familiar with the identifiers.
- Your users want to use those identifiers as the mechanism for locating the content.
To determine whether or not you meet these conditions, look no further than your search logs. If you spot a lot of category names, like jewelry or men's pants, instead of specific content references, then your content is non–uniquely identified content. If you don't meet any of these conditions, you'll need to find another navigation strategy for your users to succeed.
Beyond this strategic view of search, there are also quite a few low-level details to consider, such as a search field's position on a web page, its constancy throughout the site, field label, button label, and whether or not to offer a category menu or autosuggest functionality. We're leaving these details, however, to the curators of design pattern libraries. Our intention is not to document these patterns in this book, but rather to offer insight into why they are included in this framework and how they affect a user's experience with searching on a site.
Search Results
There are just two types of search results pages and four possible outcomes for any given search.
The first type of results page is the Search Gallery, and it's the one with which you are probably most familiar. It's simply a gallery, like that in the catalog framework discussed in Chapter 3. The only significant difference is that the collection of results presented on a search gallery page is created entirely on-the-fly based on the user's search.
)
Figure 4.3 features a search gallery, the first type of search result page.
In other words, the search gallery is a straight results page. The one you expect to see every time you run a search. The one Google uses.
One significant caveat with many search galleries is that they suffer the same problem as standard galleries: in the vast majority of cases, search results all receive the same treatment regardless of which design patterns might be most helpful for specific items. Since images are helpful for many items on Bestbuy.com, such as headphones, images are then used for all of Best Buy's products, including digital SLRs (single-lens reflex cameras), where images become significantly less helpful.
Regardless, search galleries are by far the most pervasive type of results page. In fact, every search engine we've ever seen delivers results in this format, including those that also offer the second type of results page: the search department page.
A search department page is a set of results that closely resembles a category page from the catalog framework. It may look different than the other category pages on a site, but its scope is the same. It presents links to an array of galleries and encourages users to further winnow their options before showing them a specific gallery. The search department page is basically a trick the designers use when a site has results that span too many categories to intelligently organize them in a search gallery page.
A shopper's search for Nintendo Wii on Bestbuy.com, for example, could be a daunting challenge for site designers. Does the user want the Wii game system, games that go with the system, accessories, branded clothing, toys, or something else? There's simply no effective way to guess the user's desires, and the only way to cull this truckload of possible items into a search gallery is to organize them into labeled sections. Of course, once you do that, you create, essentially, a category page.
)
Figure 4.4 offers a search department page to highlight products related to the Nintendo Wii game system.
Search Outcomes
Regardless of the type of results page, there are four possible outcomes for a search.
- Exact or very relevant match. The user is offered results that lead her directly to the content she is seeking. This happens when the user searches with terms that match those used by the site and, specifically, within the content the user is seeking. This is ideal, as it puts the shortest distance between the user and the desired content.
- Related items. The results are related to, but not quite, what the user is seeking. This might occur when the site lacks the exact content the user is seeking or when the user searches using slightly different terms than those that would lead to exact matches.
- Irrelevant results. The user is offered results that are in no way related to the content she is seeking. This happens, of course, when a user searches using terms that don't match the site's terms, but it also happens when a search system is ineffective. For example, a search on Men's Pyjamas that returns every result that contains Men isn't helpful.
- No results. The search yields no results whatsoever. This occurs either when users search using too many keywords for the site to produce matches, when a user misspells search terms, or when the site simply has no matching, or even relevant, results. Particularly rigid search systems might also show no-results pages when the user simply uses natural language rather than specific tags. No results can be good if no relevant content exists on the site, but if the content is there and the user simply isn't finding it, it's a problem.
The first outcome in the above list is by far the best. The other three, however, can lead to disaster because, as it turns out, users really don't try too hard to succeed with search. In looking at the search patterns of thirty users shopping on e-commerce sites, UIE's researchers focused on those search attempts where search failed to help the user find a result. Interestingly, forty-seven percent of the users who failed only tried the search engine a single time. Another thirty percent tried twice. Less than twenty-five percent tried more than twice to get the search engine to produce a successful result.
Now, the designers of many of the tested sites went to great lengths to get users to continue searching. They put in encouraging search tips that said things like, "Try a new search using different terms." However, there was no evidence that these tips encouraged any user to search again. They mostly assumed that the first (or maybe second) try was the best they were going to get. For example, Bed Bath & Beyond's site encouraged a user who was searching for curtains to "use a generic term like pans or coffee to broaden [her] search and increase the number of items found." What, exactly, is a generic term for curtains? These results indicate that designers get one, possibly two chances to help users find their content via search. If most of the users don't find what they want in the first try, it is unlikely they will ever find it.
Incidentally, these results aren't unique to e-commerce sites. For years, similar results have been seen on intranets, corporate and institutional information sites, and any other type of site with a search capability. The data from UIE's e-commerce study simply proves what has long been suspected. More and more, UIE's ongoing research indicates that search has to be perfect. Users expect it to just work the first time. Every time. Most search systems, however, don't even come close. In fact, the more times the users in this study searched, the less likely they were to find what they wanted. On a single search, users found their content fifty-five percent of the time, whereas users who searched twice found their content only thirty-eight percent of the time. None of the users in the study who searched more than twice ever found their target content. The users (less than 25 percent) who persevered still did not reach a positive outcome.
The number one motivator for revising and running new searches was the "no results" message in response to a query. Most users give up when they see it (although some do try their query a second time).
Here's what happened in the study:
- On the first search attempt, twenty-three percent of users got a message indicating there were no results.
- Of the users who kept going, forty-four percent got a no-results message on the second attempt.
- If they still persisted, fifty percent got a no-results message on the third attempt.
- One-hundred percent of those who persevered through a fourth attempt got a no-results message.
In theory, as people use a search system, they should get better at making it perform. After all, each successive interaction is an opportunity to learn the idiosyncrasies of the tool. But in UIE's study, users didn't seize the opportunity. For users who didn't succeed up front, things went rapidly downhill.
Encouraging users to continue with helpful hints doesn't help. As we mentioned before, many sites provide hints on the "no results" pages that try to encourage users to enter different search terms. Unfortunately, the presence of these hints didn't improve the odds that a user would get better results the next time around.
A telling fact is that the users in the study were asked specifically to go to sites that had the content they were seeking, but one out of every five users landed on a no-results message on their first attempt. This indicates that there is something fundamentally wrong with the design of many search systems.
The key for designers seems to lie in getting users relevant results on the first try. The sites that do are most likely to succeed.
Advanced Search
The most known version of advanced search is likely the one accessed via an Advanced Search link, usually positioned next to a Quick Search field. But this is probably not the most frequently used version. How can this be so?
To begin with, advanced search in its traditional form isn't as widely used as one might expect. Informal observation has shown us that it's extremely rare to come across a group that consistently uses advanced search, and outside that group, it's hardly used at all. In fact, it's possible that the only people who really care about advanced search are librarians, and perhaps people in similar situations. Librarians have an almost constant need to find very specific information for customers, and this information is often obscure enough that a plain old search just won't cut it. These searches may involve not only finding obscure information, but also locating the information in specific media types or in certain editions or versions, and being able to verify the reliability of the information. Advanced search can work wonders for cases like these. But most people aren't in this situation most of the time. For most users, most of the time, advanced search is overkill.
But there is a second type of advanced search that is used quite frequently, and it doesn't at all appear advanced. We'll call it Qualified Quick Search.
Qualified Quick Search is a form of Quick Search that requires additional criteria—qualifiers beyond keywords—to be effective. The search requirements on travel sites are a prime example.
For example, to book a flight on Southwest.com, users are asked to choose the departure city, arrival city, departure date, return date, and the number of adults and children who need tickets. The car rental site Hertz.com asks for the city where the car is to be rented, pick-up and drop-off times, and the desired car type. To book a hotel room on Hilton.com, users specify the city and state in which they'll be staying, check-in date, check-out date, how many guest rooms are needed, and whether or not to expand the search to all Hilton hotels and to a wider geographical area.
)
Figure 4.5 Hilton asks users for check-in and check-out dates as part of its Qualified Quick Search.
For any of these sites to provide good results, they need to know a lot more information than that the user wishes to "schedule a trip to Atlanta." They can't deliver meaningful results until they have an exact collection of details.
)
Figure 4.6 Cancer.gov points users to a separate search option specifically designed for clinical trial searches.
Cancer.gov offers a variation of this, also with the goal of meeting a specific need. Users looking for clinical trials are unlikely to know how to search for them through the site, so the site designers created a page enabling users to search for clinical trials, which includes a variety of qualifiers. What makes this different than advanced search? Frankly, nothing, save for the choice in wording. Instead of an Advanced Search link, it offers a Search for Clinical Trials link. The problem with advanced search is that users don't necessarily think they have advanced problems, but rather simpler problems they don't know how to solve. Simply changing the label can change the user's level of agreement with the functionality.
Supplying the search form for clinical trials also educates users on the factors distinguishing one trial from another. A trial's status, phase, treatment type, ID, and sponsor are all things that narrow down the options. But if their only option for doing so were a Quick Search field, would every single user on the site know to enter all of this information? Not a chance. But they may learn from this alternative functionality and apply that knowledge later on.
Amazon and many other sites offer a simpler case. Since typical search terms can fall across a number of categories (such as the search for the Nintendo Wii, whose results span electronics, toys, clothing, and others), these sites often add a drop-down menu to their Quick Search implementations. In doing this, they ask users to qualify their search terms with specific criteria, much in the same way that Southwest asks users to qualify their search with departure and return dates.
This, then, is a version of advanced search, in that it requires qualifiers beyond that of simple keywords. But it's also quite different from advanced search, because these criteria are usually required rather than optional, and few criteria are needed, whereas advanced search frequently offers a vast array of filtering options. It's simpler—it asks only that a user better qualify her search before running it. Hence, Qualified Quick Search.
When designing an on-site search system, it's important to consider whether or not advanced search is necessary. There may be a selection of users who will occasionally benefit from it, but if your site is like most—that is, its primary users are not librarians—you can probably get away with not building an advanced search page. If, however, you need very specific information from every user before you can deliver any sort of meaningful results, Qualified Quick Search may be the perfect solution.
Filters
Filters are another form of advanced search, with two key distinctions.
First, filtering options usually appear only after an initial search has been run, with the goal of helping users reduce the options generated by an initial search, while at the same time increasing the accuracy of the results. On the travel-booking site Kayak.com, as shown in Figure 4.7 for example, once a user has specified her initial qualified search criteria, such as her travel dates and destination, Kayak's search results page offers a sidebar filled with options to further narrow down the choices. This elaborate set of filtering options would be overwhelming if presented on the home page, where the goal is to get the user started as painlessly as possible, but on the results page—in the context of search results, alongside them—this sidebar gives the user the power to see how she might further improve her results, and do so without modifying her search to include all the information the site needs to generate better results.
)
Figure 4.7 Because they feature a background color used throughout the search results design and don't stand out, Kayak's filtering options can be difficult to spot.
Second, filters can be presented in a wide variety of ways. They can be as simple as keyword links that go to subcategories or other content pages; or they can be as elaborate as a collection of sliders, check boxes, and radio buttons that trigger real-time updates. Kayak offers these real-time updates as well. By limiting the airlines and times of day a user prefers to fly, she can easily pare down the results to see only those that perfectly match her criteria. And this happens as soon as the user changes a setting in the sidebar filters: the list of search results auto-updates so she can almost immediately see the effects of the changes rather than wait for the page to reload with a new set of results.
The caveat to using filters is that for users to take advantage of them, they have to first notice them, and this can actually be trickier than it might appear. Kayak users often entirely ignore the sidebar full of filtering options and instead scroll through as many results as it takes for them to find the flights that match their needs. (Because travel-related searches almost always begin with a Qualified Quick Search, and because Qualified Quick Search typically asks for specific information without allowing the entry of free-form search terms, travel booking is one of the few situations in which users persevere through a potentially large number of results without modifying their search criteria.) Of course, going through all those results can be quite time-consuming, but users who don't notice the filters often appear to think that doing so is their only option. The key, then, is making sure the filters are noticeable. If positioned in a sidebar, for example, filters can be made more noticeable via the use of a background color that stands out against the background of the search results page itself. One site Robert reviewed recently used the same background color in the sidebar as in the page's header area (orange, when the results area had a white background), and as a result, the company's usability tests showed that users were not having much success finding and using the filters. (Your results may vary, of course, but as a rule, color contrast is a very good way to draw the eye to a specific page area.) But again, there are many ways to present filters—a sidebar full of filter controls is but one of them. The designers at Orbitz.com made its filters appear as part of the search results themselves.
)
Figure 4.8 The Orbitz design team integrated filters into the result set.
Along the top of the results area, Orbitz features a matrix showing a selection of airlines offering flights at different price points. As the user hovers her mouse over a square in the matrix, an alternative background color is shown to highlight that square, as well as the column and row headings that indicate the number of stops on the trip and the airline offering the flight. Since the prices themselves are shown, the matrix blends right in with the results themselves, making the filters a seamless part of the search process.
As you can see in Figure 4.9, Google takes an arguably simpler approach: suggested search terms are offered via two rows of links at the bottom of each results page, allowing the users who make it to the bottom of the page to simply click once to run a modified search. That is, if the user actually sees the links. And as we've pointed out, the odds aren't particularly great that a user's results will improve beyond the first search.
)
Figure 4.9 Google puts its filtering options directly in context—in line with other results, at the bottom of the page.
Pagination
As part of its status as the gold standard in search, Google has popularized many design patterns, one of which is the pagination pattern. The interface, which offers a series of linked page numbers that are bookended by Previous and Next buttons, enables users to navigate back and forth between a set of search results pages, as well as skip ahead or back several pages at once.
Google may not have been the first site to make use of this particular pattern—it was used by several popular search engines prior to Google's inception back in 1997—but the all-powerful search site almost certainly made it the most popular version of a pagination interface on the web. Since Google implemented the pattern, it's been emulated on countless systems, including other major search sites, and even a huge number of catalog sites from news to commerce. Unlike most others, however, Google opted to instill a sense of playfulness into the design by increasing the number of letters (specifically, the letter O) in the name Google according to how many numbered page links are shown on a given results page.
)
Figure 4.10 Google's pagination interface, the defacto standard for search systems.
Although this playfulness contributes to the personality of the Google brand, it's by no means a necessary quality. The important part, from a usability perspective, is that the interface provides a method for getting back and forth within a series of pages. And it does that just perfectly. Showing page numbers sets an expectation that there are more results that can be easily accessed. Offering Previous and Next buttons with adjoining arrow icons gives users a sizable hit area and keeps them from struggling with the much smaller numbered links. Styling the current page number differently communicates to users where they are in the set of results pages.
It's when designers get crafty with pagination design, in fact, that things start to get messy for users. The prime example of this is the so-called infinite scroll pattern. The idea is simple: rather than distribute results across a series of pages, all results are loaded into a single page. On paper, this makes sense, as it eliminates the need for users to click to access results beyond the initial set and wait for new pages to load. However, infinite scrolling breaks a number of expectations for users and causes quite a bit of confusion (and perhaps even a broken keyboard or two).
Based on informal observations, because users expect to encounter the pagination interface at the bottom of results pages, the lack of one can be an unwelcome surprise. For example, in an informal study, users were asked to find a specific photograph buried deep within a set of results for an image search with an infinite scroll. One user, who was typical of the users in the study, went to great lengths to reach the end of the page. At first, he used the mouse to drag the scrollbar down. When this didn't work, he moved his mouse to the small arrow control at the bottom of the scrollbar and began clicking repeatedly to see if that helped. When this failed him, he resorted to the down-arrow button on the keyboard. When even this didn't help, he began pressing the button with more force, apparently believing that the sheer power of his intention would give him the desired result, much in the same way a video game player twists his body in all directions hoping to manipulate a character into moving in the right direction. Eventually, he started mashing down the button with enough force that the sound was audible in a screen recording of the experiment. That poor keyboard took quite a beating that day.
Again, puppies are cute, bugs are icky, and Google just works.
On a more thematic note, the pagination interface is a good example of the limitations of design pattern documentation. On the popular pattern library site Welie.com, the pagination pattern (which the site calls the "paging" pattern) includes a problem description that simply states, "Users need to browse through a large list of items looking for the item that interests them most." While this statement indeed describes, quite literally, the problem that the pattern solves, it doesn't say anything truly meaningful about the user's real problem. It doesn't reveal how the pattern fits into the larger context of searching—the when, how, and why of search. Here again is why frameworks are a necessary evolution of design patterns. Frameworks put design patterns back into context.