In my last installment of Search Matters, “Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World,” I presented several design strategies for query disambiguation.

Unfortunately, most sites do not make sufficient use of this pattern and some that do use it design and implement it incorrectly.

Show Me More

The idea behind the More Like This pattern is very simple: within each group of items representing a particular category from a catalog or accompanying each item in search results, provide a prominent link or button with a label that is some variation of More Like This ». Of course, the devil, as they say, is in the details. Figure 1 shows one of the more successful implementations of this pattern, the Amazon.com home page.

Figure 1—Amazon’s successful implementation of More Like This

On close examination, this design yields a few important lessons:

• Make group organization simple and obvious. Each group title should be prominent and simple, not inviting deep thought or much examination. The words and the color treatment of group titles should flow in a way that lets customers easily skim groups. Their titles exist to clearly separate various groups and direct the eye to the items they contain.
• Focus on helping customers make decisions. Although the items in each group are themselves fairly relevant, the subtle focus of the whole page is not on finding exactly the right item on the current page, but instead on displaying some relevant entry points to an unfathomable cornucopia of relevant choices on Amazon.com that each group exemplifies.
• Format groups differently from search results. The items in each group have a horizontal layout, in a gallery format, so it’s easy to differentiate them from the search results, which typically appear in a vertical list.

The most important thing to keep in mind is that all of these design features support a single key goal: to help customers find what they want by providing the information scent and motivation that makes their navigational decisions easy and intuitive. Let’s examine what happens when sites ignore these lessons by looking at some other implementations of the More Like This design pattern.

Make Group Organization Simple and Obvious

Any cognitive friction around the organization and format of different groups makes navigational decisions more difficult. Instead of making decisions primarily on the basis of the information scent embedded in each group’s content, customers must try to understand why certain groups have a different format—a confusing and usually futile endeavor. Figure 2 shows one example of such an over-designed More Like This page, displaying search results for the query Thai Restaurant San Francisco on Yelp.com.

Figure 2—Yelp’s over-designed More Like This page

The aim of this page is not to present all possible choices, but to help customers make a quick choice of the method that would best let them explore a bevy of Thai-food restaurant recommendations. Unfortunately, the purpose of the page is far from obvious. Observe that the page has no fewer than seven different groups, each with its own branding and formatting, in an overly complex, nonstandard layout. Together, all of these differences create a cacophony of results, making it very hard to compare the different groups without studying them in detail. Too much fancy formatting and too varied a layout hinders customers’ ability to make navigational decisions quickly, which should be the page’s primary aim.

Contrast this page with the Amazon home page in Figure 1, in which each group has the same simple format, drawing the eye to the content. On Amazon, with the aim of making customers’ navigational decisions quick and easy, groups’ simple, intuitive organization lets customers easily scan them and decide whether to explore a particular group further.

Last, but not least, the first section, Best of Yelp, does not even look like the other groups. It is the only one that contains breadcrumbs. As a rule of thumb, on More Like This pages, breadcrumbs should appear above all of the More Like This groups, not within any of them.

Focus on Helping Customers Make Decisions

To help customers make navigational decisions within More Like This groups, is more content better? The answer is: it depends. Amazon’s More Like This pattern includes one subtle, but very powerful feature: if a customer increases the page width, the number of items in each horizontal group in this liquid layout increases, so higher resolution screens and wider windows show more items in each group. I’ve already discussed the benefits of liquid screen layouts in my column “Choosing the Right Search Results Page Layout: Make the Most of Your Width,” so I will not cover that topic in detail here. Be aware that this kind of horizontal expansion is no simple trick, so don’t expect it to work out of the box, as it were. Though, if you can afford the labor that developing the right CSS stylesheet involves, this is one feature well worth implementing.

On Amazon, more content is better. Partly, this is because every additional item a wider screen shows might be the one that catches the interest of a prospective buyer. But most important, showing a greater number of items presumably creates better information scent for each group, helping to motivate customers to explore a group in more detail.

What if there were a way to show even more content in each horizontal group on a page? One way to do that would be with a carousel widget that scrolls from side to side like that shown in Figure 3, on a category page on Netflix.com.

