9 Types of Technical Docs

Documentation can be read, not read, tossed, used, and ignored. The most common call of Help Desks has always been “Why didn’t the User just RTFM (Read The Fine Manual)?!” Now it’s morphed for software applications at least into “read the help file,” but the concept is the same.

The following is a list of the end-user documentation I have come across in my days working in offices in many fields. I’ve ranked it in the order of what I’ve seen least used by end-users to most used. Expect a bit of fluctuation in where things fall in the rankings based on individual companies and industries.

9. Hard Copy manuals.

Not only are they not read by most people (they make great monitor stands, doorstops, and wobbly desk supports) they are often held by the IT department – especially if there is one book and a multiple seat license for software.

In addition, they are expensive to produce, and for equipment need to be updated regularly, and cost a lot to ship. If necessary, hard copy manuals can sometimes be converted to PDF files with interactive indexes and tables of contents, which can be put on CD and then updated and shipped much more cost effectively. This has many advantages, even in industries where machinery is being documented.

8. Wikis.

While these online, multiple authored documents are becoming more popular and more usable, at the moment, the extra learning curve to use and edit them puts one more hassle on the user. Except in very special circumstances, think twice.

7. F1 help that is loaded on the computer with an application.

You’d think this would be higher on the list. But, due to several factors, including bad help systems in the past, people not reading the words printed on the keyboard, and so on, the complaint “people don’t read the help!” is very accurate. This does not mean that you should forget about creating one, however. F1 help ties specific information to specific screens is extremely useful, and for the people who can be convinced to use it, amazingly useful.

6. Blogs.

Blogs written by a technical communicator, or by developers who are very proud of their system can be a wonderful way to communicate information, in particular tips and tricks that may not be immediately obvious. Whatever the choice of author, make sure any blog like this is updated with small tricks quite regularly for best coverage.

5. WebHelp Indexed by Google or other search engines.

Help files that are available on the internet for anyone to read can perform double-duty. When written well and perhaps in a more conversational tone (again, take your product into consideration) they can perform the help functionality as well as serve as a demonstration of the useful and varied benefits your product provides (tech writing as marketing function!). If you know your user base has internet access, WebHelp can also be designed to be accessed by F1 key. If not, you may want both WebHelp and a standard help file. These can be the same information, just exported into different formats: most help authoring tools allow your communicator to create this sort of dual-duty content.

4. Video Tutorials.

Video tutorials can be very effective for people who have trouble following the written word. Whether your tutorials walk them through your procedures as a “live” demonstration, or as a step by step process with captions demonstrating what is being done, these are popular with users.

3. Built-in Help.

I’m referring here to actual help on the screen, whether accessed by a button labeled “Help” that works like an F1 key, pop-up tool tips, a small section of the screen real estate that automatically displays help linked to what the user is doing, when used judiciously and providing real instruction about what the user needs, once he’s trained to see it when he needs it, it can be very effective.

2. Cheat Sheets.

In some companies, these are called “Job Aids” because management doesn’t want to be seen as advocating cheating in any form. A small bar that you can place above your keyboard that lists the most common keystroke commands for your computer application fits this category. So do letter-sized checklists that can be laminated and kept by machines for easy reference.  These are often the most used pieces of documentation in the workplace.

1. Calling Across the Cubicle to a Coworker with a Question

While most people wouldn’t call this documentation, exactly, it is the most commonly used method of getting help on machinery or software, or anything else for that matter. The bit of psychology that most writers and developers forget is that most people prefer to learn something from someone they trust, in person and with real communication. This is also why there is a certain percentage of people who, no matter how good the resources provided with your product will always call the help desk whenever they have a question, rather than looking it up.

Sorry, comments are closed for this post.