We technical writers have a mantra that we mutter quietly whenever someone asks an “obvious” question about our software: “RTFM.”
But though reading the (ahem) “fine” manual would often solve their problem -assuming they 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 on to read our manuals.
A large part of the problem is that nobody has time to read anymore. When I first wrote about this back in the late 1980s, I used the journal Forestry Abstracts as a barometer for how fast information is being produced. Forestry Abstracts publishes summaries of most articles that appear in forestry journals from around the world. In the 40 years from 1945 to1985, the number of articles published increased almost fourfold (to 7,150, up from 1,840).
That’s slow compared with Moore’s law, but even so, the number of articles being published doubles every 20 years, a rate that’s shown no signs of slowing; on the contrary, it seems to be accelerating, even if we don’t count the enormous growth of the Web. For broader fields, such as biology as a whole, the numbers become truly staggering.
How staggering? If you could read and fully understand an average journal article in 30 minutes, and had eight 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 read for more than 400 days per year.
In the absence of considerably longer years, and no real work to do 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), 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 priorities for most of us.
If nobody has time to read our manuals, then how can we teach people to use our software? Increasingly, the solution has been to put the instructions on-line, but that misses the point; moving the documentation on-line is even less helpful than printing it, since most people consider “on-line help” an oxymoron. The real solution is to look beyond conventional thinking (“Write a manual!”) by making the interface itself sufficiently intuitive to reduce or even eliminate the need for manuals.
But to do that, we have to work with the software’s users to understand how they approach their daily problems and how we can create an interface that solves those problems.
Why don’t we do this more? In part, it’s easy to forget that we write software to help users do their jobs, not to meet Marketing’s production deadlines or to keep ourselves gainfully employed, and certainly not to show how clever we are at creating algorithms. Plus, we’ve got our own problems and no time to solve them by reading the fine manual, so it’s much easier just to ask a writer to fix the resulting interface problems by writing those manuals nobody reads.
Which brings me full circle. It’s long past time we started making the software itself helpful by creating what the usability experts call “electronic performance-support systems,” software designed so that it helps 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 our clients and find out the problems they’re facing so we can begin solving them. That takes time, but it’s the only way to get the job done right.
Hart (geoff-h@mtl.feric.ca) is a translator, technical writer, editor and a senior member of the Society for Technical Communication. He lives in Pointe-Claire, Que., where he works for a forestry research institute.
