Faceted search has been around for a long time and has become the de facto standard for search on most ecommerce sites. However, filters with numeric values remain among the most confusing, because many sites have not able to design usable numeric filters that people can use in an intuitive manner. Recently, powerful user interface controls called sliders have become all the rage for specifying numeric attributes in finding user interfaces. Unfortunately, in their rush to implement this latest, greatest feature, many companies have not designed easy-to-use sliders. Rather than solving usability problems, poorly designed sliders create even more issues around numeric filter usability. In my experience, the following three usability issues surface most often with numeric filters:

• representing discrete values for aspects as sets of ranges
• inadvertently emphasizing overly constrained filter states
• being parsimonious with inventory information

In this column, I’ll examine each of these issues and present the best practices that solve these problems. 

Representing Discrete Values for Aspects as Sets of Ranges

One of the most common pitfalls with numeric aspect filters is their representing discrete values as sets of ranges. What makes a filter value discrete? Certain types of products typically have widely recognized, discrete values—for example, a digital camera might have a 10MP resolution and a lens with 3X zoom—which can often consist of either whole numbers or fractions. These discrete values tend to be consistent across competing brands and models and rarely change from one vendor to the next.

Many sites offering faceted search do not present discrete numeric values for aspect filters in the most useful fashion. Designers are often tempted to present such values to customers as sets of ranges. Presenting discrete filter values as a set of ranges typically results in a user interface similar to that in Figure 1, showing a camera-resolution filter on a major ecommerce site.

Figure 1—Camera-resolution filter with values presented as a set of ranges

My usability studies have shown that many people have trouble finding 10MP within a 9.9MP-11.9MP range and applying the filter correctly. The problem is a mental model mismatch. People don’t think of 10MP as falling within some range. When customers look for discrete values in aspect filters, they are most often looking for a specific value—for example, 10MP—that forms a critical part of the information scent. Most people typically think of a camera resolution as a specific value—not as a numeric value within some range.

When users try to look for the value 10MP within a range, usability problems arise, because the resolutions 9.9MP and 11.9MP simply do not exist as discrete values. While, numerically, it is true that 10MP lies within a 9.9MP-11.9MP range, this range has very poor information scent and requires additional thinking and interpretation on the part of users, which does not make for intuitive and efficient finding. Having to think hard just to find something causes problems for users.

In my user research, I have often observed that people who are in a rush, distracted, or simply not that great at working with fractions in math often select the wrong range of discrete values, wonder why they are not getting the results they expected, get frustrated, and quickly leave a site to navigate to a more usable one.

Instead of providing ranges, it is much more effective to present lists of discrete values, showing all of the possible values for an aspect filter. If doing this results in a filter with too many options, simply rounding off the value to around 10MP works very well, as shown in Figure 2. (Note that the word around is usually implied. Although it sometimes shows up in a short form such as ~10MP or 10+MP. However, this extra precision is usually unnecessary, as I will explain in a future column.)

Figure 2—Recommended redesign of camera-resolution filter

When a customer clicks a link representing a discrete value, one option is to expand a list of subvalues—for example, clicking an around 10MP link would show all of the available subvalues: 10.0MP, 10.2MP, 10.3MP, 10.4MP, as shown in Figure 2A. Should you bother designing and implementing this? Usually not. Unless your customers are professionals who might be looking for a particular value, they typically would not drill down past the around 10MP link. Is there really that much difference between digital-camera resolutions of 10.2MP and 10.3MP to a typical consumer? So, unless your company’s inventory is extremely large or you have a very specialized clientele, it is often much more useful to present an approximate value like 10MP.

Should you support single or multiple selection for displaying discrete filter values? The answer is always: It depends. Up until a few years ago, guidelines generally recommended the simplicity of single-selection links for discrete values. Today, however, I highly recommend that my clients implement multiple selection for discrete filter values—provided the finding user interface also supports multiple selection. Mark Burrell of Endeca echoed this sentiment in the 2010 UIE Webinar, “Leveraging Search & Discovery Patterns for Great Online Experiences,” in which he emphasized that most ecommerce customers no longer find multiple selection hard to use and prefer the flexibility it offers.

Numeric Sliders for Filters

Numeric sliders have recently become the rage for faceted search. Sliders can add a touch of interactive fun to what many business people refer to as a boring finding interface. Note that boring user interfaces usually work extremely well, because they are intuitive and easy to use, and UX powerhouses like Amazon and Netflix do quite well without any sliders whatsoever.

