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: Research interviewing tips From:Beth Agnew <bagnew -at- INSYSTEMS -dot- COM> Date:Tue, 25 Nov 1997 13:33:01 -0500
Hope D. Cascio wrote:
> walk around, chat, fiddle with the whatsit you're documenting, then make
your best try at
> documenting it. Then, hand your best try over to someone who knows the
whatsit
> inside out, and let him/her tear it up. Most people are much better at
telling
> you what's wrong or missing than what's right or what needs to be
included.
This is true, however I'd like to add a word of caution. Such a procedure
could inadvertently result in you being perceived as "not technical enough"
or worse, incompetent. As technical writers, we not only have to deal with
highly technical and complex material, but often with experts whose
overdeveloped egos blind them to their own responsibility to communicate
technical information. I've worked with developers who think that it's a
game of "see how long it takes the writer to get the information" (and its
variation: "see how long it takes the writer to figure out the information
I gave is wrong"). We're already hampered by the commonly-held belief among
most of our experts that they could write it better if they had time ...
blah blah blah. Hands up all those who have had a carefully crafted
document ruined by someone who "thought" s/he was a technical editor?
Hope does say to do the best job you can to get the information you need,
then use that for your document. I agree. If you've done that, you've
probably come very close to covering all of the information necessary. A
trusted technical reviewer at that point can do much to improve the final
product.
What I'd like to see, and what we're trying to do here, is institute a
process for providing technical information. Managers have to learn to
allocate developers' and experts' time to working with a technical writer,
or to documenting their work themselves. Experts have to be educated to the
need for keeping that informal documentation. Companies should recognize
technical knowledge and information as business assets and handle them
accordingly. This is the knowledge age -- but the knowledge is no good
unless you can capture it and disseminate it in a form that others can
access.
--Beth
Beth Agnew
Senior Technical Writer, InSystems Technologies Inc.
65 Allstate Parkway, Suite 100 Tel: (905) 513-1400 ext. 280
Markham, Ontario, Canada L3R 9X1 Fax: (905) 513-1419 mailto:bagnew -at- insystems -dot- com Visit us at: http://www.insystems.com