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: Help w/TW skills From:Karen Gwynn/Datatel <Karen_Gwynn -at- DATATEL -dot- COM> Date:Thu, 1 Feb 1996 15:09:10 EDT
Wow! If you could pull this off, it would be wonderful! A life-like "case
study" would be great, but for the trainer, it would be a lot of work to put
together. Someone mentioned having the tech writing students work with the
engineer students. That might be a little easier to do (from an administrative
point of view) while benefiting two camps: the writers and the engineers (or
programmers, or scientists, or whomever).
And as I'm writing this, I think I like the idea even more than just the
exercise described below. First of all, you, the instructor, wouldn't have to
do as much work getting the scenario and supporting materials put together.
Second, the writers would have a real life engineer (programmer/scientist,
etc.) to work with, thus teaching them not only real interviewing techniques,
but working with the "type" of people who they will ultimately be working with.
And third, what a wonderful opportunity for the engineer/programmer/scientist
to learn what it will be like for them to have this annoying little doc person
asking them questions and scrutinizing their specs! (FYI, I pride myself on
being one of those annoying little doc people who ask a lot of questions and
get on the programmers nerves when they write insufficient specs!)
well, just my thoughts for this afternoon (I'm in a work avoidance mode right
kwg -at- datatel -dot- com
I did some more thinking about your training situation and had some ideas.
How about having students do a pseudo-real-world project on a "frammis" and
follow the documentation process all the way through. The "frammis" could
be anything you like - I would suggest a real thing, but something that most
people don't know a lot about.
The project would involve students attending a typical project kick-off
meeting, followed by some research on the frammis at the library to develop
a basic understanding of similar products. Then you could have students
develop a documentation plan for a "User Guide" and begin interviewing SMEs.
Perhaps some folks from your local STC chapter could volunteer to act as
SMEs - some could be helpful, some could be as much fun to interview as
having your teeth pulled! [We've all been there! ;-) ] I would try to
give them a lesson or two on interviewing techniques before throwing them to
You could have some "development specs" as well, so students learn to
synthesize written as well as oral material. I'd establish due dates for
drafts, and have the drafts reviewed by the volunteer SMEs. You could also
invite an editor to edit the drafts and then speak to the class about why
she/he made specific changes.
Then comes the rewrite to final phase. I would try to have new
functionality added to the frammis at this stage, so they get a feel for
integrating new material. I would use the students themselves as peer
editors and have your volunteer editor review the edits and speak to the
class again to reinforce these points.
There are various opportunities for grading throughout this process with the
final grade being the completed document.
Let me know what you think! (As I'm sure *everybody* on this list will!!!!)
kcramer -at- ncslink -dot- com