The road to finding is paved with data: Web analytics and user experience

Browse—Search—Ask

Here are three important parts of three familiar sites: Flickr's site navigation, Netflix's search interface, and IKEA's help center.

Figure 1: Browse Flickr.

 

Figure 2: Search Netflix

 

Figure 3: Ask Ikea's Anna.

Do they seem to have much in common? At first glance—probably not. Navigating to the recent comments on your Flickr photos is not the same thing as searching Netflix for every movie directed by Werner Herzog. Asking the nice IKEA robot lady for help choosing a dining table is something else altogether.

And if you scratched the surface, you might find people with very different skills responsible for each. Information architects, responsible for Flickr's structure, might own its navigation; computer scientists, who know the ins and out of relevance ranking algorithms, might manage Netflix's search engine; and the help center might be the purview of IKEA's customer service specialists, the people who are trained to answer difficult customer questions (or, perhaps, difficult customers' questions).

Browse + Search + Ask = Find

Browsing, searching, and asking may appear to be used as if they were discrete functions, but that's not really how our brains work when we seek information. One might search Netflix for those Herzog films and stumble on his recent release, Rescue Dawn, which stars Christian Bale—then change course and navigate over to Bale's entry and beyond to learn about his career. Or one might ask IKEA's Anna about when the new store in Red Hook will open; after she directs you to IKEA's "hooks & hangers" section a search is the likely next step.

Browsing, searching, and asking might all take place within a single attempt to find information. Finding routes are often quite circuitous, iterative, and surprising. There certainly are simple, straightforward instances of finding—say, looking up a colleague's phone number in a staff directory. But wandering through and learning about information—with pauses to search, browse, and ask along the way—is how many of us find information and learn about both the complex (for example, determining the most appropriate health plan our employer offers) and the seemingly simple (like choosing a plumber).

Information scientists have developed a host of models to demonstrate that there's more than meets the eye when it comes to the process of finding. One example, Marcia Bates' popular berry-picking model, diagrammed below, demonstrates how finding wanders in a highly dynamic way; the user's initial query changes through each iteration of searching, asking, and browsing.

Figure 4: This diagram shows a user's circuitous path to finding information. Diagram by Peter Morville.

With all of its twists and turns, finding can be lovely and life-changing. Even when we fail to find—and we often do—we still learn. Finding is arguably at the center of all user experiences. If nothing else, it's what has powered the growth of the web, thereby guaranteeing most of those reading this article some form of gainful employment. And even for sites and products that aren't centered on some sort of finding (for example, the site for the television show Six Feet Under), well, some sort of finding is necessarily a requirement for success (e.g., how do I find that show's site? How do I find its plot summaries? How do I find the bios of each episode's guest actors?).

Unfortunately, most of the systems we design don't really support finding. We might do a bang-up job with searching, browsing, or asking. But we've failed at integrating them well; therefore our designs fail at helping users to shift effortlessly between these different aspects of finding, and instead impose harsh interruptions on the process.

The common example of failed integration of finding modes is, interestingly, when one of those modes itself has failed. If a user is experiencing trouble with browsing and isn't offered an alternative—such as searching, asking, or both—designers have denied users the opportunity to work their way through towards an answer. This is especially a pity if alternative finding modes already are available within the site.

For example, if a Delaware resident wants to know when the 2008 school year begins, he might search the web site for the State of Delaware Department of Education. A search for "2008-2009 calendar" retrieves the following set of unsatisfactory results, none of which contains the correct answer:

Figure 5: When this site's search system fails the user, it offers no alternatives other than another pass at what already hasn't worked: Search. Opportunities to ask or browse are not presented.

Finding no school year calendars, the user might want to switch to browsing something more contextual than the navigation links provided here, the best of which is so general ("Citizen Services") as to be discouraging. Nor are there obvious opportunities to try asking a human—or even a robot—for help, although it's certain that the Delaware Department of Education provides some sort of phone-based customer service.

Compare this with what happens when a search fails at the Lands' End site:

Figure 6: Failure leads Lands' End to guess at a new, broader search, as well as provide a variety of browsing options.

After issuing an earnest apology, the Lands' End site snatches victory from the jaws of search defeat. Aside from re-executing a broader version of the failed search (from "goretex anorak" to "anorak"), it provides both site-wide navigation options (e.g., "Swim," "Outerwear," "Women"…) and contextualized navigation options (four "anorak" results within "Women," three within "Men," and so on). The 800 number is prominent, as is the link to "Customer Service." And, though it's buried at the bottom of the page, users can ask a customer service representative questions via "Get Live Help:"

Figure 7: "Get Live Help" provides two ways (text and phone) to ask a human for help.

It's not surprising that, in these examples, the commerce site is better at supporting integrated finding than the government site is. Merchants are typically more motivated; they start out with a strong customer focus, and they see a clear return on investment for improving their sites' findability. The design lessons gleaned in such highly motivated environments—commerce, but also entertainment (especially gambling and pornography sites) have percolated throughout the design community. So why do so many sites continue to tuck away these different faces of finding into separate garrets? More importantly, what can designers do about it?

Why finding is often a broken experience

A lack of models. The non-digital world often provides designers with metaphors and models of how things work; these metaphors and models provide the raw material and inspiration for our digital designs. However, in physical information spaces it's difficult to integrate different modes of finding, so they provide few if any good sources of inspiration for how to integrated finding in the digital environment.

