An Information Taxonomy for User Assistance Architects--
[Musical segue into this piece: Paul McCartney singing in the background, "Some people say we've had enough of silly taxonomies"]

Well, I look around me and I say it isn't so.

Actually, I just want to tweak a couple that have been around for awhile just to put them into more of an architectural context.

Two taxonomies that dominate technical writing are Information Mapping® and one whose origins escape me, but which I read most recently in the Wiley Encyclopedia of Electrical and Electronics Engineering.

Information Mapping identifies the following seven types of information:

• Procedures—steps
• Process description—explanations
• Structure—descriptions
• Concepts—definitions and examples
• Principles—rules
• Facts—physical characteristics
• Classification—types and categories

The Wiley Encyclopedia of Electrical and Electronics Engineering identifies the following four types:

• Procedural
• Conceptual
• Reference
• Instructional

The Information Mapping Model is most useful when you have a bunch of poorly structured information and you are trying to figure out how to organize it and present it.

As a user assistance architect, however, I am more interested in a taxonomy that lets me analyze the user's information needs, i.e., go through a workflow or screenflow and ask, "What kind of information would the user need here? Information Mappers will argue that its taxonomy will work fine--and I won't disagree.

But I like the simpler Wiley model, with one tweak. I would replace Instructional with Guidelines. For the kinds of products I support, that makes more sense for me.

Definitions
By and large, I use the first three the way the encyclopediaclopedia defines them.

Conceptual, in the sense I want to use it, is broader than the information mapping definition and applies to any background information that the user might need to understand a screen or procedure. In essence, conceptual information is about the product or application domain, but it has no action context.

Procedural is what it has always meant—steps in the right order.

Reference is the look-up details like specifications, glossaries, and command syntax. Meant to be dived into at some particular snippet and not meant to be read like a coherent discourse.

Guidelines is a somewhat different twist than instructional. Guidelines are provided at distinct points in a workflow or screenflow where the user must make a decision, e.g., enter a value or select/deselect a feature. Guidelines coincide somewhat with Information Mapping's Principles. They should be action oriented and help users understand the following:

• What should they consider when making the decision?
• What are typical or recommended starting points or selections?
• What are the impacts of their selection?
• How would they monitor the correctness of their decision?
• How would they adjust or tune their decision?

Example
Let's say that a user is in MS Excel and is using a statistical function to calculate the probability outcome for a t-test of independent means.

Conceptual help would explain what a t-test is and define the required inputs/ouputs, i.e., alpha and p.

Procedural help would go through the steps, including navigation to get to the function arguments dialog and how to select the data fields directly from the spreadsheet.

Reference help might give the actual formulas being used in the function.

Guidance help would assist the user in selecting the appropriate value for alpha. And that's the rub! You need a researcher to give you that insight, not the worksheet designer or programmer. But it sure would be helpful for someone to tell you:

Alpha lets you set the level of risk you are willing to take for rejecting a true difference. A typical value of 0.1 is used for many marketing and social science research projects. Where harm could come from accepting a false finding as true, for example in a medical research project or one that would influence a high dollar investment, more conservative values of 0.05 and even 0.01 are often used.

Setting this value too high could result in your claiming there was a real difference between the two samples when in fact there wasn't.

Setting this value too low could result in your rejecting the claim that there was a real difference between the two samples when in fact there was.

Lower alpha values usually require higher sample sizes to be practical.

That information, combined with the conceptual help that would have elaborated a bit more on the definition of alpha, would help the user make a better-informed decision.

Conclusion
As you plan a user assistance design for an application, look for opportunities for the four types of user assisatnce described above, and be particularly diligent about identifying the need for Guidance help. It is probably our biggest shortcoming in the user assistance world.