Figure 3—Netflix’s More Like This carousel pattern

In many ways, the Netflix implementation of a More Like This carousel is very similar to the Amazon implementation of More Like This. The page organization is simple and obvious, and the groups look different from the search results. There is, however, one important difference: clicking an arrow at either side of each group scrolls the contents of the group to the right or left, displaying an additional four items. Does the addition of this carousel widget help or hinder the primary goal of the page?

Well, the jury is still out on that. However, I can tell you that the carousel takes a customer’s focus away from making a decision about which group to explore and instead invites the customer to linger on the page a bit longer, while exploring each of the groups. This is not necessarily a bad thing. But keep in mind that, even though a carousel can show customers twice as many items in a group, it still shows them only 8 to 10 items in total. This is in contrast to the hundreds, if not thousands of items a customer could see in a complete list of search results by clicking the See all > link for a group. Providing larger secondary targets—the left- and right-pointing arrows—also makes people think they should click them. If customers do click the arrows, there is a pretty good chance they might become mesmerized by the fancy scrolling interaction and miss the fact that this page is supposed to help them choose a subcategory to explore. A customer might look at the eight items the widget presents, find none of them relevant, and leave the site, thinking those eight items are all there were to see in a particular subcategory.

A carousel might seem like a fun, beneficial feature, but remember that the main purpose of the More Like This design pattern is to direct customers to explore the entire cornucopia of items under each category—that is, to select a category to explore—not to find exactly the item they want among the 8 to 10 items each carousel displays. To drive people to explore, the overall design of each group must be fairly Spartan, so customers can make their decisions quickly and move on to exploring the main body of the search results. If fancy group formatting or Ajax carousels make customers disregard the more important More Like This buttons, such a page fails to meet its primary objective.

If you are still thinking about using carousels for your More Like This groups, consider that Netflix has one of the best recommendation engines in the world and can usually select very relevant items to include among the 8 to 10 options their carousels display. Amazon, which also has an exceptional recommendation engine, tried incorporating carousels for all of their groups, but now uses the carousel feature more sparingly, presumably because the results underperformed the Spartan group design, which is optimized for quick scanning.

Although a typical More Like This page does not warrant the use of carousels, in some circumstances they can be appropriate. One place where a carousel widget might come in handy is in the Two-Dimensional More Like This design pattern I’ll discuss later. But first, let’s take a quick look at what happens when groups look just like the actual search results.

Format Groups Differently from Search Results

So far, we’ve covered More Like This pages that, for the most part, look pretty different from search results pages. What happens if you apply the More Like This pattern to subgroups containing vertical lists of results?

The query disambiguation page on TripAdvisor.com, shown in Figure 4, does a particularly poor job of helping customers choose either a means of exploring or a category of items to explore.

Figure 4—Search results for the query San Francisco on TripAdvisor

This is clearly a page that does not inspire or invite further exploration. There is much that really does not work on this page, including the bevy of no less than ten generic, monochrome icons; intermixed, ungrouped results that seemingly show up in random order; the small number and poor quality of results; and the absence of any pictures. My list could go on and on. However, as bad as all of these problems are, customers might actually overlook them, if the page did not also commit the cardinal sin of any grouping presentation: making the groups on the page look like actual search results.

In all of my user research, I have found that nothing is more confusing to participants or generates more sheer exasperation in customers than dealing with a page that looks and feels like a search results page, but is actually some kind of fancy, special-purpose page containing groups, whose aim is to take customers to actual search results. TripAdvisor’s query disambiguation page for San Francisco, shown in Figure 4, is exactly such a page. Take care to avoid this approach in your designs.

Two-Dimensional More Like This Pattern

How could we improve TripAdvisor’s query disambiguation page for San Francisco? In my user research, I’ve discovered that precisely because it is possible to show only a very small number of items for each topic—typically 4–5—customers’ do not expect to discover specific items of interest on this kind of page, but instead to see a representative set of items in each specific subcategory.

