FINDING Depends on How you SEEK –
One of the most important things to think about in making knowledge delivery systems work is HOW users will find what they’re looking for. At first glance it may seem simple: type in a search, find your stuff. But is it really that straightforward? Do you really know what you’re looking for? Do you really know what the right query is? Do you even know what content exists in the system you’re using?
One of the main reasons we all engage in building and managing support-focused search tools and portals is because we are trying to create a series of efficient, intuitive user experiences that lead people to the right answers to their questions. However, my experience is that all questions – and all users – are not created equal. Sometimes we know exactly what we need and how to ask, other times we haven’t a clue. The same person, who may be expert on one issue, may be totally lost just looking for a slightly different issue in their own KB.
In this context always think of one Christmas morning spent huddled over my sister’s computer, trying desperately to get the Disney Aladdin DVD to install and run properly, my little 4 yr old daughter wailing and pleading with me as I, the great computer expert in the family, struggled to figure out what query to enter in the Disney knowledge base to address the failure of this $5 DVD to load! One is only as smart as the next problem, really —
One of the most critical yet unrecognized features of a knowledge base is its ability to teach users about the terms, taxonomy, and content that is available to solve their question. Most searches aren’t a one-shot deal – the user progressively browses to learn about an issue, scope the content, tries different queries to see what’s in the KB, and finally decides when to browse through titles and content for the best fit. I find it useful to boil the types of interactions one needs to have based on how much one knows about an issue, and what one needs in terms of guidance from the knowledge base to get to the answer. A simple way to think about it is as follows.
Three types of navigation
1. I Know What I Know – Lookup
This is the stereotypical “Google-esque” query – I know the data I want, I know the terms that should bring it back, I type in “error 99” and voila! There’s my stuff. Support experts usually expect this type of behavior, and in fact the weaker a KB is the more they memorize special terms, document ID’s and keywords that will give them what they want. But in the end they’re not really searching as much as looking up known content. This is an important capability that must work well, but it’s far from the only interaction people have, ESPECIALLY in self-help systems.
2. I Know What I Don’t Know – Guided Search
In this scenario users know the TYPE of information they need, perhaps also the topic or potential terms, but don’t exactly know what content is out there. They may browse to scope the issue, then type in a query or two based on what appear to be the common topics. KM systems assist here by providing potential additional browse and filtering options that are relevant to the current query scope. The user can go back and forth, examining the options provided by the system, to find the right fit of topic and query detail. These systems work well when the user has some idea of what the right solution is and just needs assistance getting to the right area of the knowledge base. But that’s not the final area, nor perhaps the most important…there’s still:
3. I Don’t Know What I Don’t Know – Browse and Filter
Many users, especially those new to a particular domain, don’t really know how to think about the information that’s in it, what terms or topics are relevant, maybe not even what they’re supposed to ask. In my Disney DVD problem, I had some smart ideas but none turned out to be relevant. Was it the display driver? The computer RAM? OS version? Plug-in requirements for video? And how should I query a simple Disney DVD for this kind of stuff? These scenarios are where a good browse experience can shine. Not only can it help users figure out what the key components of a product are, the topics and known problems, but should also quickly point up common questions the user is likely to have. By seeing common issues and how they are organized users can get insight into what their questions are, or likely queries should browsing and filtering not bring back the answer immediately.
At the end of the day we’re all just looking for ANSWERS, aren’t we? If we think through what the process of acquiring knowledge entails, we can trace these patterns of inquiry and do our best to model them for particular audiences, users and issues. When this is well done for all three query types, users experience the ‘magic’ of knowledge bases. They DO indeed seem to ‘know exactly what you want’, yet you may not even be aware of how seamlessly the system allows you to move between these modes of inquiry and still get the scent of the answer you need. As KM system builders, we just have to give a little THOUGHT to how people THINK….!
“The Knowledge Advocate”