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.
Rebecca Stevenson reports: <<Our group has recently taken
responsibility for developing and delivering training on our products,
something we have been lacking up until now. This is a great
opportunity and we're glad to have this happen; on the other hand,
resources are tight, and it's important that we do everything we can to
make the two efforts work together (the word "leverage" keeps being
used).>>
One very productive approach I've used in the past involves using the
trainer to teach the trainees how to use the documentation and
particularly the online help. You wouldn't believe how many people
don't know how to use either resource. (Insert rant #17 about declining
literacy and educational standards here.)
<<I'm brainstorming with myself on ways we can make this work. So far,
it all seems to be coming down to information sharing -- reviewing each
other's material where possible (we do peer reviews in our group),
keeping everyone in the loop when source documents are passed around,
sharing software when we can to make repurposing easier, having writers
attend the early training sessions to make sure feedback is cycled into
the docs.>>
In addition to this, enlist your trainers as indispensable sources of
feedback on problems with the software and the documentation. There's
nothing like trying to teach someone to reveal your own
misunderstandings and problems with the product--or the docs. If you
can, take the opportunity to attend the training sessions so you can
watch how people actually use the software; if you understand that,
then you can adapt your docs to suit that approach.
And examine the training material against the docs to see how the two
can complement each other. For example, the training can be "here's the
simple way to do X; see page Y of the docs for you other options",
whereas the documentation can clearly refer to training material (e.g.,
"for practice configuring the Bafflebag 1001, try out Chapter 1 of our
tutorial").
One interesting potential distinction between documentation and
training is that the former is referred to by those who have already
taken the latter. That highlights the difference between the two:
training provides basic competencies, whereas documentation provides a
refresher for those whose recall is weak, and a way to go beyond the
basics for those who have already mastered the basics. Remember the old
computer manuals that used to say "here's how to use Windows"? These
now largely assume that you've taken the training (formal, or "school
of hard knocks") to master the basic skills, and now build on those
skills rather than teaching them.
--Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)