What if, instead of showing a fairly random sample of 4–5 specific hotels, attractions, or restaurants, we showed 4–5 generic items that represent a more granular subdivision, or aspect, of each category? In other words, instead of getting item details for 4–5 specific hotels, customers could drill down to one of the most popular hotel types—for example, Family, Business, Bed and Breakfast, or Boutique. Clicking one of the 4–5 generic hotels in the Hotels group would take customers to a search results page with results filtered by both the category Hotels and a type of popular hotel, making it possible for them to rapidly perform a visual, two-dimensional drill down into their area of interest. This is the idea behind my Two-Dimensional More Like This pattern. Figure 5 provides an example, showing my suggested redesign for the TripAdvisor query disambiguation page.

Figure 5—Suggested redesign for the query disambiguation page

This Two-Dimensional More Like This pattern is particularly appropriate for cases where the content includes thumbnail images and both the category and aspect are clearly defined—as they are in the case of hotel types, for example. In many cases, brand is another popular search facet that provides an easily recognizable secondary aspect you can apply across a group.

Interestingly, I have found that there is little need for secondary aspects to be consistent across categories. Let me give you an example. In my last column, “Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World,” I showed how HomeDepot search results for the query drill fell into three categories: Drills, Drill Bits, and Hammer Drills. If we were to apply the Two-Dimensional More Like This pattern to that example, it would be highly appropriate to use Brand—for example, Black & Decker, Dewalt, and Makita—as a secondary segmentation for the Drills category. On the other hand, it would be best to segment the Drill Bits category by the type of drill bit—for example, Sets, Drill Bits, Philips Screwdrivers, and Flat Screwdrivers.

In my user research, I have found there is little problem with applying different secondary aspects to different More Like This groups on a page, so long as they make some intuitive sense. I have theorized that this is because the customers using a search results page usually quickly narrow the results down to a specific category, by following its information scent. So, they need to figure out the organizational pattern behind a single subcategory in which they are interested rather than to compare different subcategories to one another.

As I mentioned earlier, the Two-Dimensional More Like This pattern is an excellent use case for using a carousel widget. As Figure 5 shows, if there are more aspects—like brands or hotel types—than can fit in the 4–5 thumbnails that can appear on a page at once, you can safely hide the less popular aspects on the carousel. In this case, the expectation would be for customers to first narrow down their search to a specific category, then invest more attention to selecting the appropriate secondary aspect. If customers cannot find the secondary aspect they want by scrolling from side to side with the carousel, they can still click the group’s See All » link to view all of the search results for an entire category.

The Two-Dimensional More Like This pattern works particularly well for resolving ambiguous queries and creating category pages on which customers can clearly express search refinements by clicking a single label or image. However, it would be less appropriate for information categories that are somewhat arbitrary and less clearly defined. In the Netflix example shown in Figure 3, is there really that much difference between the categories Anime Action and Anime Sci-Fi? Applying the Two-Dimensional More Like This pattern to the recommendations on the Amazon home page would also be problematic. What single image could you choose to represent the categories New for You or Recommended for You and their subcategory aspects?

One difficulty in designing a Two-Dimensional More Like This page is selecting which specific items to show as representatives of each aspect. I recommend that you select the first thumbnail in the set of search results that would appear if a customer clicked a subcategory plus an aspect. Selecting the first thumbnail in a list of search results as the representative aspect performs particularly well for sorting a search result set by Best Selling or Best Match, because the first item usually provides an excellent representation of the constrained results set. Sometimes customers click a specific item not to select a subcategory and aspect, but simply because they liked the item in its thumbnail for some reason. Placing the item that represents both a subcategory and an aspect first in a set of search results satisfies both the display criteria and the I-want-this-specific-item mental model perfectly.

What if a specific criterion like price is important in a customer’s decision making when selecting an item on a Two-Dimensional More Like This page? In this case, as Figure 5 shows, it is perfectly appropriate to use a sorted list format—for example, Priced from $XX.XX, which shows the lowest-priced item in a given set of search results first—even if the set of search results customers see once they click a link is sorted by Bestselling or Most Popular.

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.