That said, sliders can be helpful in some applications, because they give people tremendous filtering power when they are implemented correctly. With great power, however, comes great responsibility: Sliders deserve special consideration from designers—precisely because they make it so easy for your customers to screw up and overconstrain their queries, leading to search results that are either incorrect or of poor quality. This, in turn, results in frustrated customers who leave your Web site quickly without buying anything. The two issues I see most often with sliders are:

• inadvertently emphasizing overconstrained filter states
• being parsimonious with inventory information

Let’s take a closer look at each of these issues and what we can do about them.

Issue: Inadvertently Emphasizing Overconstrained Filter States

To examine the issue of overconstrained filter states, let’s take a look at an example—the slider rating control on TripAdvisor, shown in Figure 3. Ratings seem deceptively simple, yet raise a host of usability issues when they are implemented incorrectly.

Figure 3—Slider rating control on TripAdvisor

TripAdvisor has implemented ratings using a double slider control, which presents a perfect example of inadvertently emphasizing overconstrained filter states. This double slider control allows a wide variety of ranges—some of which are much more useful than others when it comes to finding particular items or content of interest. For example, rating ranges spanning only a single star—such as 0-1 stars, 1-2 stars, or 2-3 stars—are simply not useful, because short ranges do not match the mental model of the people using the system.

Most of the time, people click a rating filter to get all of the merchandise above a certain rating—that is, as a way to find higher-quality items in their search results. However, a double slider control overemphasizes the ability to constrain the range from both sides, making it very easy to get this wrong by overconstraining a query.

A much more useful way of approaching this design problem is to use a single slider or a set of links like those shown in Figure 4, which shows ratings as they are currently implemented on Amazon.

Figure 4—Amazon’s more useful implementation of ratings as links

We could further improve the rating control shown in Figure 4. Since the goal of people using this control is to get better-quality items, it is not actually that useful to show only a single star—the lowest possible rating. Instead, it might be more intuitive to replace the single star with the word Any and make that the default filter state. The filter shown in Figure 4 also has the important added advantage of providing vital inventory information. Item counts following each set of stars help people using the ratings filter to clearly understand the consequences of their actions and builds appropriate expectations. Understanding what to expect from their actions lets people be more efficient and effective, leading to higher customer satisfaction and better usability. Next, we’ll explore how we can use sliders to show inventory information.

Issue: Being Parsimonious with Inventory Information

Do all dual sliders emphasize overconstrained filter states? Not necessarily. For some filters dual sliders are entirely appropriate—for example, for price ranges. However, the problem that I described earlier of overconstraining queries and, as a result, providing inadequate information never really goes away. As Figure 5 shows, the dual slider control for the price range filter on TripAdvisor provides no inventory information, so customers would have no idea what the effect of manipulating the sliders might be. Any action customers take might be a hit or a miss—but it is never clear in advance which it will be, because the system simply does not provide the necessary inventory information.

Figure 5—Dual-slider filter for price range on TripAdvisor

Compare the dual slider for price range on TripAdvisor to the price control on Staples.com, pictured in Figure 6.

Figure 6—Price control on Staples.com with multiple check boxes

As I mentioned in one of my previous columns, “The Mystery of Filtering by Sorting,” overconstraining search results by price is one of the most common human errors we see in usability testing for search user interfaces. Which control would you expect to result in more overconstrained queries: a dual slider or a set of check boxes? The control that makes overconstraining results easier is the dual slider, because it gives no clue as to what to expect from a particular action. On the other hand, the dual slider provides the bling many business people crave as a means of differentiating their user interface from the competition.

In this age of highly interactive Ajax interfaces, clicking links or typing in numbers to specify a price range seems so old-fashioned. Is there a control that would provide the interactivity and fun of the slider, yet offer the inventory information so necessary to helping customers make informed decisions?

One approach would be to use a dual slider for setting a price range, combining it with a sparkline that graphically represents the available inventory information for every price in the range. Figure 7 depicts my suggested redesign of the TripAdvisor price filter, which combines a dual slider with a sparkline, showing the available inventory for each price in the range.

Figure 7—Suggested redesign of the price range filter on TripAdvisor

