RE: Field testing manuals

Subject: RE: Field testing manuals
From: "Stuart Burnfield" <slb -at- westnet -dot- com -dot- au>
To: "Techwr-l" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 11 Sep 2015 13:48:14 +0800

Hi Megan,

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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives


Follow-Ups:

Previous by Author: Re: How do enterprise software companies offer help?
Next by Author: Re: Must documentation always follow the UI?
Previous by Thread: RE: Field testing manuals
Next by Thread: Re: Field testing manuals


What this post helpful? Share it with friends and colleagues:


Sponsored Ads