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:skills for non-writers From:Miki Magyar <MDM0857 -at- MCDATA -dot- COM> Date:Mon, 29 Jul 1996 09:01:18 -0600
Elizabeth Boling asked, "If you were coaching people who were not
professional tech writers through the preparation of materials for
distribution to their peers, what would you consider to be the minimum
skills that person would have to develop?"
Good question! I've had occasion to work with non-writers on several
occasions: helping production line workers document their procedures
for ISO 9000, teaching consulting engineers how to improve their
reports, and working with product development engineers to simplify the
process of documenting the product (command sets). I have also taught
a tech writing course to people who were there only because they had
to take it to graduate.
The most effective approach I have found for this audience is to take
advantage of their speaking skills. I tell them to think of the writing as if it
were a conversation they were having, in which they answer the
questions the other person is asking. Since they have all been in this
situation, and feel comfortable talking about their skills and information,
this is easy for them to imagine. Then what remains is to write down the
questions, have them TELL me the answers, then write down what they
just said. A few times through this process and they are able to come up
with pretty decent first drafts. Whenever possible, I get them to buddy up
with someone who doesn't know their area, and do a cross-check on
each other's work.
This does not eliminate the need for a competent technical writer/editor,
but it certainly minimizes the work, makes the people doing it feel good
about what they're doing, and shortens the whole process.
If you have the time, it is also very effective to use examples of excellent
and awful material to help them learn how to see and specify the
characteristics of each. From this, they can develop their own checklist
to improve their work. Before and after type examples work well for this.
For things like the assembly procedures and command set descriptions, I
gave them a template to fill in the blanks, with examples of what a 'good'
one looks like.
Hope this helps -
mikim -at- mcdata -dot- com
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-