Browse Versus Search: Stumbling into the Unknown Unknown [Organizing Content 9]
So far I've been writing about alternative ways to navigate help content. The other day I was talking with my colleagues about some of these ideas, and one colleague said, You know, when it comes down to it, most users will search for what they're looking for rather than try to browse a system of folders anyway.
I will admit that we're a search-driven culture. Our fascination with Google is that it seems to contain answers to nearly any question we ask it. We search for information, and we find it. As a result, we can skip all the old-school navigation and just give users a search box, right? Not exactly.
Search versus browse modes
Users who browse have different purposes than those who search, and we can't assume that those who browse can find content the same way through a search. Geoff Sauer pointed this out in a previous comment, explaining the following:
After Rosenfeld and Morville's 1998 book Information Architecture for the World Wide Web, the field began to differentiate between two discrete behaviors — “browse” and “search.” People who browse the EServer TC Library's Careers>Technical Writing section are behaving differently and have different goals than people searching for a particular article.
A user browses a table of contents when he or she is looking around to see what's there, usually moving with a mind open to discover new things. In contrast, a user searches content when he or she needs to locate a specific piece of information.
We do this all the time. When you fire up your computer in the morning and go to Google Reader or nytimes.com, is your first action to use the search box and search for content? No, you skim the headlines, you browse the most popular articles, you look at what's new. You don't use search because your primary intent is to discover new things.
And this is where search has its limitation: lack of discovery. A user relies on search to find specific information he or she already knows or suspects to exist. Rarely does a user search for something he or she doesn't even know to search for.
For example, let's say I download Photoshop CS5 and I'm playing around with the application. In a moment of idleness, I open the help and browse through the content. There I read the words "content fill," and start learning about a feature I didn't know existed. I would have never thought to search for "content fill," but it's in the help.
Content fill, by the way, is the ability to extract subjects from an image and have Photoshop automatically fill in the background in a seamless way. It's one of those wow-I-didn't-know-a-software-program-could-do-that moments. Now that I know the term, I can search for "content fill" and find more specific information about the topic. But previously, when I didn't even know content fill existed, it's not something I could have searched for and found.
The Unknown Unknown
In The Future of Search and Discovery, Peter Morville notes that one limitation of search is finding out the "unknown unknown." This term, the "unknown unknown," comes from Donald Rumsfeld, Morville notes. The full Rumsfeld quote is as follows:
There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don't know. But there are also unknown unknowns. These are things we do not know we don't know.
Rumsfeld's political use of this term in the context of Afghanistan drew considerable controversy, and there's an entire Wikipedia article dedicated to the term Unknown Unknown.
In fact, in the article, two Italian economists expound on the idea of the unknown unknown in a more elaborate way:
A subject is certain of something when he knows that thing; he is uncertain when he does not know it, but he knows he does not: he is consciously uncertain. On the other hand, he is unaware of something when he does not know it, and he does not know he does not know [emphasis added], and so on ad infinitum: he does not perceive, does not have in mind, the object of knowledge. The opposite of unawareness is awareness.
I could think of about a dozen examples of unknown unknowns in my life, but my focus here is with user help. How many times have you been using an application, and have grown comfortable with it, only to discover one day that the application has a feature you had no idea existed?
It happens to me often. When I experience one of these "oh, I can do that?" moments, it's exciting. It puts me on top of the world. It's an information high.
If all you give your users is a search box, you deprive the user of these moments of discovery.
For another example, look at music sites. I enjoy Grooveshark because I can often find a song I'm looking for and save it in a Favorites playlist. But Grooveshark gets old after a while, because I keep playing the same songs over and over. After a while, I switch over to Pandora, because Pandora serves up a continual stream of related artists based on preferences I entered. With this model, Pandora helps me discover artists I didn't even know about. I couldn't find them in Grooveshark because I don't even know what to search for, because I don't even know they exist.
Only 5 Percent of users search websites
I think we tend to overestimate how frequently search is used in our help files anyway. According to web usability analysts, only about 5 percent of people use the search features on websites. Granted, help files and websites aren't exactly the same thing, but they are similar. AGConsult says,
Google might be insanely popular but that doesn't mean the search feature on your website is too.
On the contrary.
When we do visitor behaviour analysis (read: Google Analytics) we often see that the search feature is rarely used by more than 5% of a site's total number of visitors. On our blogs the number of searchers is even lower: around 1,5%. On the website of a Flemish province we're working for it's just below 5%.
AGConsult goes on to say that users aren't very good at search. They frequently misspell words and use the wrong terms. Additionally, the search features on most websites aren't accurate. The whole search endeavor often becomes a last resort for users, after they fail to find information by browsing.
Additional benefits of browsing
As I said, search deprives users from discovering the unknown unknown. But there's another benefit to browsing. AGConsult also notes that "people who browse see more and buy more." This is why grocery stores place the milk, bread, and dairy at the back of the store -- it forces you to see more of the store, to browse, and ultimately to buy more.
There's a similar benefit with this browsing behavior in help content. Users who browse the help will realize that it contains empowering information to make them smarter users with the application. Users who sink their souls into the help for a while can walk away with a renewed confidence about it contents and what they can do in the application.
Users who default to search modes only may never come to see all the valuable information in help. They may search for the wrong terms several times and give up with an impatient frustration, dismissing help entirely. But users who browse will "see more and learn more."
Not dismissing search
I'm not recommending that we abandon search. In fact, the next few posts will address ways to improve the accuracy of search. But it's important not to dismiss navigation and browsing patterns with the idea that all users will just prefer to use search anyway. Yes, some may search. And some may be very good searchers, stringing together AND/OR operations, enclosing unique phrases in quotation marks, or even the grandaddy of them all, searching the help for the exact error message they're seeing.
But the majority of users, I'm guessing, stumble into help only half aware of what they're looking for. They browse the contents, realize a few new concepts along the way. When they finally leave the help, they leave with more knowledge than they intended to gain.
About Tom Johnson
I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.