Nobody reads manuals, do they?

by Geoff Hart

Previously published as: Hart, G. J. 2001. Nobody reads manuals, do they? http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_nobodyreads.html

We technical writers have a mantra that we mutter quietly whenever someone asks an obvious question about how to use our software: “RTFM”. But though reading the (ahem) “fine” manual would often solve the problem—assuming the purchaser actually received one of those increasingly rare printed manuals with their software—only technical writers seeking inspiration on how to do their own jobs better can be relied upon to read product documentation. To make matters worse, many of us admit that we’d rather play with a product, hoping to figure out what to do, than use the documentation.

A large part of the problem is that nobody has time to read anymore, and not just because life is getting faster and more demanding at a furious pace during the Internet age. When I first wrote on this topic back in the late 1980s, I used the journal Forestry Abstracts as a barometer for how fast information was being produced. Forestry Abstracts publishes summaries of the articles that appear in most forestry journals from around the world. In the 40 years from 1945 to 1985, the number of articles published increased almost fourfold (to 7150, up from 1840). That’s slow compared with Moore’s law, which predicts that microprocessor power (as measured by the number of transistors on a chip) doubles in less than 2 years, but if the number of articles being published in a field as small as forestry doubles every 20 years, the numbers still get huge very fast. To add to the problem, that rate shows no signs of slowing; on the contrary, it seems to be accelerating, even if we ignore the enormous growth of material published on the Web. For broader fields such as biology as a whole, or physics, or chemistry, the numbers become truly staggering.

How staggering? If you could read and fully understand an average journal article in 30 minutes, and had 8 hours per day in which to do nothing but read, then remaining completely up to date on forestry in 1985 would have required you to do nothing else but read for more than 400 days per year—which poses something of a problem given that the average year is considerably shorter than this. Nobody would ever try to read everything published in a field, so let’s consider more realistic numbers: if you read only the abstracts published in 1985, and took about 5 minutes to read and absorb each one, you’d be reading for close to 2 hours every day, for the rest of your life—and that's assuming the volume of information doesn't increase. Which it will.. I don’t even want to think about what this would amount to in 2001, with nearly enough time elapsed since 1985 for another 20-year doubling to have occurred.

In the absence of considerably longer years, and no real work to do or life to live during those longer years, it’s obvious that nobody can read it all. Given how many other things we’d rather read (e.g., novels) or watch (e.g., TV) or hear (e.g., the latest Smashmouth CD), each of us has to be very picky indeed about what we read. Unfortunately, software documentation ranks right up there with the tax code on the list of reading priorities for most of us.

If nobody has time to read the manuals we produce, then how can we teach people to use our software? Increasingly, the solution has been to put the instructions online in the form of “help”, but that actually misses the point; moving documentation online is even less useful than printing it, since most people outside the technical communication community seem to consider online help an oxymoron. For that matter, there are days when I have a lot of sympathy for that position.

So the real solution is to look beyond old-fashioned thinking (“write a manual!”) and conventional thinking (“write online help!”) by making the interface itself sufficiently intuitive that it reduces or even eliminates the need for documentation. To do that, we have to work with the software’s users to understand how they approach their daily problems and thus, how we can create an interface that solves those problems.

Why don’t we do this more? In part, it’s because we’ve come to believe that we write documentation to help users do their jobs—not simply so that we can meet Marketing’s production deadlines or keep ourselves gainfully employed. That sounds perfectly reasonable, but like all seemingly logical statements it only makes sense if the underlying assumptions are sound, and in this case, they’re not. In fact, we write documentation because product developers often forget it’s their job to create products people can use to get their own jobs done. Some product developers seem particularly forgetful in their quest to show how clever they are at creating algorithms or fitting 130 horses under the hood of a compact car; others really do recognize the need to create usable products, but in the face of deadlines and corporate goals that would feel completely at home in a Dilbert comic, have no time to do much more than keep up with the workload. In the end, it’s often much easier just to ask a writer to fix the resulting usability problems by writing those manuals that we’ve agreed nobody reads.

Which brings me full circle. It’s long past time we started making our products helpful by creating what the usability experts call “electronic performance-support systems” or what psychologist Jef Raskin calls “the humane interface”. In short, we need to produce products that help people do their work rather than making them change the way they work to follow our preconceptions. And the only way this is going to happen is if we make time to listen to the users of our products, find out the problems they’re facing so we can begin solving them, and seduce or browbeat the developers into incorporating what we’ve learned in their designs. Every time I grapple with a difficult or incomprehensible product, I grow increasingly convinced that we’re the only ones with the empathy and communication skills to do the job right. Isn’t it about time we started trying?