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.
I've certainly heard these sort of audience-centric strategies before.
Essentially, as I see it, it's just getting user input all the way through
instead of the end. My question is: how do you actually get any genuine,
valuable user input at any point in the process.
In our industry (construction/project management) nobody is going sit down
with us for any length of time to discuss the documentation! We have
difficulty getting feedback on the program, let alone the manuals. If Adobe
called me up and asked me to comment on their FrameMaker manuals, I would,
but only because I happen to be a technical writer. Our average end-user a)
doesn't care very much about the manuals and b) cares even less to tell us
how they feel about them.
Short of paying them, I don't know how I'd get users' help in actually
developing our documents. I'm open to suggestions. DB.
-----Original Message-----
From: PHILA -at- Mail -dot- VIPS -dot- com [mailto:PHILA -at- Mail -dot- VIPS -dot- com]
Sent: Wednesday, December 15, 1999 8:51 AM
To: TECHWR-L
Subject: Involving Users in Doc. Design?
<snip>
So what is the alternative? Designing documentation in close contact with
the people who will use it. Actually asking the users what they need from
the documentation. Writers should go out to client sites and observe and
analyze the customers' workflow, then structure the documentation based on
the customers' specific questions, work patterns and business needs. The
primary question should not be "How does this work?" to the developers, but
"Tell me what you do, what your problems are," to the customer.
...........................................
We're experimenting with this approach in our new document design process;
given the nature of our product and our documentation, it seems to be an
ideal match. I'd like to hear whether other writers have tried this, and if
so, what were the results?
