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:Effective mechanism to gather end-user feedback? From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, Laura Chris <tw_asks_u -at- postinbox -dot- com> Date:Wed, 18 Jan 2006 10:40:04 -0500
Laura Chris wondered: <<I work as a writer with a product-based
company. As my documents are targetted at the end users, I believe that
direct feedback from them would be the best way to improve the
direction of writing and the quality of our documents.>>
Indeed, that's the best way. Of course, you have to ask the right
people. Microsoft screwed up revision tracking in the past two versions
of Word because they asked "general" users (who don't often use these
tools) rather than editors how to improve the tools.
<<In our company most of the customer calls reach the help desk and I
see the big bosses complaining about increase in support costs during
the reviews. If my stars are aligned correctly, I get to know what the
exact problem was, otherwise the requirement comes as an enhancement
request for the documentation with no trace about the history of the
problem. >>
If they're serious about decreasing support costs, then you can make a
strong business case for change. Point out that the best way to reduce
these costs* is to work directly with the help desk to find out details
of the problems. Ideally, this should be full-blown, in-person
cooperation, but at a minimum, you should have read-only access to the
support database or should be cc'ed in all e-mails.
* Actually, the best way is any of the several flavors of user-centered
design: design software to work the way users expect it to work and
need it to work, and a lot of your support costs disappear. Of course,
trying to persuade certain managers of this self-evident logic is like
beating your head against a brick wall: it feels so good when you stop.
If you can understand a problem, you can solve it; if not, you're just
guessing at a solution, and waiting for the support calls to roll in is
an awfully expensive way to find out whether you guessed right.
<<There was an instance where a user was not able to locate the
installation details in an installation manual and the request came as
a documentation enhancement request for the next release of the
product. I do not have the luxury to try out the product installation
as there is always a shortage of systems and most of the times I have
to go by the developer's words.>>
Sympathies. I had the same situation at a former employer; they'd
locked down all the systems so tight that I couldn't even customize my
Start menu, let alone install the software I was supposed to be
documenting. I'd write stories about this kind of thing, but nobody
would buy them--as fiction. Point out to your managers that the
developers aren't doing their jobs right--otherwise there'd be no
problems, right?--and that the only way to document installation is for
you to install the software. Duh!
<<We have a very inviting line such as "Send your comments about this
user manual to the following e-mail address:, in our support site but
have not found any takers for this so far over the years!>>
That's typical. The response rate to reader surveys is often below
1%--and often far, far below that rate. Most people figure it's not
worth the bother. However, I love the approach built into Apple's
Safari browser: right under the main menu, there's a "report bugs to
Apple" choice. I've used it several times to send them URLs that didn't
work properly. Why not propose a similar feature?
And add instructions on how to use that feature on the first page of
the online Help system, and as an option in any help window that
doesn't help: "Click here to report a bug or problem with the
documentation." That is, make sure people can't miss it. If possible,
provide direct feedback: "Yes, we'll add that to the docs during the
next release. Thanks!" or "I've submitted your request to the design
team. No promises, but with luck we'll get it into the next version."
<<At present, I have user forums and chat as options in mind, but we as
writers are not supposed to contact the customers directly.>>
Forums are a great and underutilized resource, but they have certain
issues. For one, I imagine there are issues of legal liability if you
don't moderate the forum and a flame war gets out of hand--or if a
self-appointed expert provides bad advice that really screws up
someone's system. Plus, there's that fear that people will tell you
what they really think about your product. <g>
Why not do a bit of searching on the Web to see if there are any
communities that already exist for users of your product? If so, join
up. Make it clear that you don't represent your company, but that
you're happy to listen and ask questions and learn. If your managers
are so stupid that they want to shield users from the very people who
can help them (a common attitude for some reason), ask permission first
so you don't get into trouble if you're discovered. So long as you're
clear that you won't be associating yourself with the company in any
way*, they should be willing to look the other way.
* You don't want to be a sock puppet, of course. Just make it clear
that even though you work for the company, you in no way act as their
official representative to the world.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
