Why is it that when people get stuck trying to figure out a piece of technology, they invariably pick up the phone and call a help desk rather than open a manual or, if it’s available, click on the help button? Certainly, it would be quicker to find the answer than wait for the “next representative to become available.” The answer, of course, is obvious, as anyone who has tried to read a technical manual can tell you: Either the answer isn’t readily available (can’t find it) or doesn’t make sense (can’t figure out what’s being said when they do find it).
As a technical writer, educator, and owner of a technical writing consulting business, I am acutely aware of this situation. Unfortunately, most of what passes for technical writing is bad. Anyone who has tried to assemble anything that comes in a box knows how difficult it is to turn the assortment of wood, screws and bolts into a bookcase by simply following the pictures in a manual. Or the unfortunate computer user who receives a message that the program has encountered a problem and must shutdown and looks hopelessly at the 700 page manual that came with the computer and picks up the phone.
So why is this? The problem, as I have observed, is most often due to the fact that the people writing about technology don’t understand it themselves. And, as I used to preach when I taught Composition 101 at various colleges and universities, if you don’t understand what you’re writing about, no one will understand what you’ve written. This is true whether you’re writing about what you did last summer or how to use API or how to repair a jet engine.
Unfortunately, the number of people who can understand technology and have the skills to describe it is fairly small. Most of the candidates who interview at our company are competent writers but don’t have a clue how things work. When I question them about their apparent lack of understanding, they tell me that we just have tell them what to write. Yikes!
The situation is not as hopeless as it sounds. We’ve discovered a number of candidates who are very technical — and not only can write but enjoy writing — but don’t want to be engineers. Usually, we find that they are better understanding the technical aspects of the project than they are at the exposition, but we can work with that: We can edit the material and work with them to make the manual clearer and more effective. The opposite is rarely true: No matter how well the person can write, if he or she doesn’t understand the technology, no amount of work (short of rewriting the manual myself) is going to make material any better.