Knowledge Harvesting--
My big aha came several years ago when I was documenting a predictive dialer product (software/PBX switch that automatically makes outbound calls for a call center based on calling lists, and operator/outbound line availability). You know, that nasty technology that lets annoying telemarketers and collectors bother more people than if they were looking up numbers and dialing them manually.

I had to document the screen that let the system administrator set the "busy call-back time" i.e., how long the system would wait until before it redialed a number that was busy. My online help was flawless: it defined the parameter, gave the minimum and maximum values, and explained how the spinner control changed the value: "click the up arrow to increase the call-back time; click the down arrow to decrease it." Took it to a usability lab and sat poised with victory cigar in hand just waiting for the positive feedback that would say "Light 'em if you've got 'em."

Interesting turn of events, however. The parameter was pretty well named apparently; no one really needed the definition to figure out what it meant. The whole up arrow and down arrow thing seemed to work pretty well; the users figured that one out without the help. The min and max values became pretty obvious when the numbers quit going down or up.

Even so, users still went to help. What they wanted to know was, "What's a good number?"

You know, there's a reason it's sometimes called the "anything but help" button. Mine certainly fit the mold.

There is a happy ending...
I found one of our customer consultants, the folks who went onsite and helped customers tune their systems, and I asked him what a good number was.

"Ten minutes," he said. "You know there's a warm body there and you don't want to let him or her slip away."

I followed up, "Why would you make it higher or lower?" After all, there had to be a reason for the spinners that allowed the system administrator to change the parameter setting.

"Oh, I check the daily reports," he said. "If the line utilization rates are low, I change the busy call-back time to make it higher--you see, I'm calling the same busy number too many times and I'm wasting an outbound line. If the hit rate starts going low, I decrease the busy call-back time, I'm letting the live bodies get away by not calling back."

OK, there's a lot of fuzziness here, no hard and fast algorithm, but some real meaningful heuristics. That's what the users were looking for: guidance.

The Challenge
Writing up what he told me was easy, any half-dead Information Mapper (R) could do the If/then table on the way to post-op. Even anticipating the question should have been easy: any time a user is asked to set a parameter or make a decision such as enable or disable, they will want some guidance. Even the pattern was obvious: State a typical starting point, describe considerations and impacts for changing, and point to system outputs that can give you feedback on the impact of the decision made.

So why didn't I put it in the help from the get-go?

I wasn't tied into the source of application expertise--I worked with developers primarily. I'm not being snotty; it's unfair to expect that experts in C++, Java, and database creation to also be experts in running a call center. I had to leave my social and disciplinary comfort zones and seek partial truths from segments of the business I was not used to dealing with.

The challenge, then, is threefold:

• Identifying the kind of information the user will need
• Designing how to route that information from the Content Management System
• Finding the source of the information in order to articulate it and get it into the CMS

The third bullet is why I emphasize that a robust user assistance system has elements of a Knowledge Management System. It is the harvesting of useful content from experts, when that content is often loosey-goosey (aka "fuzzy") and tacit.

The upcoming STC conference in May will include a conference-in-a-conference called the Knowledge Management Institute. Larry Todd Wilson will be doing a presentation on Knowledge Harvesting--I highly recommend it for any UA architect or content developer who has to document complex applications where the guidelines users seek cannot be culled from the product technical specification.