Look Before You Ask
In: Columns > Wide Open
Published on July 23, 2002
When I go grocery shopping, the first thing I do when I get in the door is hang a sharp turn to the customer service counter.
“Excuse me,” I say to the disenchanted attendant, “where can I find casaba melons, rye bread, and lowfat chocolate milk?” The employee rattles off the more or less exact locations of these items, and I’m off.
When I walk into a department store, the very first thing I do is walk up to the information desk.
“Excuse me, where do you keep the cross-weave black straw hats?” I ask the person behind the desk, who points me to the right shelf in the hat department. I can find my way fairly well if the representative knows the store well.
Of course, when I go to a restaurant, I start off by asking the maitre d’ whether the entrée list includes my favorite item, because I don’t want to bother to read the menu before making my selection.
What do you mean, “no?” These are real-world examples of what you do every time you use a search form without navigating the site.
I’m not here to trivialize or ridicule the use of search capability on a site. The retrieval of informaiton from a web site is a fundamentally different task than finding fresh bread at the supermarket, and should be treated differently. However, search has become the /files/includes/default.css technique for getting around online, while its offline equivalents are usually downplayed by organizations and avoided by individuals. How many of us like asking questions at the store?
A whole culture of information architecture (more on that next month) has arisen to optimize the utility and scope of site structures and navigation. Yet the first impulse for many people arriving on a site is not to look around the site hierarchy but to type in a word or three and see what results come back.
This happens on many sites as well as across the scope of the Web. Think of how frequently we head to Google and type in a few words to decipher where we want to go. A few of us head to dmoz.org or Google Groups quite often, even if they may serve us well; I hardly ever use the directory trees at Yahoo anymore, though I had a decided bias not long ago toward their hand-picked listings over generic search results.
Searching the Web has been a necessity since its sheer size became unwieldy. One would like to assume, though, that there are alternatives to finding things other than by searching, especially within a single site, where serious effort is usually expended creating a site sensible enough for people to use. The sad truth is that few of them may use it.
What brought about this reliance on search?
For one thing, search engines have become experts at honing in on results. Google, for example, has proved so reliable in its results that people have begun /files/includes/default.cssing to it over perennial favorite Yahoo and its famous directory. Some sites, like My Simon, use IA within search results to maximize the odds of finding the right thing.
An important sub-factor is the instant gratification of seeing results. If I want to buy the new Doves CD on Amazon, I can either click into Music, then browse Alternative Rock, then D in the A-to-Z listings, then on the Doves name in the alpha list; or I can type in “doves” and select “music” from Amazon’s drop-down menu, and I’m off and running in one shot. Information architecture can only do so much for the impatient.
Perhaps most importantly, we as an audience are accustomed to search. We’ve been doing it for years, even on the most well-designed sites. It’s easy, it’s enticing, it’s intriguing, and it works.
So is it bad to lean on search results?
If so, what can we do about it?
Fundamentally, searching isn’t a bad thing at all. But it certainly can be the second-best option, as it would be on a site that has a dedicated information architecture and spent time on its structural presentation. After all, the local Food King didn’t group foods together and hang descriptive signs anticipating that you would ignore them and ask for help at the front door.
(They also didn’t put the milk in the back corner for your convenience–but that’s another matter entirely.)
Indeed, there are real-world equivalents that contradict the examples I gave at the beginning of this column. The Muze kiosks at music stores encourage shoppers to search for data as they would search for items on the Web, and a good Muze result can enhance a shopper’s overall experience by increasing consumer knowledge and lessening confusion.
Still, as Web site developers, if we rely on search too much, we may sell our audiences short. If the audience becomes too accustomed to searching instead of surfing, users may habitually overlook some of the most well-designed components of our sites.
I suggest trying this instead: increase the prominence of your site hierarchy. Emphasize navigation, not overwhelmingly, but enough so the user realizes the first thing to do is scan for the appropriate area, not jump into a search form. At the same time, downplay your site search just a touch: Keep it on the home page, and move it lower on the screen, for example, or give navigation tips on your search page. Let search remain to maximize your site’s usability, but tone down its presentation just enough to encourage a click or two.
The goal is not to eliminate search as an option, but to expose the audience to an alternate, and possibly superior, mode of site navigation. Most users know a site nav exists, but do they use it? Give them positive signs that it’s going to give them smart results, and they just might.
In the meantime, I’ll still be meandering the aisles when I shop, appreciating smart information architecture and longing for the return of uncluttered category listings on Yahoo. See you by the milk.