Differences between training guide vs user's guide?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Daniel Ng wondered: <<My team and I are beginning to start work on a 
training guide. They have already started working on their individual 
topics in Chinese based on the English template which I created. I will 
be working alone in ENglish for now.>>

Off topic, but of interest to me and possibly others: I've been told by 
several Chinese colleagues that Chinese readers are now so accustomed 
to English rhetorical styles and instructional approaches in user 
manuals that they simply accept the English approach rather than 
requiring or preferring a fully localized version that takes advantage 
of Chinese rhetorical and pedagogical approaches. How true is this in 
your experience? How would you describe these differences? (Private 
reply would be fine.)

On to your actual question: <<Our software system already has a User's 
Guide or online Help (RoboHelp, compiled help chm). When writing the 
Training Guide, it seems like I am rewriting my user manual all over 
again...>>

The two should achieve entirely different purposes. Consider the 
following example: In a training guide, you might teach someone about 
using the online Help (something I highly recommend for beginner 
audiences): how to open the Help menu, the different options available 
under that menu, how context-sensitive help works, how to use the index 
vs. the search function, and so on. In a reference manual, you would 
not do this.

See the difference? A training guide teaches someone the basics of how 
to interact with the software; the reference (user's) guide provides 
detailed instruction for someone who already knows the basics of how to 
use the software. So for example, you would _train_ me to use menus and 
the keyboard and dialog box to print a Word file; after that, the 
user's manual would explain all the options in the Print dialog (every 
field, every button, etc.).

<<We will provide this training guide to supplement our Project staff 
when they deploy the software and train clients.>>

Since you'll be working with these people, make sure to spend time with 
these people finding out their needs and the needs of the people they 
will be training. This information is what lets you produce 
documentation that meets their actual needs, rather than making 
potentially incorrect assumptions about their needs. We often fail when 
we assume that we understand our audience.

<<I feel uneasy that it may not be a good idea in the long term 
(duplicating information).>>

Some duplication is inevitable, but you're right that you shouldn't be 
wasting a lot of time doing things twice. Understanding the difference 
between training and reference material (see above) helps. In some 
cases, it will still be appropriate and helpful to repeat information; 
in that case, do so. If you'll be doing it a lot, investigate the 
possibility of various forms of "single sourcing" (reuse of content in 
different contexts).

<<Our users are majority of of low education (some illilterate), 
although manager/supervisor levels will have no problem reading. Though 
I suspect the training will mostly benefit supervisors and managers.>>

Make sure that you understand which audience you're actually writing 
for, since their needs will clearly differ. If most of your audience 
are "low education", prioritize their needs: something that works for 
them will also work, even if less well, for the managers, but if you 
focus on the needs of the managers, it won't work at all for the 
majority of your audience. You may need to create a separate document 
just for the managers that focuses on their specific needs.

If most of your audience is low-literacy, emphasize the use of graphics 
rather than text. One very powerful approach (supported well by many 
Dutch studies, including some with Asian audiences, I believe) is to 
use screenshots, with callouts (text plus arrows) pointing at specific 
areas of the screen and stating explicitly (and concisely) what the 
reader should do. It's unlikely that you can use an entirely graphical 
approach (i.e., you'll have to combine text and graphics for most 
things), but you can certainly emphasize the graphics.

Another key point: For an audience like the one you describe, ask 
yourself the following question: "What information does the reader need 
to understand the instructions I will present?" That is, explicitly 
identify your assumptions, and state those assumptions clearly. The 
audience will not know what you are assuming until you tell them, so 
tell them!

<<Do I document every dialog/field/ screen, or am I focused on user 
interaction flow alone.>>

In a training guide, emphasize the overall flow: what do I do and why? 
The advocates of minimalism (the excellent work of Carroll and van der 
Meij) have clearly demonstrated that adult learners learn well by 
exploring the software once they understand the what and why. So focus 
on that, and design your training to support this kind of learning by 
exploration. The user manual supports that exploration by answering 
questions that come up as they explore.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
www.geoff-hart.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l


---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.