Why Don’t People Read the Documentation?

It looks like this is turning into a train blog. This time I'm sitting in the train back from Salzburg, Austria, where I visited an uncle who makes flight simulators and also supports them. He told me how customers don't read the documentation he wrote, but instead call him whenever they have trouble operating his equipment. That seems to be a universal problem for technical writers: customers don't bother to consult the help files or printed documentation, then complain if the equipment doesn't work the way they think it should work. They think, for example, that a specific action should be triggered by a particular button. When that button doesn't perform the action they expect, they call the customer service desk rather than consulting the documentation about the correct button to press.

On the other hand, how often have you and I attempted to decipher badly written, badly organized and/or badly translated documentation for some device we bought? Small wonder that customers give up on even trying to consult documentation after they have encountered a few such texts that were written in programmer speak, contained factual errors or were translated into garbled English. If customers are to get into the habit of consulting help files or booklets, they must consistently encounter files or booklets that actually help them solve problems with the devices they handle.

This, in turn, means that the documentation -- in whatever form -- must not only be accurate and well written, but also well-organized, with a device's particular audience in mind. A cell phone intended for senior citizens, for example, needs to be accompanied by an extensive printed booklet illustrating each step with large screen shots. A software developer kit that lets programmers write code for a certain computer platform, on the other hand, requires only very specific online information and can include acronyms and IT terminology.

While technical writers need to keep their audience in mind when writing the source text, we translators all too often forget -- or never know -- who might be reading our document. Just as the original writer's word choices depend on the target audience, so do ours. Sometimes we can glean from the source document who the likely readers might be, as in the examples cited above. But if that is not obvious and the client didn't tell us, we should ask. No need for extensive audience analysis, but the answer to "Will this document be provided to the consumer or to the technician servicing the device?" or a similar question should provide enough information so that we can gear our choice of vocabulary and sentence structure towards the target audience.

If we consistently ask this question, agencies and end clients will get into the habit of providing that information with the project. This will (hopefully) result in documentation that is useful to the end consumer, leading to them actually reading the documentation.