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.
Re: Technical writers and instructional designers: PART TWO OF THREE
Subject:Re: Technical writers and instructional designers: PART TWO OF THREE From:Nina Panzica <panin -at- MINDSPRING -dot- COM> Date:Mon, 8 Feb 1999 17:19:12 -0500
Part two of a three part message. Sorry for the lack of paragraph
breaks in the first installment--didn't realize my mail client would
strip those out with a cut-n-paste.
NP
Although any kind of training or classroom instruction experience that
you've had will help you some when getting a handle on timing and
presentation material, it's not easy to learn this quickly if you've
never trained in the field that you're writing about. The very best
thing for a transitioning technical-writer-to-instructional-designer
to do in this situation is to insist that she be allowed to sit in on
a course similar in length and related in subject matter to the course
that she is required to write. In my contracts to date, I've never
been afforded the luxury of doing this, but I've often thought of what
I'd do if I could be present in such a class. I'd take copious notes
about how long each segment or activity lasted, how much the trainer
used the written materials and how much she improvised or talked off
the top of her head, where the problems were, etc. I'd then use that
practical knowledge to structure the course I was writing.
I mentioned earlier that instructional-design writing has some
structural elements in it that are not present in "ordinary" technical
writing. This looks like a good place to list them. While not all
courseware has all of these elements, most use some combination of
them:
1. Preparation Notes: these appear only in the instructor's guide
version of the course and tell the trainer what he or she has to do
before the class starts to get ready for it. They frequently include a
list of materials or equipment, such as pens, paper, or PCs, needed,
background reading the trainer should do, or preparations for
simulations that must be made, etc.
2. Welcome (this can include a general introduction to the purpose of
the course, a getting acquainted activity, a short, scheduled "pep"
speech by the executive who's spearheading the training, housekeeping
activities such as passing around a sign-in sheet and explaining about
breaks and bathrooms, or other introductory elements.)
3. Course Review (this is called by as many names as there are
instructional designers, I imagine, but what it involves is some kind
of overview of the modules or sections of the course: on what days
(approx.) each will be taught, the contents of each, etc. This kind
of resembles the "In this Manual..." section you find at the front of
many user guides, but often the method of presentation is graphical:
some kind of chart or visual aide is used to display the days of the
course and the content within each day. If you work for an
instructional-design house, they're probably have their own format for
this. If you're on your own, you may need to invent one.
4. Overall Course Learning Objectives: A brief list of things that the
student should know or (better yet) be able to demonstrate at the end
of the class. There is some skill involved in writing these objectives
_and_ in making sure that they are met during the course. Many
training books cover this ground, however, so I won't go into it here,
except to say that these overall objectives should be somewhat general
and there should not be too many of them. (Speaking of training books,
at my local bookstore, Borders, the training books were not, as I
expected, in their pitifully small education section: instead, they're
scattered throughout the business section. More on books in a minute.)
5. Course Modules or Sections. Each of these is self-contained, and
is comprised of some of the following sub-elements:
A. Introduction to the module's subject matter and possibly a table of
contents
B. Module objectives
See #4, above--module objectives are much more specific than course
objectives.
C. Module activities
As with learning objectives, there is some skill involved in designing
activities. Activities can include reading some source materials,
performing an action on a computer under the instruction of the
trainer or the workbook, taking a tour of a facility, using equipment,
taking a test, or performing a "training exercise," just to name a
few. You will find plenty of models around for these latter--in
training books especially--but most of the models are junk,
empty-minded touchy-feelie pabulum that doesn't help the student grasp
anything substatial. I've found a couple of books that contain
training exercises that are worthwhile and that can be adapted to
courses where technical content is being taught which I'll list later
in this response, but basically what you need to do when designing a
training exercise is to create an activity that is fun or engaging or
will otherwise hold the adult students' interest while at the same
time demonstrating to them some concept, principle, or skill that
would be harder to learn just by reading or listening. Training
exercises themselves consist of typical course elements: an
introduction or description, the exercise objective(s) (usually one to
three), exercise instructions (one set for the trainer, one for the
students), the exercise itself, including any written materials or
forms needed by the trainees to complete it, and a "debriefing" after
the activity is complete--for these I often use provocative questions
designed to draw the trainees out about their experiences with the
exercise.
D. Explanatory material
This is content: stuff the students are expected to read or points
that the trainer should talk about, for instance. You usually do not
have to be as complete with content material as you do for traditional
technical documentation. For one thing, you are able to assume that
the trainer either knows something about the subject being taught or
is able to speak to it easily with brief "talking points" to keep him
on track. For another, it is seldom that in any class the trainees are
expected to learn _everything_ there is to know about a topic, and
thus the writer is never expected to be all inclusive. If you should
find yourself writing a reference-book sort of course (easy enough to
do if you're used to typical technical-writing assignments), try to
divide the content into three levels: beginning, medium, and advanced,
and put each kind of content in a separate course.