Readability/Usability/Quality 4-99 (December 1999) by Gabriele Bock

Is that User Centred Documentation?

Quality management is forcing technical communicators to meet the challenge of writing user centred documentation. Adequate preparatory work would be to categorize potential users according to experience, knowledge, tasks to be performed, and other use-relevant features. Users' requirements and requests should then be incorporated into the document's design.

However, some technical communicators still invest little effort and thought into user analysis. Particularly when writing for a technical audience, they claim to know exactly what kind of information users need. The reasons they give are:

• long experience in the technical communication profession ("We've always done it that way ..."),
• professional experience in the same (workshop) environment where the product is used, maintained, repaired ("I did the job myself ..."),
• same technical background and education as the users ("One of the first things they learn at school ..."),
• same use, maintenance, repair practice of the product as the user ("I am also a user of the product ..."), or
• the user group is too diversified ("How can I write for so many different people ...").

Although all these reasons are truly supportive for producing user-centred documentation, why do they not dispense user analysis?

 

Experience May Hamper a User-centred Approach

Professional experience in communication is important, but methods, tools, and processes change and need to be reviewed and improved from time to time. Technical communicators who are not familiar with the state of the art in technical communication give away the chance of making their professional lives easier by learning, for instance, how to realize user-centred documentation.

 

Experience Can be Outdated

Experience in construction, manufacturing or workshops aids understanding for the kind of information needed in a working environment. But as most things in life, professional practice changes with time. In many cases the communicator's experience is outdated and should be adjusted to the current situation by obtaining users' confirmation.

 

Education and Knowledge Levels Differ

Curricula differ from school to school, even more from country to country and continent to continent. Did you ever compare your own school knowledge to that of your colleague, provided you still recall it? The best trained service technician trying to repair a broken device under-piecework conditions is not very inclined to guess what common technical knowledge the documentation is referring to. He needs the information straight and in a simple, short, clear way!

 

Different Ways to Use the Product

Although the technical communicator's use of the product, and the way to maintain and repair it, may be similar to that of the user, it is rarely identical. For reasons the technical communicator can hardly ever anticipate, users do not always follow instructions: maybe

• the user does not read the instructions at all,
• the appropriate tools are not available,
• the user pursues goals the communicator never thought of, and
• inaccurate instructions allow more than one way of handling or repairing a device and so increase the damage risk.

User analysis enriches the experience of the technical communicator by providing information about user behavior, product handling, and documentation deficiencies.

 

User Group too Diversified

The least plausible argument for not doing user analysis is the diversified target group of the product. Of course, users have different capabilities and capacities. But for that very diversification you need to find out what information needs to be complied with, if you are to structure your information appropriately.

Diversification is not only relevant for communicators working for companies that operate on an international level. User groups with different levels of education and experience exist for products produced for international, national, regional, and local markets. This is a big challenge for technical communicators, especially if the localization budget is small or non-existent.

 

What is User-centred Documentation?

A technical communicator's job is to explain technology to people, not to describe technology for its own sake. None of us will produce successful user-centred documentation unless we first investigate and consider the users' information needs. When developing a user-centred document design, this is :

• "the practice of designing products so that users can perform required use, operation, service, and supportive tasks with a minimum of stress and maximum of efficiency." (Woodson, quoted in Rubin, J.: Handbook of Usability Testing, New York 1994; p. 10.)

Technical communicators who still are not convinced that user-centred documentation does require a switch in their documentation practice, might follow another track. Recently Tampere University in Finland offered an interesting seminar on technical communication. The title of the seminar suggested - probably unintentionally - a way for those who still think they know everything about their users: "Optimizing Users: What Do Real Users Want From Documentation?"

By purpose or not, you can read the first part of the title in two ways: Do you want users to optimize your documentation or do users themselves have to be optimized? What is your answer for your users?

"transline Deutschland - Übersetzungsdienst für technische Übersetzung"