ere’s a toast to those gentle if anguished souls who toil anonymously with the singular goal of helping you better understand something. How to use your new computer. Install and configure your new app. Or navigate an ambiguous user interface designed by engineers who think differently—and don’t get out much.
Who are these gentle souls? We speak of technical writers: altruistic, hard-working, under-appreciated but nonetheless essential animals in the technology food chain.
Virtually everything we purchase that is computerized, mechanical, electrical, or requires assembly comes with a manual. As products are being developed, some dedicated typist is toiling away trying to create content that will help you make sense of it all.
We have known many of these characters over a career that has spanned too many years to mention. Technical writers are a strange breed, caught somewhere between the lay person and the geek.
Here at tech-52, we write for enjoyment, but we also write manuals for a living. To pay the bills, yes, but also because it’s a pretty interesting profession. And we like to believe that we might actually be helping people.
Usually tech writers stumble on, then become impassioned by, the career. Musicians, artists, journalists, English and philosophy majors—all kinds of usually right-brain thinkers—come to the profession.
Sometimes it seems like we are irreplaceable. Other times it seems we may soon be extinct.
No one reads anymore, do they?
We’ve heard colleagues say “No one reads the documentation,” and it stings a little bit, even though we know it’s a falsehood posing as fact.
We know our users read the manuals, because when there’s a mistake in the documentation, or missing information, we hear about it from our technical support colleagues who deal directly with customers.
The reality is people have just too darn much reading to do. That’s why it’s critical for a manual to be right sized, and carefully written to include only what the reader needs to know.
That is the holy grail of the technical writer, writing a manual that is not only usable, but helpful and appreciated, as well.
And that’s where our expertise and our own experiences can be truly valuable.
Technical writers are people too
Technical writers are also product users. We have the same likes and dislikes as most people. And most of us do read the manual—or at least attempt to. We appreciate it when a manual exhibits good production values and quality prose. We’re elated when it provides illustrations that make absorbing the information easier. We’re ecstatic when a manual is short and sweet and tells us just what we need to know.
(Paradoxically, It’s actually easier to write a large tome than it is to create a small but effective booklet.)
When we buy a new product, the first thing we do—and strongly encourage others to do—is read the documentation. Even when something seems intuitive, or it’s something we’ve done a dozen times before, along comes a manufacturer who introduces a new wrinkle. It’s usually critical to know this before we forge ahead with a product.
Unfortunately, companies increasingly are cutting corners when it comes to documentation—reducing budget, laying off writers and editors, and outsourcing work to less qualified (and less expensive) contractors. “Good enough” is replacing excellence in these cases, and simply providing some kind of document is all that’s required.
We’ve even heard of companies moving entire publication departments to India and China, where English is a second or third language!
Downsizing and off-shoring is problematic in many ways, not the least of which is that products, especially technology products, are becoming increasingly more powerful and complex, and the technical aptitude of consumers is not keeping pace.
A failure to communicate
Maybe if fewer users are reading the manual, it’s because they are growing increasingly distrustful of the content. If a manual seems like an afterthought, if the quality of the writing, the production values, graphic design, and typography are shoddy, if the manual was printed on cheap paper, or not printed at all—all these things must mean that the information provided inside is shoddy, too.
The mere presence of a manual does not guarantee a satisfied customer, but a poorly written, inaccurate manual almost certainly guarantees a dissatisfied customer.
The happy path
In the computer industry, there’s a concept known as the “happy path.” This refers to an installation procedure or a workflow wherein the user goes through a procedure, mostly accepting the defaults, with the idea of getting done quickly and with the fewest headaches. Nine out of 10 times, the happy path will work for you. The happy path lulls people into thinking that they don’t need to read the manual. Sometimes this is true, but many times you’re not going to get the most out of the product that you spent good money on.
We’ve found on quite a few occasions, with different products, that the happy path was not the best approach for us.
The happy path is the manufacturer’s idea of what is best and is likely to result in the fewest support calls. However, your workflow, or the way you organize your life, or the hemisphere of the brain you most often use, might run counter to the manufacturer’s happy path.
Reading the documentation can result in a better decision.
Over the years, we’ve worked closely with technical support teams who spend their days talking to mostly disgruntled customers who can’t figure out how to make something work. We see firsthand the many problems associated with customers not reading the product manuals.
The anguished cry from technical support engineers after a support call with a clueless customer is “Aarrgh! RTFM” (read the f—ing manual)! The customer is always right, but they could at least make an effort to help themselves.
Clearly the industry has to improve, as well. We need to design better products, and provide better methods of training and knowledge transfer. We need to engage with our customers and adapt to an ever-changing, fast-paced world where people don’t have a lot of time to get their jobs done, and therefore not a lot of time to read stacks of manuals.
Throw us a bone
The next time you need to work with a product, however, read, or at least browse, the manual. You might find something really useful inside, and if you don’t find it helpful, complain to the company. Let them know that you deserve better.
You’ll be encouraging them to invest in their publications department, which might mean we tech writers will get to keep our jobs.