Search Is Key to Findability

In this column, we’ll be talking about search. Searches turn up in many places. In Web sites, they are often the user’s first choice for navigation. In social network sites, they enable users to locate relevant groups. In business applications, they are tools for locating individual records and for building reports. With search, one size does not fit all. The care and creativity with which you design the search tools in your applications can really have an impact on the user experience.  

Best Practices and Patterns

Ambrose Little

Historically speaking, search is not one of the things developers tend to think much about, unless they work for Google.  In many IT apps, it’s something we sort of slap on at the end.  On Web sites, it is often the same—we assume that we can leverage a search appliance or some other easy keyword searching facility, and in some cases we  leave it up entirely to Bing, Google, Yahoo or another search engine . When we implement search ourselves, there’s usually a binary toggle in our minds between “simple” and “advanced,” with “advanced” meaning that we throw up a form with most or all of the key properties on our objects, add some drop-downs and let people go to town.

We can and should do better with search. No matter how well we craft our information architecture, the chance that we nail it to the point that search is not needed is low, and it grows closer to zero the more we add content, objects and data to our solutions.

Search needs to be factored in as a top-level concern when you are thinking about your solution. It should be there as part of the cross-cutting concerns, along with security, performance, and other requirements.  In fact, you can more generically call search “findability,” because the reality is that you need to think not just in terms of search but also in terms of other ways of finding information.

Donna Spencer has identified four common modes that users employ when they seek information (see boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them):

1. Finding something when they know what they want and have words to describe it.
2. Exploring when they have only some idea of what they want and may lack the words to articulate it.
3. Finding relevant items when they don’t know what they need.
4. Finding something they have seen before.

 These modes might be a good place to start when you consider findability in general.  (By the way, “findability” was coined by Peter Morville in his book Ambient Findability [O’Reilly, 2005]. I think it’s a great term to sum up the cross-cutting concern and quality we’re after here. Of course, the understanding and disciplines involved in this go way back—to before the term was coined—in information and library science.) 

Other researchers have studied and written about “information foraging” (Peter Pirolli and Stuart Card, “Information Foraging in Information Access Environments,”  1995) and “berrypicking” (Marcia J. Bates, “The Design of Browsing and Berrypicking Techniques for the Online Search Interface,” 1989). Lately, some theorists are building on these and other ideas to suggest a more focused subdiscipline of “exploratory search” (Ryen White and Resa Roth, “Exploratory Search: Beyond the Query-Response Paradigm,” 2009).

What seems to be a common thread among these thinkers is that finding information (or objects that you want to work with) is neither straightforward browsing nor a straightforward ask-and-find means of operating.  It is typically a combination of modes, and not only that—people tend to use “evolving search,” which is identifying new, useful information found while searching that they can use to further tweak and enhance their knowledge of the topic as well as their searching.

What this suggests practically is a need for us as creators to enable this kind of finding—to think about searching as a key part of enabling people to find what they need to find and integrating that with other means of discovery.

How Can We Do This?

As already noted, ensuring that findability is one of the cross-cutting concerns you address in your solutions is key. There’s a lot to be said for simply putting it on your checklist and making sure that you think about it.  Maybe the solution’s need for findability is less than in others; maybe it’s the most important quality.  You won’t know if you don’t bother to think it through.

From an implementation perspective, you need to think through your formal information structure as we discussed in “Strategies for Designing Application Navigation” (msdn.microsoft.com/en-us/magazine/dd458810.aspx) and then individual views and screens (see “The Tao of Screen Design” at msdn.microsoft.com/en-us/magazine/ee413547.aspx).  For search, the first step is to try to get an understanding of what search means in the context of both your solution and your users.  The context of your solution (for example, a rich client application for processing loan applications) can help you think about what kind of search is more helpful than others.  Contrast the loan application with a public marketing Web site—the search needs for the Web site are probably quite different. 

In the first case, the solution context is to make loan processors effective in processing loan applications.  The information is private and tightly controlled within the organization. In the second, the solution context is distributing information and educating people about a product or service with a view to driving sales. Here, the information is public and is intended to be disseminated as widely as possible.

