If No One Reads the Manual, That's Okay

by Tom Johnson on Dec 27, 2009
categories: technical-writing

Most people take time off during the holidays, so if you don't, you end up mostly sitting alone at work, wondering why you're not taking time off too. I wanted to follow Penelope Trunk's advice about pursuing your pet projects while working during the holidays, but instead I was trying to finish a project with an end-of-year deadline.

The project I'm working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I'm writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don't expect anyone will ever read it.

It's a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.

And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don't think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.

The idea that "no one reads the manual" is certainly not new. But despite this accepted truism, most of us don't entirely believe it. I think we always have an imagined audience in mind when we write. I often imagine a confused user searching for questions in the help, or a new employee printing out the manual and reading it, making notes in the margins and going step by step through tasks a manager marked. I imagine a user familiar with an application suddenly dumbfounded on a specific screen, clicking help and scanning for answers.

I need this fantasy about the way my manuals are used because without it, there's no motivation to write.

Charles Hurwitz, a technical writer in Israel, recently had an experience that confirmed the idea that no one reads the help. Charles writes,

Early on in my tech writer career I had the eye-opening experience of walking into an engineer's office and seeing a multi-volume set documentation on his bookshelf still covered in shrink wrap. I thought to myself that after all the months work on the manuals he should at least have the common human decency to take off the shrink wrap. It's like buy a painting and hanging it with the painted side facing the wall. Since then when people ask me what I do I tell them I write books that nobody reads. (It's Official--Nobody Reads the Manual)

In his post, Charles also references a survey by Gadget Helpline that found 64% of men and 24% of women don't read the manual before calling support (Gadget Problems Divide the Sexes).

It's not just a matter of putting the manual gently aside. Users actually despise long manuals. Ron Jeffries writes, "Your customer hates big manuals. He has shelves and boxes full of them just like you do." (Manuals in Extreme Programming).

I believe the discomfort of reading a 200-page manual compares with the pain a dentist administers when removing a tooth, or the frustration an IRS writer creates when he or she makes a long, complicated tax booklet users will have to figure out.

Joel Spolsky, a programmer and web entrepreneur, says,

Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done. (Designing for People Who Have Better Things To Do With Their Lives)

When I interviewed Mike Hughes several months ago for a podcast, he said the conclusion of most studies about how people use help is that they don't actually use help.

Some writers still find hope in the rare instances when users will consult the help. Sheila Fahey of Cherryleaf explains: "When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it." (If no-one reads the manual, then why bother?)

Looking at help this way is seeing the help as an emergency kit in a car. People won't normally need the emergency kit, but when you're stranded on the side of the road in the middle of nowhere and hungry and cold, you will use it. You will break it out of the plastic wrap and actually use it.

Flipping Sides

Not many writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.

But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it's probably going to tank on the market and you'll soon be out of a job anyway.

Also, if so many people are consulting the help, you probably aren't contributing enough on the design/usability side of your technical writing role. Remember that you're part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that's a good thing.

No One Knows

Knowing exactly how often help is used and by whom is hard to measure. If your help is entirely online, you can measure basic hits easily enough. But if it's distributed in print, you can't really know.

For example, on Christmas day, my sister-in-law was putting together a fish tank and filter for her boyfriend. (By the way, a Betta fish is a cool present to give someone.) Installing the pump and filter was confusing. Was the pump supposed to be above or below the waterline? Was it supposed to be making that humming noise?

At one point, just as she and other family members were getting frustrated, one person jeered, I can't figure it out, and there's no manual at all!

More people get frustrated assembling things on Christmas than on any other day of the entire year. It's a day manuals are both cursed and blessed. But in this scenario, no doubt the company that created the filter was unaware of the frustrated user stuck without a manual. We're often in the same position of ignorance about our users.

If you think about it, the technical writer is in an unusual role. Users hate the presence of manuals as much as they hate missing manuals. They despise lack of detail yet curse length. If no one reads the help, your position lacks value. If everyone reads the help, you're on a sinking ship. Ideally, you want the user interface to be simple enough not to need help. But the more you contribute to this user interface simplicity, the less you're needed.

Conclusion

As the year closes and the project manager is off skiing and the developers are playing video games and the quality assurance engineer is organizing his closet, I'm pounding out the last topics of a 200-page manual that I will soon deliver to a group of users who will smile and thank me for the manual, knowing they don't have to read it or critique it anymore, but can just put it proudly on their shelf, or maybe even in a storage box.

If I find out, through feedback or on-site visits or other means, that they don't ever read the manual, that they have never actually opened the manual beyond the table of contents, that's okay. I hope they never have to.