In his book Beautiful Evidence, Edward Tufte describes sparklines as “data-intense, design-simple, word-sized graphics.” Although I have no idea who first thought of combining a slider with a sparkline, I have been recommending this solution to my clients for over four years, and I can claim to have arrived at this idea independently. Unfortunately, so far, most of my fellow designers and the business people with whom I have worked have remained cold to this idea, stating that a slider with a sparkline would be “above and beyond what an average user could understand.” However, my own experience as a user researcher backs the opposite conclusion. Every usability test participant who has seen the user interface in Figure 7 has confidently stated that he or she understood that the sparkline represented the number of items available, eloquently proving once again that “clarity and simplicity are completely opposite of simple-mindedness,” as Tufte said in his book Envisioning Information.

Recently, during the UIE Webinar I mentioned earlier, I was supremely gratified to hear Mark Burrell of Endeca recommend dual sliders with histograms as one of the best ways of showing price ranges. Burrell’s experience with dual sliders was similar to mine: he said that most people have no trouble understanding that histogram bars—a step-wise variant of a sparkline—represent item inventory for each part of a slider’s range and that histograms clearly help people to avoid overconstraining their queries.

In Conclusion

In our age of rapid development, new ideas and new controls hit the Web almost every day. Even as companies are struggling to overcome the old challenges of numeric faceted filters, designers are innovating interesting new controls with which they can solve those challenges. One such control is the slider, which gives unparalleled power to customers. However, successfully offering this power requires careful UX design in order to avoid potential pitfalls. Again, the following three issues with numeric filters surface most often:

• representing discrete values for aspects as sets of ranges
• emphasizing overconstrained filter states
• being parsimonious with inventory information

Designers’ uninformed use of sliders for filters often exacerbates these issues. In this column, I have presented best practices as well as some novel approaches to help designers overcome these challenges. But there is simply no substitute for empathy and solid qualitative user research. Understanding why customers do certain things is extremely important in designing effective user interfaces. No matter what metrics we have, we cannot improve our user interfaces unless we understand what our customers’ goals are and why people fail to reach them. With every new filtering innovation, it becomes ever more important to stay focused on our customers, with patience, empathy, and understanding.

References

Morville, Peter, and Mark Burrell. “Leveraging Search & Discovery Patterns for Great Online Experiences.” UIE Virtual Seminar, 2010. Retrieved February 7, 2010.

Tufte, Edward. Beautiful Evidence. Cheshire, CT: Graphics Press, 2006.

—— Envisioning Information. 4th ed. Cheshire, CT: Graphics Press, 1990.

Our language is limited and imperfect. Typically, people type search queries quickly and with little forethought, so queries are definitely less than perfect. When a customer constructs a query that may have more than one meaning, a good search user interface provides tools to help the customer define the query in less ambiguous terms, so the search results more closely match the person’s intention. This process is known as disambiguation, and best practices for effectively supporting the disambiguation of search queries are the subject of this column.

Recently, I came across a new search engine—which shall remain nameless—that promised a combined search and browse approach to finding products. I was curious, so I put this new search application through its paces by typing the query Canon. In addition to results for cameras, the search engine displayed results including the company’s profile for investors, Pachebel’s Canon—a form of music—and, to my great surprise, a Canon mattress and a Canon ottoman, which the products section featured prominently.

Unfortunately, these search results represented a fairly typical situation that occurs when a search application does not correctly understand the meaning of a query. Especially frustrating was the fact that the user interface did not provide any tools to help people to refine their queries and, thus, improve the quality of their search results. The only way people could improve their search results was by typing more keywords into the search box, which takes both thought and work—two things any busy, distracted Internet user can do without.

In her recent column on UXmatters, “First, Do No Harm,” Pabini Gabriel-Petit quoted Jef Raskin: “A computer shall not waste your time or require you to do more work than is strictly necessary.”

What can we do to remedy this situation? In this column, I’ll discuss three simple strategies designers of search applications often use to help people resolve ambiguous queries:

1. Show related searches.
2. Select a default category automatically.
3. Prominently display a category selector.

Let’s look at the advantages and limitations of each approach.

Showing Related Searches

Related Searches is a fairly standard module on mainstream ecommerce sites and search engines. Figure 1 shows an example on Amazon.com.

Figure 1—Amazon’s Related Searches module in the search results for Canon

Most search applications track how people modify their original queries, then apply an algorithm to this tracking data to display the most common modifications to queries in a Related Searches module. As Figure 2 shows, people who typed Canon augmented their queries by typing Canon camera, Canon lens, or other more specific queries.

