I’ll tell you who writes those “How To” manuals–technical writers like me! I’ve been a technical writer for most of my working life. For those who don’t know what a technical writer does, here’s a quick explanation: we make the complicated simple. Technical writers put together “how to” manuals, such as the ones you get with your new DVR, iPad, etc. The whole concept of a “How To” or user’s guide is to give your clear step-by-step instructions on how to use the product you just bought.
Unbeknownst to many, technical writers for the most part are rarely experts on the subject matter. What we are experts in is writing and getting information from our SMEs (Subject Matter Experts). Once we have that, we can put together a clear and concise manual. I have written manuals about everything from F-16s to optical lens technology to X-ray machines to a few states’ Department of Labor laws and more. Believe me, had I been an expert in everything I’ve written manuals for, my head would have exploded by now.
As with everything in life, there are technical manuals that actually help, and others that, well, for lack of a better phrase–don’t. My own style is pretty basic. I start with the assumption that the user knows no more about this gadget/doo-dad/device than I do, and go from there. When you get something new that you know little or nothing about, you want to know how to use it and FAST. So, based on that premise, a good manual will tell you how to 1) put it together, 2) how to run it, and 3) how to stop it. Once you have that down, it’s a lot easier to learn the other stuff.
Technical writers are not only good writers, but good organizers, too. We recognize that humans learn best when the instructions are simple, easy to follow, clear and consistent. For example, let’s say we need a manual to walk someone through how to make a sandwich: you get out two pieces of bread, put the filling of your choice on one side, then cover it with the other piece of bread. Easy–we no longer have to think about it. Therefore when we write a technical manual, we follow the same basic rules as the Sandwich Principle–filling inside, bread outside. We don’t confuse the reader midway through by switching the bread with the filling.
So how do we do it, not being experts? Simple. We pick the brains of the experts themselves. I have worked with many types of engineers, and there is one thing consistent with them all–they are BRILLIANT. However, they often do not communicate in a way that most people do; they are so used to working with complicated theories and practices that it’s hard for them to get down to the basics. So it’s my job to pull out those basics in order to construct a user-friendly manual.
Honestly, these folks are so intelligent that halogen lights can shatter in their mere presence. Their minds work on a plane far above mine. I often ask them midway through our question-and-answer session if they are fond of a certain type of tea, coffee, chocolate, etc. This is so I can later make a Melchior-esque offering to them in thanks for their help (and also so they might help me again!).
In order for me to get the information necessary to complete a guide for the ingenious device or process that he or she has invented, my dialogue with them goes something like this:
“So, Dr. Lumens [imaginary physicist] , how exactly does a user use your thingamabob?”
(Dr. Lumens answers with sentences that use so many words I’ve never heard of (despite me being an English major, obsessive reader and pretty-ok Scrabble player) that I can actually feel my brain begin to throb.)
“Thanks for that; it sounds incredible [and insanely complicated!]. So, the user sits down in front of your thingamabob and does exactly what to start it?”
(Dr. Lumens starts to explain, but trips over his own brilliance and goes off into three separate tangents, none of which I can follow.)
“Ok. So the user sits down in front of your thingamabob and then–presses, I’m just guessing here–the On button to start?”
(Dr. Lumens stares at me as if I have great horned toads hopping out of both ears. His massive brain is so far ahead of the On button that we might as well be shouting between Mars and Jupiter.)
“O-k, I’m assuming that the On button starts the process. After doing this, the user does–what?”
(Dr. Lumens thinks about the question, then gives me a good explanation of what happens several steps AFTER the On button.)
“Thanks very much for your time, Dr. Lumens. I’m going to prepare an outline of your manual, and then email it to you. I would very much appreciate your going through it and making any comments or changes you see fit.”
(Dr. Lumens finally looks me square in the eye. I can tell that he not only appreciates that this first meeting was so short, but that he can look over my manual AT A LATER TIME THAN THIS. Gruffly, he says he will ‘get to it when I can.’)
“Thank you, Dr. Lumens. I’ll send you the outline once I’ve put it together from my notes.”
(Dr. Lumens, still sitting, looks at me expectantly.)
“Oh! Um, can I bring you a caramel latte/two sugars/extra cream?”
(Dr. Lumens solemnly nods his head once, then leaves.)
Done and done. Much work follows, but you get the gist of it–I continue to winkle out precious bits of information from Dr. Lumens and start putting the pieces into a manual template. After this, all I need to do is to keep emailing the good doctor with each iteration until we come to a mutually agreed-upon user manual. Of course, once a user actually reads the manual to use Dr. Lumens’ thingamabob, all new information will come in, but again, it’s my job to keep up with the changes. Eventually we get to a point where not only can the user use Dr. Lumens’ thingamabob, but Dr. Lumens’ himself accepts the manual.
How do I know he likes it? Two things: 1) the manual survives the approval process, and 2) I never hear from him. In this business, that’s a good thing. No feedback from an SME means ‘ya done good.’
Let me close with this truth about technical writers: we don’t do this for praise. We do it because we are obsessed with words and instructions, and we can’t look at a misspelling in a menu without pointing it out to the person in charge (who usually does NOT appreciate it). Technical writers are like plumbers; that is, you don’t need a plumber until you need a plumber, if you get my drift.
Their job is to keep on being brilliant. My job is to translate that brilliance into text that the rest of us can understand.