Technical communicators often develop software documentation and manuals before product completion. While financially sound, this practice produces frustration in the user and unusable manuals. Consider the following example and fill in the names, dates, and manual titles from your own bad experience.
You watch in awe as a coworker does an amazing trick with a popular word processing application. You know you could use this feature to impress your friends and make your supervisor ooh and ahh. At home you try to use this spectacular new discovery. You follow each step precisely as you saw it done. But nothing happens. You repeat each step again and still nothing happens. As a user, you do what comes naturally – avoid looking at the documentation at all costs! You call the person who showed you the trick. No one answers the telephone. You then call the friend who knows more about computers than you ever want to know.
He tells you to look at the manual. You know that if he tells you to look at the manual you must need serious help. As a last resort, you break down and look in the manual. You look in the table of contents, the index, and then flip aimlessly through the pages as you silently curse. Frustrated, you decide to try online help. Again you search by subject, by word, and you even type your question as the program prompts you. Nothing. Nada. Zip.
Like most users, you believe the answer lies out there somewhere, so you search the documentation for hours. Finally, as exhaustion, frustration, and a mental break down threaten to overwhelm you, once again you call the guru who showed you the function five hours ago. As you share your story she laughs bitterly. "That’s not in the documentation," she says. "The programmers didn’t design that function until after the manual was written."
Imagine the rage you feel at that moment. Why does a manual, written as a tool for the user, made you feel capable of murder?
This situation occurs all the time. Can you remember the last time that you purchased anything that required assembly? I can. Not only did the box contain the wrong screws, but the manual, written in English, apparently came from a translation. Yes, the English language can read like a foreign language. Did you know that? Perhaps you did, especially if you ever bought anything that required a manual.
Herein lies a great mystery. All technical communicators use manuals at some point in time. However, when we write a manual we tend to forget every horrible experience in our past. Our goal becomes pleasing the programmers, meeting the deadlines, making the boss happy, or leaving work before rush hour traffic takes over the roadways. These goals, while worthy, ignore the user for whom we write. Let me say it another way— the user is the only reason that our profession exists.
Next time you sit down to write a manual, forget all those terms like task oriented and deliverables. Just recall those feelings of rage and frustration you experienced as a user when the one thing you needed turned into the one thing the writer forgot. Then start typing. Your manual should turn out fine