I argued in Too Big to Browse; Too Small to Search, that search works best when it has a large amount of content to work with. But it occurs to me that there is a really important caveat to be made, which I can best express as the difference between findability and searchability.
The distinction I want to make is not clear in the common usage of the words “find” and “search”. They are often used as synonyms, particularly in computer interfaces. But I think there is nevertheless a significant difference in the connotations, which points to a significant distinction we should pay attention to when we think about the findability of our content.
Find is a word often used to describe locating something known and/or in an expected location. For instance, I might set out to find my keys (a known object) in one of the familiar places I leave them: in my pockets, on the dresser, in the door. I find a word in the dictionary (given a known word and and expected location). Search is a word often used to describe locating something not specifically known, or not in an expected location. If I can’t find my keys where I usually leave them, I may have to search the house for them. If I am lost in the woods, I search for food.
Here’s a tech comm example that illustrates the difference. If I am a programmer and I know that I need to call a certain function, but I don’t remember the exact syntax of the function call, I can find the function by name (something known and specific) in the API Reference (an expected location). But if I want to solve a particular programming problem, and I don’t know whether or not there is a function for it, I will probably search Google (not a specific location) by attempting to describe the problem I am trying to solve (not a specific or known object). The answer may come from the API reference, if there is actually a function that does what I need, but I did not start out with enough information to find it there — I had to search more generally. Next time, though, if I remember the function name, I may find it directly in the API reference, rather than having to search again.
Searching and finding are different in a some important ways that can make a substantial difference to our findability strategy.
- Searching works best with a larger body of material. Finding works best on a small body of material. If I am lost in the woods, the more territory I can search for food, the better my chances of turning up something to eat. If I lose my car keys in the woods, then the less territory I have to look in, the better my chances of finding my keys.
- People find things by name. They search for things by problem. That is, if I want to find the syntax of printf(), I enter “printf” in the find box. But if I want to find a way to get the user’s home directory from an XSLT script, I enter my problem “get the user’s home directory from XSLT” in the search box.
- Finding addresses “where is the” questions; searching addresses “is there a” questions.
- Searching can be a multi-step process, which can involve multiple searches, or searching followed by browsing links. Finding is generally one-and-done. If the specific object I want to find is not in the expected location, I switch from finding to searching.
These differences have important consequences for the kinds of findability aids we provide:
- Searching requires a relevance engine to correlate a non-specific search string with useful resources. Relevance engines work best with large volumes of content and large numbers of query strings to profile, which in practical terms means your help system’s search/find function will suck for search. The most effective search strategy is probably going to be to put your content where Google can index it.
- Finding requires a specific vocabulary to match the specific find term with a specific known resource. Your help system’s search/find function and/or its index function is going to work much better for finding than searching.
- Traditional book-based aids, such as TOCs and indexes, are finding aids, not searching aids. (This may leave those of us who grew up in a book-based civilization a tacit bias in favor of finding over searching, which we will need to examine and get over.)
- Other findability aids, such as faceted search, are likely to work much better for finding than for searching.
- Taxonomies are finding aids, not searching aids.
- Links between topics are much more important for search behaviors than for finding behaviors.
- Hierarchies, up to a point, may be useful finding aids (though they are still limited by their artificial subordination of categories), but they are useless for searching (indeed, I believe they are a positive hindrance to searching).
Once we recognize the difference between finding and searching, we have to ask ourselves some questions:
- Which is more important to my user base, finding or searching? What role does industry, role, or demographics play in their preferences?
- Is finding a bigger issue for some content, and searching the bigger issue for other content? For instance, is finding a bigger issue for reference content and searching a bigger issue for task-support content?
- Can I design my content to support both finding and searching well? (For example, is my linking strategy good enough to support the refinement stage of the search process?)
- Do I have both a findability strategy and a searchability strategy?
Do you? Do you have both a findability strategy and a searchability strategy?