Improve the usability of search-results pages

Add sophisticated but easy-to-use filtering and sorting controls

E.R. Tufte, in his phenomenal book Envisioning Information, states, "Clarity and simplicity are completely opposite of simple-mindedness." This false simple-mindedness is often evident in the design of a search-results page. Even on some of the leading e-commerce sites, this important page is frequently made hard to use by excessive visual clutter or the complete absence of appropriate sorting and filtering controls. This is especially daunting as more and more raw data return as search results, without the appropriate tools to manipulate them.

A well-designed search-results page is well worth the effort, since it is the key to helping your users successfully achieve their goals and enticing them back to your site. The engineering challenge is to provide just the right kind of sophisticated yet easy-to-use sorting and filtering tools that map well to your customers' goals and mental models. In this article, I present some design ideas to start you on your way to creating a more usable search-results page.

Blood, sweat socks, and chicken soup

According to usability research, while most consumers search occasionally, more then half of all users are "search dominant," meaning they go straight for the search and ignore the rest of the navigation on the site (see Designing Web Usability: The Practice of Simplicity). Thus, the search-results page is used by a vast majority of the customers, and the usability of this page is often key to the usability of your entire site. Given this data, it is astonishing how many companies ignore the usability design of this important functionality and are content to let their users muddle through.

Nowhere is this more evident than in e-commerce, as the following tale of Internet shopping illustrates: My wife has a well-concealed passion for cooking, but loves cookbooks about chocolate. For her birthday, I wanted to present her with a well-illustrated tour guide to chocolate cooking nirvana, and I figured this guide should range somewhere between 5 and 0. I knew exactly what I wanted, so I bravely set my browser to Amazon.com and typed "Chocolate Cookbook" in the site's search function. Would you believe that (at the time of this writing) I found 14,597 books?

The first item was listed for .99, which fell outside my desired price range. The next two items had no visible price at all. Navigating to the next search-results page seemed fruitless: at 10 items per page, it would take 1,459 pages to see all 14,597 items. At a brisk browsing pace of 1 minute per page, this browsing process would take just more than 24 hours!

Sorting by "Avg. Customer Review" netted a very highly rated A Tale of Blood and Sweatsocks and a disappointedly chocolate-free Chicken Soup for the Teenage Soul (shown in Figure 1):

Figure 1. Sorting chocolate-cookbook search results by Avg. Customer Review. Click on thumbnail to view full-sized image.

It is possible that the search engine mistook the unfortunately named Chicken Soup series for a real cookbook, but a tale about sweat socks seemed completely out of place. At that point, I was completely stuck: Not only was there an excessive number of items in the search results, but most of the items seemed to be either in the wrong category or in the wrong price range. Most importantly, and absolutely critical to enable me, the user, to reach my chocolate shopping goals, there did not seem to be a way to filter the search results in such a way as to narrow them down from 14,597.

Too much data

My unfortunate shopping experience is indicative of the larger problem affecting many large consumer sites: excessive amounts of raw search-results data with no way to manipulate the results. Between the Herculean efforts to give customers "something" from their searches and brilliant marketing initiatives to maximize the number of "impulse buys," many Web companies have lost track of their core competency: helping customers quickly find exactly what they are looking for.

Companies ignore usability of key functions at their peril. In his excellent book Don't Make Me Think!, Steve Krug quotes his wife's excellent statement on the key importance of usability: "If something is hard to use, I just don't use it as much." Anyone who has had a negative and frustrating experience with a Website will hesitate to use it again. Search programs can and should be made smarter (think Google), but the usability of the search-results page can also be improved dramatically.

The lack of appropriate controls to filter search results by category and price range made it impossible for me to purchase my cookbook at Amazon.com. To paraphrase the opening quote, engineers at Amazon.com substituted "simple-mindedness" for "clarity and simplicity." What Tufte brilliantly wrote of information design is equally true of interaction design: "...the operating moral premise of information design should be that our readers are alert and caring; they may be busy, eager to get on with it, but they are not stupid."

To keep users coming back to your site, all of the pages essential to the successful shopping experience must be well designed to support your user's goals. One of the most frequently used pages is the search-results page, and it is well-worth the additional design effort. The challenge is to provide just the right kind of sophisticated sorting and filtering tools that are easy to use and map well to your users' goals and mental models. As discussed in the next section, providing "just the right tools" is no easy task.

The right toolkit: Everything users need and nothing more

As a great designer Milton Glaser once famously said: "Less is not necessarily more...just enough is more." Following this advice is by no means easy. To provide "just enough" functionality, a designer must focus directly on the goals of one particular user, and understand that user's specific needs and behaviors extremely well (see About Face 2.0).

In my specific case, I knew exactly what I wanted, and my goals were clear:

  • Media type: Book
  • Category: Cookbook
  • Subject: Chocolate/deserts
  • Price range: 5 to 0
  • Rating: Highest customer rating and/or bestseller

To help me achieve my goals, Amazon provided a good sorting functionality for sorting the result set by user ratings or bestseller. The important feature missing from the Amazon search results was filtering, which compromised the result set's usability. To improve the site usability, in light of my specific goals, Amazon could have introduced two simple filters: category and price range.

