Browse Versus Search: Stumbling into the Unknown Unknown [Organizing Content 9]
May 26th, 2010 | Posted in blog 9 Comments »
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.
Sponsors
Tags: AG Consult, Donald Rumsfeld, Information Architecture Summit, Peter Morville, search patterns, Technical Writing, user behavior
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
Both comments and pings are currently closed.
Mark Baker (5)
DiSc (3)
Ellis Pratt (3)
Jen (3)
Neal (3)
Richard Hamilton (3)
Jenny (2)
Sarah Maddox (2)
Sarah O'Keefe (2)
Stefan Kleineiken... (2)
Hi Tom -
Personally, I lean more toward search than TOCs. But that’s me. Perhaps it’s because I usually go into help files to get info and get out quick. I rarely look at TOCs and generally don’t browse them, but should more often for the reasons you note. I’m sure I could find helpful information I wasn’t looking for. Also, once a TOC gets past a certain size, I don’t even want to look at it. There’s more information than I’ll probably ever use. Take Word, for example. It has many great features, but I don’t use them all. Ultimately, users need to be able to drill down to just what they need.
Your point about the ways people search is well-taken. Everyone is different. It always amazes me to watch my son search for info. Whereas I may type in “hot dogs barbecue” for something, he’ll go ahead and type in an entire sentence, such as “how do I barbecue a hot dog on an outdoor grill in August?” I always think “Hmmmm. I have to remember that next time I write some docs to make sure it’s findable.” How do we balance the need for brevity vs. the need for findability? Tough one sometimes.
Then there’s Twitter, which I’m regarding more and more as one big search-fest. The Twitterverse is, in reality, a world-wide army of reference librarians, pulling down info from the Web and sorting it into feeds. At a first level of organization, I follow people for specific reasons – for their expertise in a certain area. I know that they will find info for me about their topic. So from all the info to be had via the Twitterverse, I’ve managed to take advantage of its inherent organization (level 1) just by choosing whom to follow. From there, you can then group feeds into lists (level 2). Then there’s another wildcard search option: hashtags. Let’s say you use #techcomm. You’ll likely find writers tweeting about something you’re interested in, or will be once you see it. You may also (and probably will) find other people to follow or add to one of your lists. So I think that ties in to your browsing idea. Use multiple hashtags, and you can have a search ebb-and-flow. Widen the net or reel it in. Twitter is a magical combo of searching and browsing. The former enables the latter. It also enables me to customize my content. Of all the info out there, I’m mainly interested in a specific subset, really.
I wonder: can we have subscription options in docs, like following people in Twitter? That would be interesting. A while back, I came across mention of some in-house Twitter-type apps. Maybe as part of user collaboration with docs, users could review info in documentation, intranets, Internet, whatever and tweet about it. They could specialize and users can follow who they want. Or maybe you could push info out from the docs to people that you think they might be interested in. What about the people that don’t open the help in the first place? Think of your browsing idea: let’s take the docs to them. Surely there are many helpful tips in the docs that people would appreciate hearing about.
Maybe as you’re thinking about all this (great series, BTW), we can look outside of docs and websites and old help file structure and look at new methods and devices, to look entirely into the unknown. What can we make? I don’t even know that it would come down to either browsing or searching. Maybe (probably) a combo. Maybe something else entirely. Let’s push the envelope and see what develops.
Looking forward to your next post -
Julie, thanks for sharing your thoughts here. I like your insight about looking outside tech comm to other models such as Twitter, and then pulling those models back to tech comm. Your point is really worthwhile here. This seems to arrive at another problem with tech comm: the toolset is limiting. But if you adopt web tools for tech comm publishing, you have many more options available.
I also found your analysis of Twitter itself interesting. You said, “Then there’s Twitter, which I’m regarding more and more as one big search-fest. The Twitterverse is, in reality, a world-wide army of reference librarians, pulling down info from the Web and sorting it into feeds.” I admit I hadn’t thought of Twitter in that light. I don’t use Twitter productively enough. I see all of this random information / noise constantly disseminated and wonder if it’s a time sink or whether it’s an idea catalyst. I want it to be the latter, but often it slips into the former.
What tools do you use to constantly pull in Twitter hashtags? Tweetdeck?
Your comment has given me a lot to think about.
Thanks, Tom.
You’ve got me thinking as well. I have not considered the browsing aspect of using tech docs enough. I’ll definitely be keeping that in mind more from here on out.
Personally, I would be lost without Twitter. It’s an excellent resource. I use it to gather info, and have found much interesting, timely, and compelling content I never would have otherwise. I start the day perusing the feeds I follow; it’s my morning paper. My goal in using it is to also share info with my followers, focusing mainly on tech communication and social media. With all the changes going on, Twitter makes it easier to stay on top of trends. Whether or not Twitter is a good use of one’s time depends in part on who you follow, I think. As much as possible, I try to focus on feeds that mostly share content and avoid those that are more conversation-based. But, again, that’s me. Just one person in the Twitterverse.
Currently, I use HootSuite but am also looking at TweetDeck. These tools are great because you can set up columns for your different lists and hashtags you regularly follow. It makes it easy to jump in, scan some tweets, and move along. You can find some real gems once in a while. Just today, there was one on #techcomm from @KnowledgeBishop. He shares a link to a site that changes tweets into a newspaper, so you can, in effect, make a customized news feed for yourself. Here’s the link: http://paper.li/.
That’s really cool; check it out. Now I’m thinking about how that could be used for docs. I bet it would be useful for handling browsing for info. All these new methods and tools are sure making tech writing interesting these days.
Julie, thanks for expanding more on how you use Twitter. I agree that some tools like TweetDeck can help organize the information in a more sensible way. I guess I still have a lot to learn about Twitter. The main problem I run into is figuring out how to reduce the noise and increase the quality of content. As you say, sometimes there are real gems. But for me, most of the time it’s simply a distraction.
[...] Browse Versus Search: Stumbling into the Unknown Unknown … [...]
What needs to be considered is a seamless experience between search and browse so that that avenues to the unknown can be explored (browsing) within a defined known (search) and so that an unknown (browse space) can be quickly sliced (via search) into unknowns of specific interest.
Note that even Google has begun to see the benefits of certain kinds of browsing experiences with the additions to their sidebar of Related Searches, Wonder Wheel and Timeline views. While not the same as a pre-structured experience it still is more exploratory then just filtering.
Thanks for participating in the conversation, Karl. You summarized the need for the search and browse experience well. I haven’t explored many of these alternative Google browsing experiences that you mention, so thanks for noting them here.
Your point about the ways people search is well-taken. Everyone is different. It always amazes me to watch my son search for info. Whereas I may type in “hot dogs barbecue” for something, he’ll go ahead and type in an entire sentence, such as “how do I barbecue a hot dog on an outdoor grill in August?” I always think “Hmmmm. I have to remember that next time I write some docs to make sure it’s findable.” How do we balance the need for brevity vs. the need for findability? Tough one sometimes.
Maybe as you’re thinking about all this (great series, BTW), we can look outside of docs and websites and old help file structure and look at new methods and devices, to look entirely into the unknown. What can we make? I don’t even know that it would come down to either browsing or searching. Maybe (probably) a combo. Maybe something else entirely. Let’s push the envelope and see what develops.