TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: user-centered design From:Chris Collins-Wooley <CWOOLEY -at- US -dot- ORACLE -dot- COM> Date:Tue, 9 Feb 1999 06:34:31 -0800
Kristin Zibell <kjzibell -at- US -dot- IBM -dot- COM> asked about user-centered design. The term comes, I believe, from a software design approach that requires that developers ask their users what they require to do a task, then incorporate the answers into the software. Ideally, they repeat the cycle two or more times. Many writers approach preparing their documents the same way. The approach predates software and product design in general. This is its latest manifestation.
Involving users at the start of a product cycle is what distinguishes this approach from next-bench design; a developer or writer builds a product that her or his neighbor in the next cubicle can understand, then sells it. Users influence this approach by buying a competitor's product, or by complaining. The developers or writers then roll fixes to the complaints into the next release. In the real world, I'd guess most software results from some proportion of each approach, and that software products in highly competitive markets are more likely to have put the horse before the cart.
If your company takes a user-centered approach, there's a good chance it includes documentation in its product cycle. It tests a product's documentation with the product. A formal user-centered environment usually has -- or contracts -- a usability lab. If your company runs usability tests on its products you should make sure it includes testing the documentation.
If not, you can incorporate user-centered design techniques to plan and construct your documents. In short:
>> Identify your audience: your user's needs, language, and environment.
>> Ask them what information they need, and when they need it.
>> Show them what you have to see if it works.
>> Rinse and repeat.
How do you go about it? I haven't come across a how-to book specifically for writers. It may be out there. But I can recommend Karen Schriver's 'Dynamics in document design,' which is the results of her marvelous career of discovering how to communicate effectively. It is a history of the origins of technical communications in general, and a description of a user-centered document design cycle in particular. Jeffrey Rubin's 'Handbook of Usability Testing' can help you prepare meaningful tests. I would also recommend Marlana Coe's 'Human Factors for Technical Communicators.'
HTH,
Chris
. . . . . . . . . . . . . . . . . . . . . .
Chris Collins-Wooley
Technical Writer
Oracle Pharmaceutical Applications
Waltham MA 02451 cwooley -at- us -dot- oracle -dot- com
Colorless green dreams sleep furiously -- Noam Chomsky
. . . . . . . . . . . . . . . . . . . . . .