In her recent book, Search User Interfaces, Marti Hearst discusses the related searches algorithm in detail and quotes several impressive studies that document the effectiveness of this approach. Indeed, in my own user research, most people have found the alternatives a Related Searches module presents very relevant and clicked them to find what they wanted—mainly because of their very good information scent. Related searches often seem to present the keyword combinations people had unconsciously desired, but could not quite formulate themselves without more thought.

Essentially, a Related Searches module eliminates the effort and thought creating a good query requires, making a search user interface more intuitive and enjoyable, without using a great deal of precious screen real estate. The back-end algorithm for this module does require a fair bit of infrastructure to implement the query tracking. However, some APIs like Yahoo! BOSS are now available to make the job easier.

In my studies, I discovered people had a positive response to most suggestions revolving around modifications of their original queries, because of their very strong perception that the recommended queries represented the combined wisdom of crowds—as with tagging and folksonomies. However, many people I observed were highly suspicious of any orthogonal queries that recommended competing brands or products.

For example, in Figure 1, a related query that recommends Nikon in response to the query Canon would quickly cause people to become mistrustful and question the value of all suggestions in the Related Searches module. For this reason, I recommend that search user interfaces concentrate on showing only query modifications in their Related Searches modules. Show competing products and brands in a different module instead—for example, in a sidebar. You can easily limit search results to those that contain the original keywords with a simple grep command. Done properly, a Related Searches module is a very useful device for helping people disambiguate their queries and improving the quality of their search results—thus, creating a better finding experience.

Selecting a Default Category Automatically

Displaying only search results belonging to a specific category or topic by default is another very common strategy for disambiguation. An ecommerce system can determine what category or topic to display by default, using supply data, demand data, or some combination of the two. Supply data refers to the number of distinct product or content entries currently available in a site’s inventory that match a certain keyword query. In contrast, demand data refers to the number of people who selected products from a specific category after typing the same keyword query during a given period of time.

To automatically determine the default category using supply data, an ecommerce system might fairly easily measure the number of items currently in the inventory that match a specific keyword query. For example, if 70% of the items that match the query Canon belong to the Digital Gadgets category, the search algorithm might automatically display results in the Digital Gadgets category whenever a customer submits that query—omitting results in Music and other categories. A more sophisticated way of doing the same thing would be to use demand data to determine how many customers in the last week proceeded to view or buy items in the Digital Gadgets category after searching for Canon versus products in all other categories; then, if the number exceeds a certain threshold, to display the Digital Gadgets category of results by default.

What are some advantages of selecting a category of results by default? Automatically interpreting the query Canon as a request for Digital Gadgets, then showing a Canon brand product catalog lets Best Buy create a very compelling visual browsing experience, complete with custom subcategories and aspects, as shown in Figure 2.

Figure 2—Best Buy search results for Canon

I’ll cover best practices for product catalogs in more detail in future columns, but for now, notice how extremely committed this category selection is in comparison to the Amazon search results for the same query, shown in Figure 1. Not only is the Canon brand selected, there is no trace of any results matching Canon for other types of products on the site. This provides a great user experience for someone looking for electronic gadgets, but it could be very confusing to someone looking for something in the category Music, for example.

A final word of caution: Automatically selecting a default category or topic is a very committed action, so communicating how to undo this action can be a challenge. Evidence shows that half-hearted measures for indicating the presence of other results on a Web site do not work particularly well.

Here is an example. When doing some user research for one of the top Web retailers, I tested a memorable user interface that automatically selected the category Shoes when a user typed the query Nike. However, unlike the Best Buy user interface shown in Figure 2, the user interface I was testing also provided a prominent link to let users undo the category selection—Not looking for Nike Shoes? The usability test task involved finding Nike bags. The study’s significant finding was that the vast majority of participants did not discover or click the link Not looking for Nike Shoes?

I theorized that this might have occurred, because the link did not contain any information scent for the category Bags for which participants were searching. Additionally, when people quickly scanned the page—as most people tend to do—mentally processing this negative statement was fairly difficult. Dynamically displayed links for other Nike categories that started with strong keyword scent words might have been much more successful—for example, Other Nike products: Bags, Shirts, Pants, Jackets, More….

The moral of this story? If you do commit to using a default topic or category as part of your disambiguation strategy, make sure it is for a good reason, based on metrics that help your company meet its business goals. Decrease your company’s risk by providing a clear way out of the default category, using links that start with prominent keywords and provide strong information scent for other popular categories or topics matching a keyword.

