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.
Make it as easy as humanly possible for a customer to give feedback
while they're using the docs. For PDFs, enable commenting. For
browser-based help, add a mailto link at the bottom of every topic
that prefills the topic file name. For printed manuals I'd seriously
consider getting some stickers made up with labels such as [ X ] (this
information looks wrong) and [ ? ] (I don't understand this/I have a
question about this). Collect the manual at the end of the beta
exercise and go through each tagged instance with the customer by
Skype or phone call.
Your goal is to minimize the overhead for a customer to give you a
snippet of useful information. If they have even a fleeting thought
that a sentence is wrong or confusing, ideally it should take no more
than a few seconds to record that via their copy of the manual.
I agree with Sion that site visits are invaluable ("as much in terms
of helping you understand them and how they work as much as
anything"--YES squared). I haven't done many but, with two exceptions,
I always learned something useful and unexpected.
Those exceptions were when I introduced myself with 'I'm the technical
writer.' This was like saying, "The manuals are my baby. Tell me
what's wrong with my baby. Is it ugly?" I got nothing. The baby was
fine. After that, I'd start with, "I've been asked to find out where
the manuals could be improved." After that, I'd get real feedback, not
always comfortable but always useful.
My theory is that most people are basically nice and they want to
help. In the first case they think they're helping by sparing me the
bad news about my hideous offspring. In the second case they're being
nice by helping me do that job I've been given
Finally, it's important to be specific. People rarely read the whole
manual so don't ask for feedback on the whole manual. Ask about a
specific recent task, for example to do with installing or upgrading
the beta software or trying out one of the new features or
troubleshooting when something went wrong. And keep digging. When a
customer says, "The documentation isn't detailed enough" management
often thinks the solution is to double the page count or to add a lot
of baby-step detail about how to click things in the UI. In my
experience, "not enough detail" means "I couldn't find the answer to
my very specific question X." So adding a thousand factual sentences
is an expensive waste of your time if it still wouldn't have helped
that customer with question X. Ask that customer for examples of where
detail was lacking.
Hope this helps.
--- Stuart
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn more about Adobe Technical Communication Suite (2015 Release) | http://bit.ly/1FR7zNW
