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:Re: At what point can I pass the buck? From:Fox Cole <foxcole -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 19 Mar 2009 11:19:22 -0500
David Downing wrote:
> Obviously, questions that deal specifically with clarifying
> something in the documentation are my responsibility -- e.g., "On p.
> 34, you have a statement that's ambiguous. Did you mean A or B?"
> But some of the questions I'm getting are on the order of, "The
> documentation says it's supposed to work this way, but that
> contradicts what's happening when the client tries to do such-and-
> such. Is the product misbehaving, is the documentation wrong, or am
> I misreading the documentation?"
>
> Of course, if the documentation is inaccurate or ambiguous, I need
> to know that, but to what extent is it my responsibility to explain
> why the product is (possibly) behaving in an anomalous fashion. At
> what point am I justified in passing the buck to the SME?
Like you, I always listen to questions people are asking (and request that
tech support send me any questions they've logged on products I've
documented) for two reasons: to learn whether my documentation has failed,
and to learn what more the users need to know.
However, I am not the product designer or developer or support expert. I'm
not using the product every day, so even though I have delved into it and
worked with it hands-on and become intimate with it, I'm neither qualified
nor authorized to answer questions about its use, except where documentation
is concerned.
It's also happened before that the product changed or some new or different
functionality was introduced after the documented release, but no one
thought to notify me to update the documentation. I wouldn't want to be
passing along wrong information or guessing about why something didn't work
as expected, and my employer would certainly not be amused if I did.
I'd address anything directly related to the documentation, then take the
asker to the appropriate support person and participate in their
question-and-answer meeting. (I realize this isn't an option for everyone.)
Sometimes I come away with a project to document some new functionality.
Sometimes I come away with a better understanding of the user's needs and
can set up a task to improve the documentation with the next release.
Sometimes the issue has nothing to do with documentation but with an error
in data or in backend processing. In any case, I know I've done my best to
fulfill my role responsibly, not overstep it, yet help the person get the
information they need from the proper source.
Cheers!
---Fox
If the world were a logical place, men would ride side saddle. -- Rita Mae
Brown
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