Either one of these filters would have dramatically decreased the number of search results. Together, these filters could have helped me zero-in on the manageable 20 to 50 chocolate cookbooks to examine in a reasonable amount of time. Having these filters would have allowed me to take control of the searching process and complete the buying task successfully.

It is worth noting that filtering itself is a foreign concept to most users. For this reason, Krug suggests that good search filter design should use a customer's own terms and natural language, so the filter reads like a sentence. For example:

"Search ____ for ___________ in ___________ Price from $___ to $___"

Implementation is shown in Figure 2.

Figure 2. Implementing a natural language filtering scheme using HTML controls. Click on thumbnail to view full-sized image.

Good search filters are challenging controls to design. The filters in Figure 2 would definitely increase the task completion success rate in my particular use case, because they help me zero-in on the right product category in my price range. However, would these filters help all users in all cases? Would additional controls confuse newbie Web users and add clutter to the screen unnecessarily? Simple guesswork won't give you the right answers to these questions. To design search filters correctly, you need to know your target users intimately.

The concept of a "persona" introduced by Alan Cooper in About Face 2.0 is a powerful and sophisticated tool for user behavior modeling. Personas are not real people, but they are based on the behaviors and motivations of real people gathered through usability research. Cooper defines a persona as "a precise descriptive model of the user, what he wishes to accomplish and why." This model of a fictional archetypical user comes in handy for understanding user goals and exploring the ranges of behavior in specific contexts—such as your system's interface.

Using personas allows the designer to prioritize which users are the most important ones to design for—those models become one or two "primary personas" for your project. Other important classes of users become "secondary personas." Thus, the key to a successful "just-enough" design is to address the needs of the primary personas, without unduly inconveniencing the secondary personas. (For more discussion about personas as an effective design tool, see Resources for links to Cooper's excellent books About Face 2.0 and The Inmates Are Running the Asylum.)

Regardless of whether you choose to use persona-modeling in your design, it is invaluable to conduct frequent usability tests with real users throughout the design process. The usability tests should be conducted frequently, and as early in the design process as possible, using static HTML or even low-tech paper prototypes. It may initially seem like a hassle, but if you consider the high cost of modification and quality assurance of the finished software product versus the low cost of modifying a paper prototype, obviously performing detailed product design before coding begins is well worth the effort. Persona-based design coupled with frequent usability testing is the most cost-effective way of ensuring that your final product will be successful in helping your users reach their goals.

Although filters are hard to design, the good news is they are often relatively easy to implement, which you will see as we add the category and price filter to my chocolate-cookbook search-results page.

Designing a category filter with drop-down control

One popular implementation of the category filter is a drop-down control. This implementation is especially handy if many categories need to be displayed and screen real estate is tight. Note that providing this filter up-front often makes little sense. Currently, Amazon has 35 categories, and few people will ever make the effort to read all 35 categories to find out which one fits the subject best. Most likely, if users wanted to put in the time to learn the categories, they would browse instead of search.

The key to a successful category filter is instead to narrow the categories only to those constrained by the search results, so the user can more easily choose the most likely category from the smaller, more relevant list. Usually, the category with the most items contains the most relevant search results, so it makes sense to show it first, with other relevant categories appearing in the order of descending item count. To make this ordering scheme clear to the user, it helps to show the item count after the category name. In our case, "Cooking" would clearly be the first category with the most items, making for easy user selection. For someone looking for cookbooks, it would be obvious to select "Cooking" and avoid the "Persperational Fiction" category, as shown in Figure 2.

Search filters can be implemented using SQL in the following way. Assuming the original search query used to retrieve "chocolate" items was:

 SELECT *
FROM item
WHERE title = 'chocolate'  -- simplified for clarity
ORDER BY average_customer_review DESC

The list of categories for these search results can be obtained by using the original SQL search condition of title = 'chocolate', modified with a GROUP BY clause:

 SELECT category_name, category_id, COUNT(*) AS items_count
FROM item
WHERE title = 'chocolate'
GROUP BY category_name, category_id
ORDER BY COUNT(*) DESC

To construct the filter, we first need to create a small helper class, HtmlOption. Each object of this class represents one option in the drop-down (HTML select) control:

 

//Value objects must be serializable for use in distributed Java systems like J2EE public final class HtmlOption implements java.io.Serializable {

//Both value and text are strings private final String val; private final String text;

//Constructor public HtmlOption(String text, String val) { this.text = text; this.val = val; }

//Accessors only, with no corresponding mutators public String getValue() { return val; }

public String getText() { return text; }

}

Each object of this class will be immutable, which is a good object-oriented design practice and has many advantages. As Joshua Bloch writes in his famous book Effective Java, immutable objects are simple, have only one state, can be shared freely, and are inherently thread-safe.

Now we have everything we need to write the code that will generate our category filter:

 

ResultSet rs; //Standard JDBC, the rest omitted for clarity

ArrayList categoriesFilter = new ArrayList();

//Add the first option: "All Categories" String text = "All Categories"; String val = "0"; categoriesFilter.add(new HtmlOption(text,val)); //Add the default no-filter option

while(rs.next()) { text = rs.getString("category_name") + " (" + rs.getString("items_count") + ")"; val = rs.getString("category_id"); categoriesFilter.add(new HtmlOption(text,val)); }

1 2 3 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more