Prominently Displaying a Category Selector

In addition to a Related Searches module, most ecommerce sites also provide a category selector widget. Notice that, in Figure 1, Amazon presented its available categories in a navigation bar on the left. While this strategy is pretty standard and widely accepted, some sites go still further, emphasizing their categories as a strategy for disambiguation. For example, compare the Amazon search results shown in Figure 1 to The Home Depot search results for drill, in which the categories appear prominently above the search results, as shown in Figure 3.

Figure 3—Home Depot search result categories

There are many good reasons for emphasizing categories as part of your disambiguation strategy. Prominently displaying categories above search results clearly signals to customers that their queries may have more than one meaning on a site. Providing categories also lets customers correctly customize search results by selecting a category, then aspects or other finding tools matching a specific category. For example, the category Drills might feature the aspects Power Tool and Hand Tool, while the category Drill Bits might have the aspects Size and Hardness. Showing categories above the search results—as opposed to in a navigation bar on the left—also allows the display of longer category names without wrapping, providing improved information scent without compromising readability.

However, as we can see in Figure 3, showing categories above the search results can also lead to some pitfalls. If you look carefully at Figure 3, you’ll notice that The Home Depot search results actually feature two separate category selectors—one in the navigation bar on the left, the other above the search results—which could be pretty confusing. The two sets of categories are not the same, leading customers to wonder where they should click and why. The links in the navigation bar are sorted alphabetically—not in their order of popularity—which is suboptimal. It’s not clear how the categories above the search results were selected or sorted or why they appear in such a prominent location. As a result, the categories above the search results feel a bit like a Band-Aid—letting customers jump directly to popular areas of the site.

Providing additional information scent for the main categories on The Home Depot site would serve that function better. Customers might expect each of the subcategories to be a separate link—so, for example, clicking Power Tools would display a level-two subcategory—but this is not the case. Instead, each link constitutes an independent selection, forcing customers to navigate three or four levels deep into the site hierarchy and make committed category selections before they’ve had a chance to see the wider inventory. Since each link exposes just a subset of a very detailed hierarchy, these links force customers to learn the site’s category structure to be able to make informed decisions.

Last, but not least, hierarchical categories can introduce a huge readability problem if many categories start with the same keywords. For example, seven of The Home Depot’s categories start with the keywords Tools & Hardware > Power Tool…, making it hard to distinguish the Tools and Accessories categories from one another and make the right choice.

This page displays far too many categories—fourteen, in all—above the search results. Plus, despite the generous amount of screen real estate the page allots to categories, the category names are too long, so they wrap. Together, these two factors push the actual search results way down on the page, placing all products below the fold at many screen resolutions. My research has indicated that many customers might be confused by this. Instead of scrolling, they might feel the site is forcing them to click a category before they can see any actual search results.

A better choice would be to commit to showing the first-level categories just once, above the search results, while avoiding wrapping, and augmenting them with additional keywords—as space allows—to help customers make the right choices. As Daniel Tunkelang notes in his book Faceted Search, showing four to seven values for each aspect seems like the sweet spot. His finding is well supported by my own research. Sticking to Daniel’s recommendation, I would reduce the number categories on The Home Depot site at least by half. The resulting user interface might look something like that shown in Figure 4.

Figure 4—Redesigned Home Depot results, with an expanding category widget

Figure 4 demonstrates an Expanding Category Widget design pattern that is very similar to a search user interface I recently redesigned for an enterprise client. The original design had very long category names, forcing categories in the navigation bar on the left to wrap three or four times.

Placing categories above the search results solved the problem, effectively handling long category names and providing a great way of disambiguating complex queries. However, be aware that even this improved user interface distracts customers from shopping. Prominently displaying categories practically forces your customers to deal with the complexities of your user interface and the category hierarchy on your site rather than actually shopping.

For a less ambiguous query, a good middle ground might be to automatically collapse the wide category widget to its standard size in the navigation bar, allowing users to drag its handle if they want to expand the category hierarchy again, as shown at the bottom of Figure 4. Judicious use of a simple animation, showing an expand/collapse transition might be very helpful in improving the attractiveness and usability of this widget. The Expanding Category Widget is a useful design pattern that might be worth exploring when determining your category-driven disambiguation strategy.

Conclusion

