When I’m not writing about video for PLSN or tracking down the latest video innovations on the concert stage, I make my living writing technical manuals for my clients. Way back in the last century, when the mighty Ampex was downsizing, I left the company to start my own business thinking that I could make a living producing sales, training, and marketing videos for broadcast manufacturers. However, a trend soon emerged after the first few dozen cold calls. Potential clients told me that their customers loved their products, but hated their manuals (and since this is a fine, respectful publication, we can’t print the client’s actual descriptions of their own manuals).
Reinvented!
Voila! Armed with Adobe® FrameMaker®, Visio®, PhotoShop® and Webster’s Compact Writers Guide, I reinvented myself — and have never looked back. It’s proven to be a remarkably good path in a number of ways. First, tech writing is a perfect way to stay current in the midst of changing technology. One is forced to adapt, learn, and then explain new technologies — as clearly as possible, and in the most un-ambiguous manner possible. Second, you get to learn how to operate just about every new goodie that’s invented, down to the last nuance of the very last menu — even before John Q. Roadie gets his hands on it. And for a true techie, this is major cutting-edge fun.
Finally, you get to interact with the propeller-heads in the engineering department, and if they’re open minded, you get to suggest changes — and offer better ways of doing things that make more sense to someone on the crew, rather than someone coding in C++ in a cubicle.
Yet, after doing this for 20-plus years, I can still say with complete certainty — no one reads manuals. No one, nada, zip, bupkis. Those of you out there that read them … may I see a show of hands, please? (scanning the horizon) See! No one (sound of crickets).
Manuals?
In a nutshell, this is the tech writer’s lament. The work is meticulous, the diagrams are precise, the indexes are deep and lengthy, but our actual audience is very minute — even though there are countless benefits to be realized. From the manufacturer’s perspective, the manual is a required item on a product’s critical production path. If there’s no manual in the shipping package you can expect major trouble from the reseller, dealership and ultimately, the buyer. Or, if the company opts to have their manuals written by engineering, you’ll definitely get a manual, but it won’t be written from an operator’s perspective, and ambiguity may reign. If the company does hire a writer, a manual is published (physically and electronically) — which no one reads, and the result is major complaining from the company’s technical support team. It’s an interesting cycle.
Given the choice of reading Tom Clancy or the Wombat 101 User’s Guide, which one would you choose? And in today’s environment of instant gratification, the “connect and stumble” method of learning the product seems to be preferred. To paraphrase the classic line from John Huston’s Treasure of the Sierra Madre, “Manuals? I don’t got to read no stinkin’ manuals!”
QSG to the Rescue (Almost)
Based on the “connect and stumble” method (and out of the writer’s sincere desire to educate and inform), the Quick Start Guide (QSG) was born. These are typically very brief, highly concise, graphically oriented guides designed to get you connected and going in relatively short time. Almost every company now deploys them — from the $50 Bluetooth headset, to the $50K HD projector.
Unlike the full manuals, the readership percentage is pretty high by comparison — because a QSG is fast and easy. Follow the steps, and you will get a picture on the monitor, or some kind of valid output. You won’t learn every mode and feature, but it might be barely enough to keep the director from yelling at you. However, if you get into trouble or need more information about a particular function, two pages of laminated cardboard won’t cut it. (That’s precisely why I spend hours on my indexes, to point you to a precise topic — but sadly, I know you ain’t gonna use the index either.)
A Fable (But Not Really)
So let’s turn to the ugly downside of not reading the manual. From an actual transcript of an actual (highly trained) tech support professional, it goes something like this:
Customer: My projector doesn’t do anything.
Tech Support: What kind of projector is it?
Customer: A black one.
Tech Support: Can you describe it for me?
Customer: Yes, my boss says it was very expensive.
Tech Support: Can you press the menu button on the remote control for me?
Customer: No, we’re not allowed to use the remote control, only our boss can use it.
Tech Support: Did you read the troubleshooting section in the manual?
Customer: No, it was just easier to call you people.
Tech Support: (mumbling under his breath, “RTFM, RTFM …”)
Granted, given the benefit of the doubt, the customer might have been under pressure, or perhaps in a critical production situation — but think of the benefits had the manual been read. Perhaps the “troubleshooting” section might have shed some light on the situation — pun intended.
Closing Arguments
Ok, if you absolutely, stubbornly refuse to read the manuals, at least heed the following guidelines when you call tech support (because you will call them, you know).
Establish a common vocabulary early on. If you can clarify basic terminology, you’ll eliminate verbal problems quickly, and get to the electronic problems that much faster.
Remember that the tech support pro is not physically in front of your system, nor does he have the same configuration of peripheral equipment. He’s following a series of concise troubleshooting steps based on his knowledge and experience — but your description of the glitch is all he has to go on. Be specific and accurate!
Stay in sync with the tech support pro. Do not get ahead of him, and do not press keys out of sequence. Pay attention!
And if all else fails, RTFM.
