---
title: "If No One Reads the Manual, That’s Okay"
date: 2009-12-27
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2009/12/27/if-no-one-reads-the-manual-thats-okay/
---
# If No One Reads the Manual, That’s Okay
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](http://charleshurwitz.wordpress.com/2009/11/12/its-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](http://news.bbc.co.uk/2/hi/technology/8346810.stm)).

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](http://xprogramming.com/xpmag/manualsInXp)).

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](http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html))

When I [interviewed Mike Hughes](https://idratherbewriting.com/2009/01/31/podcast-make-your-help-indispensable-safeguard-your-job/) 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?](http://www.cherryleaf.com/artice_whybother.htm))

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.