Encyclopedias do not user assistance make--
One of my colleagues attended an internal training session last week so she could observe how our documentation is used by people doing realistic tasks. Her observations were not surprising, but bear repeating:

• Users had a lot of knowledge already.
• Users tried to solve problems using no help. They started [doing the primary task] without consulting any documentation.
• Users rarely looked at the guides or quick start cards. Documentation was the last resort.
• When using documentation, users gravitated toward the diagrams.
• Users got frustrated when they saw how many documents the [product] has on [our customer support] website.
• Users did not use the Help button on the user interface.

I'm not discouraged by these observations, mainly because they reinforce what I already knew. But it was good to be reminded and to think about their implications for product support documentation:

• User assistance has to be useful in small chunks (users don't want to spend time in documentation).
• User assistance has to be specific (users are there as a last resort and will abandon general discussions).
• Information developers should influence text on the UI (since users rarely summon the hidden Help files).
• Information developers need to emphasize informative graphics as much as they can.
• The user interface needs to provide a more compelling access to Help.

In short, Help designs and content development should be less concerned about being complete and in depth and be more concerned about being relevant as soon as possible. Time and time again I see that users go into the documentation as a last resort and when in the documentation, get back into the application as soon as they can. Help needs to look and act more like a performance support system and less like an encyclopedia.

Do the following quick audit:

• Pick any spot on your UI and imagine a likely question the user would have. Click on Help and have an associate start counting out loud--very loudly. How long did it take to get to the answer? How many clicks? Did each click add value?
• Does the Help add value beyond what is already on the UI? In other words, if all you have to say about the customer name field is that's where you put the customer's name, why bother? Seriously, we don't have to fully document our products. Nothing hides useful information better than surrounding text devoid of meaningful content.
• How much of the user's time does your documentation waste by talking about itself? I know your English teacher said to start a chapter by describing its purpose. But I have never seen a user go into a manual to answer the question, "What is chapter two about?" And please, if you take up any space explaining your typographic conventions, users do not care!
• Do you provide meaningful examples or practical guidelines?
• Do you use informative graphics?

Help needs to be quick and relevant. If a topic needs to have the users spend more than thirty seconds, it probably doesn't belong in Help. Because they won't.

John Carroll in the Nurnberg Funnel made the point that training had to accommodate how users really learned. Help has to accommodate authentic user behavior--precisely those behaviors that my colleague observed. Given a choice between re-engineering the user assistance and re-engineering the user, you will be more successful in the long run doing the former.