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:Using customer feedback (was: Advice?) From:"Bob Stromberg, MVS/JES Information Development" <stromberg -at- VNET -dot- IBM -dot- COM> Date:Thu, 26 May 1994 12:55:03 EDT
>So now it comes down to rewriting our software manual, now that we at leas
>got it out the door.
Wonderful idea! In 14 years in the business, I've found that my
understanding of what users want from a piece of documentation
improves all thru the development process, and beyond.
>Since I'm new at this, I wouldn't mind a little advice on going about this
>task. How we determine what's important, what's missing, how to organize,
>stuff like that.
Please consider engaging your users in some kind of dialog. This
can be especially helpful if you receive some feedback that other
users might not agree with, or if you have too much to do, and
have to be selective about proposed improvements.
You might be able to "listen in" to ongoing dialogs that your
customers have in with your Technical Support folks. Or there
might be a product-related newsgroup. Look into newsgroups
dealing with the problems or tasks that your product addresses.
For example, I work on IBM's MVS/ESA operating system
documentation. I follow the IBM-MAIN discussion list. I also
follow the OPERS-L discussion list, because "operations" is one
of the task areas that our documentation addresses.
I work up an understanding of documentation deficiencies, and
proposed corrective actions, then I try to figure out which
corrections to make. Some are quick and easy. Some are harder
to accomplish. Sometimes a problem in the doc causes a user to
fail in accomplishing a task, or to damage the user's data or
business processes. I consider such problems to be more
significant than weaknesses that are merely puzzling, but can be
Be aware of potential problems caused by raising user's
expectations. If ever you promise a user that you will correct
a problem, it's a Real Good Thing to follow through.
I think it's OK to tell someone that you'll work on a problem,
letting them know that the outcome is a bit uncertain. But don't
leave them hanging if their own work depends on the information.
Make sure your response provides that user with the clarification
or correction. After all, when users give you feedback,
they are performing an act of altruism!
There's a lot to say on this topic. I could write all afternoon.
BUT...I'm working on corrections to the latest MVS/ESA Planning:
Installation and Migration book, and I've got to go back and look
over some comments received from an IBMr who was working up a
presentation on migrating to MVS/ESA SP 5.1....
Bob Stromberg, MVS/JES Information Development, IBM Corporation
Phone: (914) 296-6158 or IBM tie-line 8/296-6158
IBM Mail: USIB2FZL Internet: stromberg -at- vnet -dot- ibm -dot- com