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.
Kimberly McClintock wonders: <<Looking for experiential anecdotes
regarding capturing informal user feedback, and filtering it. Here’s
the situation: a Sales Engineer was supporting a customer as the
customer installed our product. The customer is at another site, the
SE is on-site here.>>
Based on your observations of this interaction, you may find an
opportunity to refine your documentation to better support the SE and
the customer, or perhaps to provide training for the SE in how to use
the existing documentation. (See comment below.)
<<They used our documentation and completed the install over the
phone. It’s a complicated and fragile process that involves getting
several supporting applications installed and configured. The docs
team wrote the documenation and tested it, it’s also been tested and
tweaked several times by internal staff.>>
Complicated and fragile processes need to be simplified and made more
robust. You can't solve those problems (bad design) through
documentation, and anyone who believes otherwise is a fool. I'm sure
you'll hear the argument "this is too complex to simplify", but
that's evidence of poor design skills and ignorance of user behavior
more often than evidence of a truly insoluble problem.
<<I could hear the SE on the phone with the guy at one point and
knew, based on the problems he was having, that the customer had not
read the critical ‘Before you Start’ section of the documenation. The
result was hours of frustration on the part of the SE>>
As noted above, training the SE on how to use the docs can solve this
problem. It's also possible that the "read this before you start"
information wasn't as clearly identified as you thought, since both
the customer and the SE appear to have missed it. Check your
assumptions at the door, and ask the SE (and the customer, if
possible) why they ignored this information. You may learn something
-- even if only that this particular combination of customer and SE
collectively amount to a single idjit. <g>
<<the SE brings up the docs and the issues he had and suddenly the
documentation is up for group critique.>>
Great! Take the opportunity to work with them and learn something. If
nothing else, you build a sense of cooperation, and you may even get
the opportunity to point out that a problem exists because the idjit
developers changed the software after the manuals had already been
printed and shipped to the customer. Don't turn this into a
fistfight, but do make it clear that not all problems are your fault.
And that working together rather than post-hoc bitching is most
likely to solve the problem.
<<I want to put a process in place for capturing the information, and
teach myself and my colleagues how to evaluate & filter useful from
not-so-useful feedback.>>
My definition of useful feedback: It clearly and objectively
identifies a problem that I can solve. Anything else may be
interesting, but it's not useful.
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
Coming soon: _Effective onscreen editing_ (http://www.geoff-hart.com/
home/onscreen-book.htm)
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