In a library, for example, the reference desk might be located in a strategic location. But there's only one reference librarian, and he can't shadow you in case you want to shift from browse to ask mode while deep in the stacks. If you're ready to search the online catalog, you'll have to hoof it back to the catalog terminal (unless you're lucky enough to have an iPhone stowed in your pocket). So even the traditional library—the most advanced physical information space that most are familiar with—doesn't provide a sufficiently integrated model to emulate in the digital space.

Finding modes are divided by irrational boundaries. Every organization is the setting for an ongoing push-and-pull of alternately foregoing responsibility and grabbing for turf. This churning has drawn bizarre, illogical boundaries around search (it's IT's thing), browse (the realm of designers and marketers), and ask (owned by customer service and support if by anyone at all).

Complicating things further, we often confuse finding modes with the specific technologies, such as search engines or CRM systems, that are integral to their function. For example, search systems are usually maintained by technical staff because managers and, too often, designers see these aspects of finding as, primarily, pieces of technology. A search engine is indeed a requirement for a successful search, but so are quality content, document titling, interface design for search entry interfaces and results, and many other factors. But decision-makers don't realize that, and assign the responsibility for the entire search experience to developers who may only be adept at maintaining the search engine itself.

Designers are sometimes complacent. Too often designers are fine with decisions that take important design issues, like the aspects of search mentioned above, out of their hands—not our table! Everyone's already too busy, and it's hard to convince oneself to try to take on something new, challenging, and time-consuming.

But there is another, less-obvious form of complacency common to so many designers: they don't design for holistic experiences—like integrated finding—because they don't speak data. Designers haven't paid much attention to the terabytes of user data being logged right under their noses. Fortunately, that's changing.

User Experience, meet Web Analytics

Over the past decade, something really good has happened to the web. Designers of all varieties have begun to recognize that it takes many different, complementary types of expertise to design today's complex digital products. Because designers have realized that no single discipline is enough, they've made great strides toward developing a shared consciousness and community across disciplines. From necessity they've mashed together many design-related practices and methods into a new animal commonly called user experience (AKA experience design). UX is awkward and a bit homely—at times more tottering Frankenstein than toddling infant—but its rise is heartening and promises the world a future filled with more competent, well-rounded designers and designs.

At the same time, another field has emerged: web analytics. What's being analyzed? The behaviors of users, as expressed by what they search, where they click, and what they transact. WA is purely data-driven, and in a digital environment, most organizations already capture each of these types of data in the form of server and search logs. Intelligent organizations have realized the value of the stories their data tell, and an industry of reporting tools, like Omniture and Google Analytics, has grown up around this need. Web analytics promises designers new, more quantitatively-driven research methods to add to their toolkits. We now have real data that suggests what is actually going on with our sites and products, a wonderful complement to the qualitative methods we already use to answer the why questions we have as designers.

These two fields—user experience and web analytics—have met, but haven't been formally introduced just yet. The partnership hasn't fully taken root, and a major reason is that data analysis requires designers to venture outside their comfort zones. Due to academic training, cognitive styles, and a host of other reasons, designers tend to be more comfortable working with the kind of qualitative information that comes from familiar research methods like usability testing, interviews, and contextual inquiry. Designers are simply better at (or, at least, more used to addressing) the why questions, and often rely on artificial constructs, like personas, to serve as placeholders for what kinds of behaviors users might exhibit rather than taking advantage of real behavioral data.

However, designers also want to address the most appropriate why questions, and they're beginning to see data-driven analyses as incredibly valuable tools for identifying the best why questions. So, if a designer is trying to develop a task analysis exercise, she can now draw on real analytics data to determine which are actually users' most frequent tasks, or which tasks are most likely to fail and therefore benefit from qualitative testing.

Using analytics to expose finding

Better data is already helping designers improve their qualitative analyses in incremental ways. But in the long term, the melding of user experience and web analytics could dramatically improve designers' ability to see and design more holistic systems, including fully integrated finding experiences. This leap forward will come because behavioral data itself will be fully integrated.

Initially, different forms of web analytics were, like finding, somewhat fragmented. Some tools helped analyze the logs produced by site's search engines, others analyzed server logs to better understand users' clickstreams, and yet others helped profile how sites were found on the web. In recent years, the industry has matured and now offers a much better picture of user behavior due to a migration from analyzing discrete logs generated by separate tools to using Javascript to capture all user data, regardless of whether the users search, ask, or browse. Now it's becoming more feasible for designers to study true sessions. The implications are quite exciting. Designers will be able to witness—through analytics—the winding road between searching, browsing, and asking, and, in turn, design experiences that weave together these finding methods.

In the meantime, there are some practical steps that designers can take, even if they're not working with state-of-the-art analytics tools. Designers can look at failures—roadblocks in the finding process—and, if possible, see how users pivot at those failure points.

For example, which pages cause users to fail at browsing most often? It might be the pages—aside from the main page—from which new searches are most commonly executed. In other words, pages where users have given up on browsing and have pivoted to an alternative—searching. Conversely, where do users navigate when searching has failed them? Study the clickstreams that most commonly begin after users retrieve a zero hits search results page (in other words, where search has failed).

Finding the perfect match

There are many near-term benefits to applying analytics to user experience design. And the long-term promises so much. So there needs to be a wedding of web analytics and user experience. Designers need to get better with data to finally be able to design for finding, as well as to better communicate with managers, business analysts, and, to a degree, information technologists and developers. Designers will have to learn a foreign language to win them over. That language is data.

Designers won't be the only ones to benefit; web analytics will necessarily grow in value if it expands beyond its familiar territory of transaction conversions. Not everything comes down to commerce, and many other areas that can benefit from an analytics perspective—like content creation and navigation design—can themselves also play an important role in transaction conversions. It ultimately does come down to the experience.

Where to go from here

If you enjoyed this article, check out these other great Think Tank articles:

• Graduate education: Preparing designers for jobs that don't exist (yet), by Anne Burdick
• On the ground running: Lessons from experience design, by Adam Greenfieldk

About the author