Merriam-Webster defines the noun, “help,” as a source of aid or one who assists another. Wikipedia says that online help is “…designed to give assistance in the use of a software application or operating system…” Yet, many users call your Help Desk for support!

Why do so many users call your Help Desk for support?

Because the online Help doesn’t help them.

Help?

In 1989, Microsoft released Word version 4; it shipped with a most remarkable—printed—user guide: it was beautifully designed and laid out. It was intelligently written, and made the use of that version so much easier and better. In 1991, Microsoft released version 5 of MS Word; for many of us, it was repugnant. What happened?

For one thing, there was no printed user’s guide. Microsoft had decided to save money by eliminating the printed documentation for its applications. Instead, we users had the Word Help tool to use. So, many software companies did the same thing, relying upon the Help they offered in soft-copy to suffice both as an aid to the use of their software as well as the tutorial for that software. while these may not seem to be opposed, they are radically different approaches.

Tutorials, Bells, & Whistles

A tutorial is just that: the document seeks to introduce a subject completely, assuming that the reader or participant has little, if any, experience with the topics presented. With software, such documents are most often written from the perspective of the engineers or designers. They believe that those who use their creations need (and want) to know all the elegant ins-and-outs that they have designed into the product.

There is nothing wrong with that concept. Indeed, many of us would love to take the time to sit and read about a new software application or tool. That is, we’d love to have the opportunity to lean back, open a printed book or pamphlet that contains that information, and peruse it for a period of time. Then, we would like to be able to dog the ear of a page or use a bookmark (not an electronic bookmark, by the way) and set the book (or pamphlet) down so that we can go back to work. Maybe to even try out some of the bells and whistles we have just read about.

Of No Help

Electronic, soft-copy tutorials or user’s guides do not help a person trying to use a software application to do his or her job. When you’re using an HR application to set up or administer employee benefits, for instance, and you have a problem with a particular step in the process, the last thing you want (or need) to do is to plow through multiple “Help” screens. That material was really designed to tutor you in the use of the software as a whole, not to answer a specific, “got-to-have-an-answer-now” question. In 2001, Dr. JoAnn T. Hackos pointed out that:

Information [Help] needs to match the user’s workflow… (“When Users Hate Help,” ©2001 The Center for Information-Development Management)

In other words, the user’s focus is on the tree while the Help that person is given to use describes the forest.

Solutions

Managers must understand the different purposes and goals of their documentation. Often, the same information can be used and reused in different documents, such as a “quick-start,” user’s guide (tutorial), and online Help. The data are just organized and presented differently to be effectively and efficiently used.

• Provide user’s guides the user can study when the user isn’t using the software.
• Depend upon the developers and engineers for information when you write quick-start and user’s guides.
• Depend upon users to develop the online Help system.
• Find out how users will use the software to do their jobs and organize their material accordingly.
• Organize your material so that it is easy to find and has sufficient detail to answer, in one screen, a user’s specific question.
• Go over the bug list from the acceptance tests; that helps you anticipate questions and build a good Help system.
• Review the issues dropped into the lap of the Help Desk staff; these show you what users ask and why; they help you organize your online Help files efficiently and appropriately.

A good technical communicator is a good systems analyst as well as author and is the user’s advocate.