Internal, Object/Transaction-Driven Solutions

People who use the loan app typically need to find a particular loan application, a group of applications they worked on, related applications by type and so forth.  In a situation like this, you should observe how these people find this information today and talk to them about their pain points.  You can ask for suggestions, but keep in mind that you should not rely on them for ideas on how to improve these processes—you are in a unique place to create new and better ways for them to find information, ways they might not have dreamed of.  Another nice aspect of this kind of situation is that the goals of users and the business often align—the business wants users to work more effectively, and often so do the people.

For a solution like this, you might consider using the Table Filter pattern (see Figure 1) as part of the Work With pattern.  You could also add Alphanumeric Filter Links if a meaningful primary attribute is available that you can use for alphabetical sorting.  Active Filtering might also be a good option.  These and other search-related patterns can be found in Quince at quince.infragistics.com.

Figure 1 Excel's Table Filter Example

Public/Information-Driven Solution

For a public marketing Web site, users’ goals frequently diverge. Their goals can also be broader, and their contexts can vary much more.  Rarely is a user’s primary goal to come to the site and immediately be converted into a sale, but if that’s the case, the user has probably visited before, probably knows exactly what she wants, and probably knows how to find it with relative ease.  Users like these have already bought in and want to purchase from you. You shouldn’t neglect these people, but too often they seem to be the assumed persona for marketing Web sites as the result of too much navel gazing on the part of the decision makers.

More often, people come to such a site with a vague notion of who you are and what you can do. They might not even be shopping per se but just trying to find information about something related to what you do. Maybe they heard about you and want to know more, or maybe they use your products and want help or want to upgrade.  Often they stumble onto you through some sort of search, even if that search is just on your company name.  I’ve even seen people type URLs into search engines.  The point is that for a public site, considering how public search engines expose you to people is key—probably more so than your own local search.  This is, of course, why so much effort and money is spent on Search Engine Optimization (SEO) and why you need to think a lot about it for such a site.

But people also expect to be able to search locally once they are on a site, expecting (often wrongly) that your local search results will be better than what they might get from Bing or Google.  More advanced users might know the search syntax for scoping a search on those engines to a site, or maybe they have a toolbar to do that.  But you shouldn’t rely on that, and besides, you might miss out on some key ways you can improve on general keyword search because you can scope it to your own domain.

Faceted Navigation

Chief among these ways to improve on public search engines is the pattern called Faceted Navigation. Despite its name, this pattern is really more about filtering search results (and is also known as Faceted Search), and in recent years it has become the top way to handle search and especially search results. The canonical example is Amazon.com. In the side bar shown in Figure 2, Amazon offers you the ability to filter results by various “facets” (also known as attributes, properties, categories, and so on).


Figure 2  Amazon.com's Faceted Navigation

You see in Figure 2 (this illustration was spliced together—normally these columns are stacked vertically on the left side) the facets of Category, Brand, Seller, Price, Megapixels, Optical Zoom, Display Size, Image Stabilization, and Viewfinder Type.  Within these facets are particular, meaningful values or ranges of values that pertain to the facet.  The view lets you clear out a selected facet by using the Any option at the top of each titled section.  It also shows you the number of items you can expect in the results if you filter by a particular facet’s value. The facets are accumulative—in other words, they effect an AND Boolean operator. 

Although not shown in the figure, the breadcrumb on Amazon is augmented when you pick a facet, which helps to reinforce what a user selected, shows the order (history) in which it was selected, and enables people to jump back several steps of filtering with one click.

