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:At what point can I pass the buck? From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, David Downing <david -dot- downing -at- Fiserv -dot- com> Date:Wed, 18 Mar 2009 09:52:51 -0400
David Downing wondered: <<For awhile now, I've had some coworkers come
to me with questions about our product, some of which seem like they
should have been taken directly to an SME. In fact, I ended up passing
some of the questions on to an SME. On the other hand, as the person
who documents the product, maybe I should be able to answer some of
these questions.>>
The "always" point to pass the buck: when you don't know the answer.
The "sometimes" point to pass the buck: when an endless stream of
colleagues nagging the SMEs about the incomprehensibility of a
particular interface feature will prove to the SMEs that it's not just
you, and that everyone has the same problem with their looney-tunes
design. The "never" point to pass the buck: when watching how people
interact with the product (i.e., what they do and don't understand)
gives you insights into how to design your documentation to improve
that interaction.
Personally, I was always flattered when colleagues came to ask me
about a product: it meant that they respected my opinion and found my
continued existence useful. That gave me a chance to develop some
productive working relationships with these people, both because doing
so made life at work more pleasant and because many of them could help
me in return when I need a future favor.
<<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?>>
See above. To me, the ideal approach is to combine the always,
sometimes, and never: help the people to the extent of your abilities,
document their problems (names and details) so that you have
statistics you can use to motivate the developers to change something
ineffective, and send the colleagues on to the developers (if
appropriate) so that the developers receive ongoing feedback about
problems with their design and you're not the only one complaining.
Then figure out how to help solve the problem and take that to the
developers so you become their ally, not the annoying nagging voice
they learn to dread.
------------------------------------------------------------------------
Geoff Hart (www.geoff-hart.com)
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
------------------------------------------------------------------------
Effective Onscreen Editing: http://www.geoff-hart.com/books/eoe/onscreen-book.htm
------------------------------------------------------------------------
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-