It is a fact of life that ambiguous queries are fairly common. In a post-Google world, most people expect a very high degree of relevance for search results after typing just a single keyword. They are often surprised and dissatisfied when your search user interface does not deliver. In this column, I’ve covered a wide range of tools and design patterns that can help reduce the thought and effort necessary to convey the desired meaning of a customer’s ambiguous query.

Numerous variations on disambiguation strategies exist, from adding a fairly simple Related Searches module to completely redesigning your search results page, following the Expanding Category Widget pattern. However, this column has not provided an exhaustive list of design patterns for query disambiguation. It is my sincere hope that this installment of Search Matters will inspire you to seek more information and explore new ideas for query disambiguation. It is only through trying out new ideas and careful experimentation that you can find the optimal approach for your Web site and your customers. Your customers depend on you to help them find what they are looking for. Do not fail them.

In my next column, I’ll cover another powerful, but underused design pattern, More Like This, which—among its many uses—can also be very helpful in query disambiguation.

Recently, Office Depot redesigned their search user interface, adding attribute-based filtering and creating a more dynamic, interactive user experience. Unfortunately, Office Depot’s interaction design misses some key points, making their new search user interface less usable and, therefore, less effective. That’s the bad news. The good news is that the Office Depot site presents us with an excellent case study for demonstrating some of the important best practices for designing filters for faceted search results, as follows:

1. Decide on your filter value-selection paradigm—either drill-down or parallel selection.
2. Provide an obvious and consistent way to undo filter selection.
3. Always make all filters easily available.
4. At every step in the search workflow, display only filter values that correspond to the available items, or inventory.
5. Provide filter values that encompass all items, or the complete inventory.

By following the attribute-based filtering design best practices this article describes, you can ensure your customers can take care of business without having to spend time struggling with your search user interface.

1. Choose either drill-down or parallel selection.

There are two basic ways of selecting values for filters: drill-down and parallel selection. Ignoring the various modalities of the many derivative mechanisms for these primary modes of selection, the two basic ways of specifying a value for a filter essentially boil down to two choices: links and check boxes.

A link is the simplest mode of filter selection. By clicking a link, a customer can either select a single value for a specific filter or drill down a level in a taxonomy, like a category or department hierarchy. Amazon.com, shown in Figure 1, provides one of the best examples of a search results user interface that uses links to indicate filter value selections. Links usually indicate a straightforward equals condition—for example, I want to narrow my search results to Department = Books—as they do on Amazon.

Figure 1—On Amazon, links let customers indicate a single filter value

In contrast to links, which let customers indicate a single filter value, check boxes let customers indicate parallel selections of multiple filter values, limiting the scope of search results to those that match them. The Kayak.com search user interface, shown in Figure 2, uses check boxes to limit search results to specific airlines. As on Kayak, check boxes typically indicate an additive OR condition—for example, I want to narrow the search results to: Airline = American OR Delta OR United.

Figure 2—Kayak airline selector uses check boxes to select multiple values

Links and check boxes complement one another very well. Links are great where customers need to display multiple levels in a hierarchy—for example, multilevel category drill-downs. Check boxes are great for selecting one or more options for attributes like brands or sizes. Unfortunately, not all Web sites use these two value-selection paradigms correctly.

As shown in Figure 3, the Office Depot user interface uses check boxes for indicating value selections, leading customers to expect a parallel selection paradigm, in which they could indicate they want to search multiple price ranges by clicking several check boxes. For example, to find chair mats that are priced from $0 to $100, you might expect to be able to select the price filter’s first two check boxes. Thus, after clicking the $50-$100 check box, you would expect to retain the ability to select the $50 and below check box.

Figure 3—Office Depot mixes the drill-down and parallel selection paradigms

However, once a customer selects the $50-$100 check box, the Office Depot search user interface does something completely unexpected. It drills down into the $50-$100 price range and removes the $50 and below check box, breaking the affordance of a group of check boxes that should let customers select multiple, parallel OR values for a single filter. Instead, the user interface now displays $50-$60 and $60-$70 ranges, while still displaying the range of $50-$100 the customer originally selected as one of the available OR values. Mixing the drill-down and parallel selection paradigms results in a very confusing search user interface.

Another confusing thing about the Office Depot user interface is that it does not provide any obvious way to deselect filters and return them to their original, pre-filtered state. This brings us to the next best practice: providing an obvious undo mechanism.

2. Provide undo for filter selections.