Many other good examples of this pattern exist (which you can see on Quince and elsewhere). For a nice discussion of comparative best and not-so-good practices, read Greg Nudelman’s recent analysis of Office Depot, which he compares to Amazon (new.uxmatters.com/mt/archives/2009/09/best-practices-for-designing-faceted-search-filters.php).  And for an in-depth comparison of current search results techniques across the major internet outlets, check “Search Results Design: Best Practices and Design Patterns” by Louis Lazaris (smashingmagazine.com/2009/09/28/search-results-design-best-practices-and-design-patterns/) along with the Search Results pattern in Quince. (There’s a Search tag you can use in Quince for related patterns; see quince.infragistics.com/#/Search$tag=Search).

Forget About Advanced Search

You might notice that ye-olde “advanced search” has not been discussed here.  That’s because in most cases you should seriously consider eliminating it entirely in favor of Faceted Navigation.  This isn’t a universal principle (no doubt you’re thinking about the Advanced Search feature on the major search engines), but unless you know that your users are advanced and want this capability, you probably shouldn’t  do it. You can usually accomplish the same purpose and get a better result with Faceted Navigation. Here are the reasons:

1. Faceted Navigation doesn’t require up-front decisions about which facets to use. People can fire a shot and then hone the results.
2. Faceted Navigation can and should make use of knowledge about the result set to provide meaningful options to filter by. (For example, if the $300–500 range contains no items, there’s no sense in showing it or letting people filter by it).
3. Because of the lightweight feel, especially if you use immediate updating as in Active Filtering (see kayak.com), people feel freer to quickly try different combinations of facets to find what they want.

Consider Limiting Result Sets

Limiting result sets is a personal design preference, not a hard and fast rule, but consider keeping your result sets to something like the top 50 or 100 results, especially if you have some kind of sorting and filtering in place. People won’t effectively scan much more than that before they grow weary and want to filter, sort, or try a different search.  By limiting results, you can:

1. Avoid formal paging, removing unnecessary complexity from the interface and saving the cost of developing that part of the UI.
2. Encourage the use of sorting and filtering facilities, which in the end makes people more effective in using your search facilities and happier with what they get out of them.
3. Improve overall performance. One of the common performance killers in apps is not managing search results well by trying to retrieve or load too many results.

You’re probably dubious of this last design recommendation, but give it a try—you’ll be surprised. It costs less than implementing paging, and paging can be added later if you want.  I would add paging and more results only if usability testing or the nature of the problem made it clear that having them is better than not having them.

More Factors to Consider

Dr. Charles B. Kreitzberg

A lot of user frustration often occurs around search. This reflects the complexity of cognitive tasks that underlie searching as well is its importance to getting the job done. As with all design, you get the best results when you understand and align with the tasks users need to accomplish and their mental models and competencies. Users often cite the simplicity of Google’s search box as the model they want to see. It’s understandable why people respond to the ease of a simple search box, but not every search fits this paradigm. Although it’s not always possible to create an effective search tool without a more structured UI, careful design of search screens can really simplify the UI.

Recently, I was involved in the redesign of a Web application in which search is an important component. It is used in a number of ways: for quick searches on the home page; as a series of specialized searches, each with a different business purpose; and as a reporting tool. Over the years that this application had been updated and revised, the number of search screen proliferated, each one somewhat different from the others.

When we analyzed the search screens carefully, we realized that they were all fundamentally similar, and we were able to create a single search screen that incorporated them all. We accomplished this by allowing the user to select the search from a drop-down list and customizing the search parameters based on the selection. The result eliminated the specialized search screens and replaced them with a single, more intuitive search tool. This was a significant simplification of the UI with no loss of functionality.

Where Search Goes Wrong

Search design often goes wrong in a number of places. Here are three things to look out for:

1. Confusing search with SEO. To some business clients, the term “search” means Search Engine Optimization. SEO is extremely important, but it is not usability or user experience.  Making the distinction between the search UI and SEO is important for keeping your discussions with business clients on track.

2. Pogosticking. Think about someone jumping up and down on a pogo stick. You get a similar pattern when a user needs to keep clicking on search results to determine which one is the desired element.  Let’s say that you’re looking for a customer named Bob Smith and you get search results with several Bobs and a couple of Roberts. You need to click down the list of results until you find the customer you want, and this can become a real usability problem. You might want to read Jared Spool’s discussion of pogosticking in the context of galleries (uie.com/articles/galleries/)

   Here are two things you can do to minimize the pogo-stick problem:

   Place enough information in the search results that the user can determine the relevance of the item without needing to visit the detail page. Be very careful about the titles you use because these are important cues for the user. For example, instead of a results item such as this one:

   

   see if you can provide a more meaningful result, such as this:

   

   Make the details available with “vertical navigation” so that the user can see the details, dismiss them and be back on the search results. The goal is to avoid having the user leave the search results pages and then need to navigate back to them. (See our discussion of navigation in the March 2009 issue of MSDN Magazine at msdn.microsoft.com/en-us/magazine/dd458810.aspx).

3. Paging. When you have a lot of search results, paging can be important both for comprehensibility and for performance. But paging can be a nightmare for the user when there are a lot of pages and no way to determine which one has the item the user wants. Try this on Amazon.com: look for a book on medical practice by an author named “Smith.” When I tried it, I got over 11,000 hits with only the first three pages showing. Jakob Nielsen notes that “users almost never look beyond the second page of search results” (useit.com/alertbox/20010513.html).

   Paging can be a tough technical problem to address because you often don’t know where the desired item is or even how many pages are actually required. But if you can provide clues to the user about where to look, you can reduce effort and frustration.

Thinking About Search UI Design

There is no magic for creating a perfect search design, but here are some questions that you can adapt to your own situation. Remember that a single application might have several types of search, and it is often a good idea to work toward a simple, comprehensive UI that can support the various types. This can be a challenging task.

1. Start with a high-level understanding of the type of information seeking you anticipate. As Ambrose suggested, a taxonomy like Donna Spencer’s four modes of information seeking can be helpful. Another taxonomy is one that Whitney Quesenbery, Janis Morariu and I developed to categorize information-seeking approaches (wqusability.com/articles/search-usability.html). It defines five types of information seeking:
   • Browse—I want to explore to see what’s available.
   • Find—I want to locate something specific.
   • Query—I want to see items that meet my criteria.
   • Structured—I want to be led through a series of choices to help me narrow my focus.
   • Guided—I want to be led through the information.
2. Consider the domain of the search. Are you dealing with a highly complex domain or a simple one? What sort of queries do you need to process? Do you need to deal with synonyms and nicknames? Are dates or date ranges important? Are records distinct or does the user need to disambiguate among similar records?
3. Consider the capabilities of your users. The hope is that you’ve been studying your users and creating personas, so this should be an easy question to answer. You want to know:
   • How familiar are they with the domain in which they are searching. Do they know the terminology?
   • How sophisticated are the users in terms of their ability to formulate search queries?
   • Are the users able to create a subsequent query to refine a results set? (Many cannot).

Clearly define the context of the search tasks. Generally, search tasks are the first step in a larger sequence of tasks. Be clear on why users are searching and what users will do with the results once the item (or item set) is located. If the user has to repetitively process records (search, locate record, process record and then return to the results list to select another record), make certain that the flow is simple and clear.

Decide how you will present the results list. You should design the results list to facilitate easy visual scanning and identification of the items. Place enough items on each page (if you are using paging) to avoid the clutter of too many small pages. (I often find that 50 is a good number to start with.)

What Else Is There To Say?

Search is a complex task and one for which thoughtful design can make a real difference in usability and user experience. Taking the time and effort to really think through the design can pay off.  Here are some practical considerations you can keep in mind:

• Search, and more broadly findability, is key to most solutions these days and should be considered up front along with other cross-cutting concerns.
• When you approach search, consider the context of your solution and the context of your users. Your understanding of these informs how you support search in your solutions.
• Think about how search can complement other forms of information seeking.
• If your solution’s information is public, think carefully about how best to expose it through the major search engines.
• Add value to your local search over the public engines through the use of facets in your domain.
• Leverage known patterns and practices to help give shape to your search solution. 

Look at the examples of the big guys, but always adapt or exclude what they offer to make sense in the context of your app and your users.

Dr. Charles Kreitzberg is CEO of Cognetics Corp. (cognetics.com), which offers usability consulting and user experience design services. His passion is creating intuitive interfaces that engage and delight users while supporting the product’s business goals. Charles lives in Central New Jersey, where he moonlights as a performing musician.

Ambrose Little lives with his wife and four children in central New Jersey. He's been designing and developing software for more than 10 years and is honored to be an INETA speaker and Microsoft MVP. Lately, he's shifted from technical design to designing for people and is now a user experience designer for Infragistics.