Â鶹´«Ã½

From David Fenton

Emma Young’s article says that software manuals rely solely on information from the computer programmers who write the software (22 February, p 19). This is not entirely true. Technical documentation is developed in two basic ways. One is somewhat similar to what your article describes: the developers hand over a functional specification to a technical writer to turn into a user manual.

But the second, arguably more important, way of developing software documentation was missing from the article. This is where the technical communicator becomes a “user advocate”: he or she learns the application intimately, and finds out as much as they can about what customers are going to be trying to do with it, and then writes the manual to help users do what they want to do.

The mindset of these technical communicators is similar to that of the best teachers and trainers, for that is in reality what they are. At each step of the documentation process they try to imagine what a user wants to know and do next – and then give it to them. They have to be writers, teachers, trainers and creators, and their work often leads them into improving the usability of the systems with which they work.

The software tool being developed by the CSIRO could be of great assistance to such a “user advocate”. It certainly wouldn’t threaten their jobs.

Software that records the history of a typical user’s actions can never tell you where that user will want to go next, what they’ll be trying to create, or how they’ll want to stretch the bounds of the software – as they always do. Only a talented human being who knows the software, the hardware and the needs of the users can do that.

Toronto, Canada