Both Amazon and Kayak—pictured in Figures 1 and 2, respectively—provide a clear and consistent way to undo a filter value selection and go back to All or Any for a specific filter. For example, Amazon provides a link to Any Department. Notice that the link is offset to the left, and a less than (<) symbol helps customers understand that this particular link goes back.

Under Airlines in Figure 2, you can see that Kayak solves the undo problem by letting customers click an All check box to view flights from all of the available airlines. Note that the Kayak undo is slightly less clear than that in the Amazon user interface, primarily because the All check box is neither highlighted in any way nor separated from the rest of the check box options. Instead Kayak highlights the airline that offers the best price. While not standard, this is hardly something that would cause undue confusion.

On the other hand, the Office Depot user interface, shown in Figure 3, does not, at first glance, provide an obvious way of undoing the selection of the $50-$100 price filter. There is actually a mechanism that lets customers do this, but it is not at all obvious. The way for a customer to return to Any price is to deselect all filter selections. While this design may be completely valid from a computer’s standpoint, deselecting all check boxes does not effectively communicate the concept of All Prices to a person using the user interface. It would be much more effective to provide an All or Any option.

There are sites that use the deselect-to-undo paradigm successfully—one fine example is Yelp.com. However, sites that use deselect-to-undo typically take special steps to ensure consistency in the filter value options that do not change based on other filter selections. For example, instead of removing options, the Yelp user interface makes certain filter values unavailable to indicate lack of inventory availability. Items that are unavailable appear dimmed, as shown in Figure 4.

Figure 4—Yelp ensures consistency in its deselect-to-undo paradigm

However, in cases where consistency is difficult to achieve, it is a far safer option to use Any or All to undo filter selections, particularly when a filter’s value options are dynamic. As shown in Figure 5, when a user deselects filters out of sequence on the Office Depot site, even more confusion results.

Figure 5—On Office Depot, the order in which filter options are deselected matters

The Office Depot user interface is particularly sensitive to the order in which a user deselects the check boxes for a single filter. For example, the price filter option $50-$100 simply disappears if a user deselects it before deselecting the $50-$60 filter option. A customer would have to click the browser’s Back button twice to undo both selections, because there is no other way to return to the default state. Typically, all of the available filters and options, plus the data that appears on a page can change after each click. The key is to avoid completely removing options in the same filter where a click took place.

3. Always make all filters easily available.

Please don’t misunderstand me. I am not saying all filters should be visible at the same time. It is perfectly acceptable to collapse filters to just a label, providing a single link like View All Filters, or to display previously selected filtering options in a unique way. However, if at different steps in the search workflow, filters start randomly disappearing from the search user interface with no way to bring them back, bad things start to happen very quickly.

Figure 6 shows what happens to the Office Depot search results when a user selects the option Red in the Color filter. As you can see, once a user selects a color, all of the other filters disappear entirely.

Figure 6—On Office Depot, filters disappear randomly

Does this system behavior make any sense? Let’s say I want to buy a red chair mat. Under Color, I can select the Red check box and view a great variety of red chair mats. Is there really a compelling reason for me to do anything else with the color filter? Will I, as a true connoisseur of all things red, perhaps drill down into shades of red for my chair mat, such as Burgundy, Farmhouse Red, or Ripe Tomato? Not very likely—at least not for chair mats. Instead, I am much more likely to say, okay, these are all of the red chair mats. Great! Now, can I select a mat from a known brand? Or perhaps I would like a budget-priced mat, so I need to further constrain my search by price. Or maybe I am a stupendous fan of the Ohio Buckeyes and want to find a chair mat with my team logo, leaving fans of the Michigan Wolverines green with envy. Using other filters to continue massaging my red chair mats query is a far more likely scenario.

Alternatively, let’s consider a different use case: I just selected Red, and now I can see a bunch of red chair mats. Almost immediately, I realize these red chair mats are almost, but not quite, entirely unlike the mat I actually want to buy. So, I immediately attempt to seek out two things:

1. a way to undo my most recent selection
2. a way to review what other filtering options I might want to use

Unfortunately for both these use cases, when I selected a color, the Office Depot search user interface unhelpfully removed all other filters. This action would be tantamount to Kayak’s removing all other filters like departure and arrival times, number of stops, price, and class whenever a customer selected a particular airline. How helpful do you think that would be to someone trying to find a flight? Removing any filters completely can be detrimental to customer success and is, therefore, not recommended. If you really feel compelled, for some reason, to minimize the screen real estate you devote to filters, you can collapse individual filters or hide their options temporarily under a More Options link.

