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:User feedback? (was 5 users in a room), Take II From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, "Nuckols, Kenneth M" <Kenneth -dot- Nuckols -at- mybrighthouse -dot- com> Date:Tue, 14 Nov 2006 10:42:32 -0500
Kenneth Nuckols wondered: <<We're aware of the pitiful response rate
Geoff speaks of when it comes to a low response rate, even among
internal customers, and 61 of the 62 projects I've completed or am
working on for this year have been sponsored by and are written for
an internal audience.>>
In theory, that's a golden opportunity. In practice... people are
people and need a reason to abandon their own work, however briefly,
to do you a favor.
<<it's easy to get annoyed with the sponsors and SMEs who respond to
our requests to review a draft five minutes after it hits their inbox
with the inevitable "Looks great!">>
For technical reviews, the manager has to make the reviewers
responsible for their work. There's no other way to reliably obtain
good reviews. If the manager doubts the seriousness of the problem,
try leaving a howling error in the middle of the docs, where even a
casual reader will find it--if nobody reports the error, you've got
all the proof you need that they're not doing their jobs. Of course,
the risk of this approach is that it's appallingly easy to
inadvertently leave the error in the document, so if you try this,
you need to ensure that at least two people add a note to their "to
do" list to remove the error later.
Note that the "hits their inbox" in your message is a clue: work that
arrives unannounced and anonymously (in which category I include e-
mail) on someone's desk gets treated just like the rest of the spam.
Try speaking to each reviewer in person, asking how they want to
receive the document (e-mail vs. print, the whole document vs. one
chapter per day), asking when is most convenient for them and what
deadline they feel is reasonable, and ask them for a commitment to do
the work. That's not just theory, by the way; I implemented this
approach at a former employer for external review (i.e., by people I
had no authority over) and it worked brilliantly.
<<Should I expect that making time to sit down with project sponsors
and document users will give me any better feedback than a form?
Everyone's busy, and the way this company has operated without
technical writers for so long (our department is only 2 years old) I
still think the majority of people don't quite know what to make of
us or how we can (should, ought to, ideally) be helpful to their
department within the organization.>>
Yes, you should expect better results, but not without a bit of work
and a bit of luck. Because this becomes a dialogue, you can apply all
your human interaction skills to establish a relationship (possibly
even a friendship), find out what the other person needs before they
can do the review for you, and meet those needs. For example, I've
had reviewers who only wanted a printout, and others who wanted me to
sit in their office and discuss the manuscript: different strokes for
different folks, and you can't use the wrong approach and expect to
succeed.
You can also make it clear "what's in it for me?" when you talk to
them; that's easier if their manager supports this process (i.e.,
they get a raise if they catch all the errors), but you can often
give them a good reason that's less mercenary. The best reason of all
is that you've already developed a relationship with them in which
they know who you are, and have something to talk to you about other
than work; since you're a friend who has demonstrated clear concern
for their needs, they feel a certain obligation to help you that they
won't feel towards a complete stranger.
Of course, you can't always establish these relationships in the
workplace, in which case you need to figure out (for each person) the
"what's in it for me?" answer. That's harder to identify, but
sometimes it pays back 100-fold. I once helped a developer figure out
an effective interface, saving him possibly a day of screwing around
with the interface designer, and he greatly appreciated that time
saving. Subsequent interactions were easy and friendly.
<<In the mean time, if anyone has any gems of wisdom on how to nudge
these meetings with sponsors and users to be the most productive (and
maybe warnings about what not to say or do) I'd be most appreciative.>>
Have a look at my other articles (search http://www.geoff-hart.com/
resources/bibliography.html using the keyword "review" to turn up
likely candidates, or just browse the titles). Getting people to work
with you is always more art than science, but some "tricks" work well
in a wide enough range of situations to be worthy of consideration.
Even the ones that don't work outright often leave an opening for
dialogue, or reveal clues as to other fruitful approaches.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