4. Display only filter values that apply to the available inventory.

I touched on the idea of showing only options and links that actually point someplace useful in my first UXmatters column, “Starting from Zero: Winning Strategies for No Search Results Pages.” At every step in the search workflow, any visible filtering options should reflect only the inventory that is available. This is dependent on a customer’s previous actions—both the keywords in the original query and the other filtering selections. As shown in Figure 7, the chair mat color selections expand to reveal tasty color choices like Maple Pale and Cherry Spice. Selecting Maple Pale and Red together should give us both red and Maple Pale chair mats. Unfortunately, the user interface does not seem capable of supplying Maple Pale chair mats, because, when the page reloads, it displays the same five red chair mats.

Figure 7—Office Depot shows color selections that are not applicable to a query

This idea seems really obvious, but quite a few otherwise first-rate sites seem to miss it. Often, the underlying issue is technical. On many sites with Ajax search user interfaces, pages retrieve and recompute all the summary data for all filter values in response to each change a customer makes, so speed becomes a primary concern. For many legacy systems, the demands of just-in-time data delivery are simply too much. At the end of their development cycle, developers are often frustrated to find that, despite their best efforts, their aging systems simply cannot deliver the speed necessary to retrieve all the filtering options, plus the items themselves, plus the data for pagination, in a single Ajax call. In such an event, rather than redesigning the system from scratch to address the root cause of this problem, developers often end up taking shortcuts—either

• caching all of the filters or
• providing a generic list of values that may or may not be applicable to the specific query at hand—like the color values on Office Depot

5. Provide filter options that encompass the complete inventory.

An equally important point is that we must always strive to design every filter to include a list of options that encompasses the entire available inventory. Let me give you an example. As you can see in Figure 7, the color filter in the Office Depot search user interface does not display the most common chair mat color, which is clear. Therefore, once a user clicks any of the color options, the site can display only a fraction of the available inventory—in this case, only 16 of 23 available items. The seven chair mats that are clear have no color attribute, so customers can never choose to view only those items using the Office Depot user interface. Instead, by specifying a color value, they unknowingly remove clear mats from consideration. This system behavior is clearly not beneficial to someone looking for a chair mat—especially if they are looking for the most common variety.

I am not sure what Office Depot’s reason for omitting clear from their color options might be, but it is reasonable to assume that the clear chair mats have the color attribute of empty, or null. Therefore, it is not possible to group these items under a valid color filter attribute. Fortunately, one fairly straightforward way to resolve any missing or inconsistent data is to include Other or All Others as a filter option. The SQL condition corresponding to Other should specifically include any items for which the color field is empty, or null, enabling customers always to view the entire inventory by using some combination of the available filter selections.

Often, there are more options for a given filter than you can show at once. Typically, best practice tells us to show 4 to 7 options for each of the filters. If there are too many options to display, it is often desirable to hide the rest of the options in a More Choices panel or popup. In this case, Other might be an option that shows up only once a customer is viewing the additional options. Specific queries dictate where to show each particular option. In our example, given the popularity of clear chair mats, I think Other should be at or very near the top. However, regardless of their order, it is critical to include all of the options that encompass the complete inventory. This is especially important in cases where there is no All or Any undo option—as in the Office Depot search user interface. Otherwise, we risk making some of the most popular items on a site unfindable.

In Conclusion

Faceted search user interfaces are fairly new, and potential design pitfalls abound. Fortunately, there are a few relatively simple and straightforward design best practices that should help designers to minimize cognitive friction and create search user interfaces that are easy to understand and use.

In this column, I’ve presented five best practices for designing filters for faceted search results. Of these, I think the first—choosing either drill-down or parallel selection—is the most important. If you choose your filter value-selection paradigm correctly, you are already half way there.

Whichever filtering paradigm you decide to implement, be sure to test your search results user interfaces thoroughly with both your potential and existing customers. I cannot overemphasize the importance of testing search user interfaces using realistic tasks. If your budget allows, it is best to avoid predefined search tasks. Instead, study how real people find items they are actually interested in—preferably in an environment where they would normally do the kind of searches you want to study. When designing search user interfaces, field studies are a crucial tool for continually making and validating design improvements—not just something you do as a formality at the end of a project.