Answered Question on Linkedin.com: Instructional Design standards for online learning? Ideally specific and measurable that can be used in contracts with vendors.?

This question was posted to theInstructional Design & E-Learning Professionals' Group:

Does anyone out there have any useful resources to share around ID standards for online learning? Ideally specific and measurable that can be used in contracts with vendors.

I have used the standards posted by the Open ECBCheck. Open ECBCheck is "a new accreditation and quality improvement scheme for E-Learning programmes and institutions in international Capacity Building." Their members focus on a specific subject (international capacity building), however, their e-learning standards can be applied to any e-learning program.

I download the standards from http://www.ecb-check.org/2011-06-15-07-04-37/guidelines. They publish them as a pdf and Excel file. In the Excel file, I find the most useful section to be the tab labeled "Quality Toolkit." That tab has a list of specific, measurable criteria that you can use to judge the quality of your e-learning program. For example: "Does the navigation allow learners to always understand their position within the programme?"





Not all the standards in the Quality Toolkit will apply to all online learning programs. I copy and paste the standards that apply to the job into the contract for that job. This is a section of the contract that I label "Course Standards."


The Course Standards section also includes subsections for things like: the file formats of the material developed for the course, voice and tense of the speaker, the skin to be used when generating files from Articulate of Captivate, and the source(s) of the graphics used in the course.

The quality standards supplied by Open ECBCheck have made a good starting point for the course standards in my projects. Post your favorite resources for quality standards in the comments below. Or,

Answered Question on Linkedin.com: What successful techniques have you used to improve learner's retention?

I recently answered a question on the Instructional Design & E-Learning Professionals' Group of LinkedIn, and wanted to share that answer here on my blog. The question posed was:

What successful techniques have you used to improve learner's retention? Based on my experience, there's only so much information you can stuff into people's heads.
What's the best single tip you would give to help improve the quality and quantity of information that people retain after experiencing the training you've developed?

My single most important tip is this: Instead of training your students to perform the task from memory, teach them why and when to perform the task, and how to use support materials to succeed at the task.

If you are training your students to perform a life-and-death skill under strict time constraints, then of course they need to be able to perform the task from memory, on demand. An emergency room medical procedure would be one example. In that kind of situation, you want them to leave class knowing exactly how to perform the task without any kind of support materials. But that is a rare situation.

In most situations, your students will have time to perform the task. That is, they will have time to find and use reference materials to help them with the task.

Instead of overloading your students with the detailed steps of how to perform a task, perhaps you should consider teaching them how to use the reference and support materials to perform the task. Then, you can focus your training on:

1. Why they need to learn to perform the task (motivation).
   
2. Who needs to be involved in the task (roles and responsibilities).
   
3. When they need to perform the task; where it fits into their workflow (context).
   
4. Which steps are critical or especially difficult (roadblocks and "gotchas").
   
5. Where to get supporting materials for the task (reference materials and job aids).
   

Of course you will still take your students through the detailed steps of performing the task. But instead of focusing on memorizing the how-to information, you'll focus on the information above. While demonstrating, you can reassure them that the "clicks, keystrokes, and actions" are all included in the support materials. After the student performs the task on-the-job a few times, with the help of the support materials, then it becomes committed to memory.

In my experience, this approach avoids information overload during class while enabling students to learn complex, long tasks. Does this agree or disagree with your experience? We want to hear from you in the comments!

How to develop training when the subject is a moving target?

Recently, I received this question from someone who had read my book on Writing Successful Software Classes. My answer appears after his question:

Problem: They keep changing the software spec's, as I'm developing training!

> The company is
> currently in the process of creating and implementing a new core business operating system.
> Our legacy system is antiquated to say the least (it is DOS based).
> The new system is being built from scratch, so this is no out of the
> box ERP that we are talking about.
>
> My team and I are competent instructional designers and trainers but
> our experience is limited to training on processes or systems that are
> already complete. What I am struggling with is building training for a
> system that is being built as we are expected to develop training. If
> the system were complete and then we had 6 months to develop the
> training before it was implemented, we would be okay, but that is not
> the case...we are expected to develop training from
> Functional Design Documents which by the way are not necessarily
> well-written. The system is being given to us in milestones, but they keep changing things and changing the milestones.
>
> I have found resources on major software rollouts, and systems
> implementations, but they are very technical in nature and gloss over
> end user training. Other resources that do concentrate on technical
> training make the assumption that a system or concept is complete when
> you develop the training.
>
> Do you have any advice or ideas of how we can tackle this? Let me know
> if you want any more details. I really appreciate your thoughts and your time.

Solution: Focus on documenting business processes first, then write keystrokes-and-clicks second

Training and user documentation almost always comes at the end of a software rollout. By the time the trainers and technical writers have the information we need, almost everyone else has finished their part of the project. And when people at the beginning of the project take more time than planned, and the deadline stays the same, that extra time they get must be taken from someone else. Usually, that's the trainers and technical writers. "We allocated three weeks for you to develop training, but testing and bug fixing took an extra week, so we had to shorten your time to two weeks."

At most companies, this is just the nature of the job. There are ways we can adapt.

First, focus on writing good instructions for your users. Unless your users must perform their work without referring to a manual, the instructions will be the user's safety net when they need to begin using the software.

Research I've done among the users that I serve showed that they prefer printed instructions. They don't like switching between two windows on their computer screen: one with instructions and one with the software. Among my users who have dual monitors, that is not a problem. But most of my users have a single, 17- or 19-inch monitor. I suspect that is why they prefer printed instructions.

Notice that I've been using the term "instructions" and not "user manual." A user manual is more than a collection of instructions. It gives background and context to the instructions. That is, a user manual doesn't just tell how to perform tasks, but also when and why. Think of instructions as a series of cheat sheets, or quick reference guides.

As you're writing those instructions, you will be simultaneously developing the demonstration that you use for training. More on that later. (At this point, you were probably wondering when I'd get around to answering your question about developing training. Hang in there).

Our biggest challenge is that as we are writing user instructions and developing training, the software is changing. We need to document and develop training for a moving target. How to do this? Here's something that has been key for me: start first with the information that will not change.

Forget about beginning your writing and course development with the introduction, or the clicks and keystrokes. Instead, begin with the information this is most unlikely to change.

In my experience, the specific list of business tasks that users need to perform with the software is unlikely to change. So I start with that. For example, suppose the business tasks I must teach are:

1. Create a new customer.


2. Enter customer demographics.


3. Attach a mortgage record to the customer.

Each of those tasks will have a quick reference guide, and a demonstration in your training class.

Now, I understand that you do not yet have the keystrokes for performing those tasks. The software is changing, so you can't write the keystrokes and clicks yet. But there are some things you can write about each of these tasks, such as:

• When to perform this task (where does if fit into your workflow?)


• Why to perform this task (what deliverable is produced; what result?)


• Next steps (what do you usually do next?)

So on each of your quick reference guides, you can add that information. For example, for the task "Create a new customer" your quick reference document might look like this:

Section: Creating a new customer

Subsection: When must you create a new customer? [This is business process information. You should be able to write this even if they don't have the software finished]
Subsection: When How to create a new customer [This subsection isblank, you don't have the keystrokes and clicks yet because they keep changing them on you]
Subsection: Results [This is business process information. You should be able to write this even if they don't have the software finished]
Subsection: Next steps [This is business process information. You should be able to write this even if they don't have the software finished]

Notice in that example above, you can write three out of four subsections even while the software is still being changed.

Remember I said that you can simultaneously develop the training demo? So at the same time that you start writing these instructions, you can start writing the slideshow for class. Your slides might read something like this:

Slide 1: Creating a new customer
When must you create a new customer?
Create new customer only when...
Slide 2: Demo
...blank slide, here you begin your demonstration...
Slide 3: Results
A new customer record in....
Slide 4: Next steps
At this point, you can now do this....

You can also start writing the in-class exercise, if there is one. For example, "Create a new customer using the following information..." During the exercise, you would have the students try to perform the task, using the quick reference guide that you wrote.

At this point, you send the instructions back to the subject matter experts for their sign-off. Since you don't have the keystrokes and clicks yet, you probably won't be sending the material to the software guys for sign-off.
But what you do have is the business process information, that is, what the user will do and where that fits into their workflow. So you will send this to the business owner of the software.

As the software team finalizes the screens, you'll be able to fill in your instructions with the keystrokes and clicks. You'll also be able to plan your training demos. When all those instructions and demos are filled in, you have most of a user manual and a nearly complete training course.

When you train, you'll make it clear that you don't expect the people in class to come out with the keystrokes and clicks memorized. That is what user documentation is for. Instead, your purpose in class is to:

• Show the students where each task fits into their workflow.


• Emphasize the critical steps in each task: things you must do.


• Stear them around the mistakes that you cannot recover from.


• Show them where to get further help with the software (if your company offers this kind of support).

In your email, you mentioned Functional Specification documents. You might be able to pull much of this information from those documents. But don't get bogged down in trying to write detailed instructions from those functional specs. It just isn't realistic to document clicks and keystrokes until you have a working product in front of you, and an authority figure who says, "freeze this interface here." Until then, you are writing the framework, or outline, into which you will drop these keystrokes and clicks.

This is the process that has worked for me. I hope that you will find it useful. If you have any questions, I'd be happy to help.

Developing an Online Course in Moodle as Quickly as Possible

I had a reader send me a question about how to estimate the time it will take to develop a course in Moodle. I'd like to share her question and my answer with you. As always, your comments and experiences are welcome.

Her Question:

I am just about to embark on my masters dissertation project, and am looking a web-based tutorials for teaching. At the moment I’m considering putting together a tutorial as part of the project using moodle (I have copies of your books in front of me now).

One question I cannot seem to find an answer to, is realistically how long would it take for me to construct something like this? I have seen reports stating that construction of online courses can take up to 18 months, but I think these were from scratch as opposed to using a software programme such as moodle. I am fairly Internet literate, and have created basic webpages before, but have never done anything like construct my own online course.

I am studying via distance learning and also have a full-time job. I have between now and June/July to work on my project (including analysis and user-testing, etc) – do you think this is something which I can realistically achieve in this kind of time frame?

My Answer:

In my experience, the old methods of determining how long it takes to develop courseware were never very accurate. With the variety of tools available to us today, the many different situations, and the many different expectations from learners and stakeholders, those old recommendations are even more inaccurate.

I no longer ask, "How long will this take me to develop?" Instead I ask, "How long before the client needs it?" And then I determine what I can do between now and then. It sounds to me like you have a few hours a week to spend on developing an online course, between now and June. That's not much time. So instead of dwelling upon how long it will take, let's talk about how to maximize your output in the time that you do have.

First, try to get out of installing Moodle yourself. If you can use an outside hosting service, find one that has a one-click install for Moodle. If you must use your organization's web server, try to get the web admin to install it for you. When Moodle installs without trouble, the installation goes quickly. When it gives trouble, you can spend hours tracking down the problem. If you pay a few dollars a month for a hosting service that will install Moodle for you, I advise it.

Second, resolve to stay within Moodle's built-in capabilities. Some of the add-on modules add great functionality. But for a project working against time constaints, I advise you stick with Moodle's built-in functionality and not get bogged down in trying to get add-ons to work.

Third, make as much use of existing material as possible. As a librarian, I'm sure you can locate web pages that you can use as course material. I think there's nothing wrong with a course whose learning material consists entirely of links to external web pages, video, and audio. For example, if I was teaching a course on public speaking, I might link to a funny Youtube video of public speaking bloopers, tips from Toastmasters, and famous speeches. Creating your own multimedia takes especially long, so I would search Creative Commons for media I could use in my course.

Fourth, I would try to use Moodle's built-in Web page editor (Web page Resource) to write a short description of each resource that I link to, and what I want the students to pay attention to while viewing it, and what I'd like them to get out of it. To ensure that they read this before going to the resource, I would put the link to the resource on this web page instead of on the course's home page. Then, the students would need to go through the web page that I write before clicking through to the external web page/video/audio.

Fifth, I would follow up each reading/viewing/listening resource with an activity created in Moodle. For example, I might ask the students to:

1. contribute to an online discussion, and to rate other students' postings in that forum. (Forum activity)


2. take a short quiz on the material (Quiz module)


3. write a summary of the material and upload it (Assignment activity)


4. record a snippet of speech and upload it (Assignment or Workshop activities).

Sixth, I would use outside services for things that Moodle doesn't handle, or that it handles only with plug-ins. For example, after the students have completed viewing the resources and doing the follow-up activities, just before an exam, I might schedule a summary lecture with WebEx or GoToMeeting. The lecture could include a slide show of the material that will be on the final exam, whiteboarding, and chat. If possible, I would record the session and offer it to the students as a download.

Seventh, I would offer an online exam open only at a given time, to ensure that students don't take the exam and pass along the answers.

That would be my model for rapid development of an online course. And if I could, I would choose a topic for that course based upon the amount of good material freely available online.

Estimating the time to create a training course

The Question

I received this email asking how to estimate the time it takes to create a software training course:

Hello,

I have a strong background in software development and training development and delivery. My training has always been around soft skills, business processes, and employee orientations.

I recently joined a software company as the Training Manager and I’ve been tasked with “figure out how we should do user training for our product”. I’ve purchased and read your book, User Training for Busy Programmers and it’s been very helpful already in translating my current knowledge of software development and non-software training into what I need to do for software user training.

I was wondering if you have any thoughts or resources around estimating the time it takes to develop user training following the process you outline in the book?

Thank you,

Jennifer

The (somewhat disappointing) Answer

Here's my reply:

Jennifer,

Years ago I asked this question on several of the most popular training and technical writing mailing lists. I also tried equating the time it took to develop training and documentation to things like function point counting, number of screens, number of keystrokes and clicks. None of it worked.

Seriously. The conclusion I arrived at is that there is way to predict the time to develop training and documentation, that is more accurate than your own experience.

Since you have experience developing training in business processes, you're not far off from being able to accurately estimate time to develop training for software. Because at the end of the day, a software class is (or should be) nothing more than a business process class that features a new tool. So when you're trying to estimate development and delivery time for a software class, ask yourself how long it would take to develop and deliver the class if you approached it as teaching a new business process, which just happens to use a new tool.

Sorry I couldn't give a more concrete answer. This is a question the continually challenges me, and I'd be happy to hear of any resources you find that help with it.

Regards,

William Rice

A Plea for Help

I want to hear what you have to say about estimating the time it takes to develop a software training class. Do you have any objective, quantitative methods that work for you? Or like me, must you rely on intuition and experience? How accurate are your estimates?

This topic is ripe for conversation. Leave a comment, and keep the dialog moving!

Creating an Instructor Kit

After you've tested the in-class exercises, polished the presentation
materials, printed the handouts and workbooks, and created the data files
for class, are you ready to hand over the course to an instructor? Not
yet. You have one more thing to do before calling your course finished:
Create the instructor kit.

An instructor kit often differentiates a good course from an exceptional
course. It is more than a pretty package or a finishing touch. It is an
integral part of any training course that you must hand off to an instructor.
The instructor kit's ultimate goal is to increase the quality of the students'
experience, by helping the instructor to assimilate, set up, and deliver
your course.

This article addresses creating an instructor kit for a software course.
However, 90% of this article is directly applicable to creating an instructor
kit for any technical course, and the other 10% is easily adaptable to
non-software courses.

What is in an Instructor Kit?

An instructor kit consists of information and tools.
Most of the information helps the instructor teach. Most of the tools
help the instructor set up, reset, and delete the course. The information
that you should include in an instructor kit is listed below. The software tools that you should include are described after that.

Types of Information in an Instructor Kit

Most instructor kits require the following types of information:

Prerequisites

Prerequisites include:

• Proficiencies the instructor must have to teach the course.
  


• Information the instructor must know about the subject.
  


• Minimum equipment and software needed to teach the course.
  

Setup Directions

Setup directions include:

• Required settings and configurations for the equipment and software before installing the course.
  
• Directions for installing the course files.
  
• Required settings and configurations for the equipment and software after installing the course.
  
• Directions for testing the installation.
  

Delivery Information

Delivery information includes:

• The location of any data or documents that the instructor or student will use in class.
  
• The location of any data or documents, and a list of functions or menu items, that the instructor should steer students away from.
  
• Key points that the instructor must address in class.
  
• Directions for demonstrations.
  
• Information to help the instructor coach students through workshops.
  
• Directions for using the tools listed in the next section.
  

Reset Information

Reset information includes:

• A description of the state of the data and documents used in class, after class.
  
• Directions for returning data and documents to their pre-class state.
  
• Directions for testing the reset procedure.
  

De-installation Directions

De-installation directions tell the instructor how to de-install all
software placed on the training computers, and how to reset the computers
to their original state.

Types of Tools in an Instructor Kit

For a software course, most tools consist of software designed to help
the instructor present the course, such as:

• Installation Software.
  
• Electronic Slide Shows.
  
• Reset Software.
  

Tools may also include a printed instructor guide, and hardware needed
for the course. Most instructor kits require the following types of tools:

Instructor Guide

The Instructor Guide contains all of the information given above. It
is usually a printed document, but most instructor kits also include an
electronic version of the document.

Installation Software

The installation software may be simply files that the instructor copies
to the classroom PCs, or an application that performs the installation
when launched. The installation software can:

• Install the data used during the course.
  
• Install the documents and files used during the course.
  
• Install the Electronic Slide Show.
  
• Configure the settings on the computer(s) used during the course.
  

A course may require separate installation routines and files for the
instructor and students. A non-software course may instead have equipment
that is used during setup. This equipment may differ for the instructor
and student.

Electronic Slide Shows

Electronic slide shows are usually created with an application like PowerPoint
or Astound!. The slide shows may be installed by the same software as
the data and documents used during the course. Or, it may require its
own installation software.A tutorial on creating electronic slide shows
for technical training is beyond the scope of this article.

Training Applications

Training applicatioins consist of the applications that students and
the instructor need for the course. This may include the actual application
being taught, and also:

• The application used to run the slide show.
  
• Applications used to examine documents.
  
• Applications used to examine, create, or modify data that is used in class.
  

Training Files

Training files consist of the data and documents used during class. The
instructor may receive more complete versions of the data, for demonstrating
the results of in-class exercises. If this is so, the instructor and students
will need separate installation routines.

Reset Software

Reset software returns the data and documents used during class to their
pre-class state. It also resets and software settings that the students
changed during class.

De-installation Software

De-installation software removes all training software from the computers
used during training. It also returns the computers to their original
settings.

Outline for the Instructor Kit Guide

Use the following outline as a starting point for writing your instructor guide. I've numbered the sections so that you can see the hierarchy.

1. Introduction to the Course

Explain why the course is taught, what the course covers, and to whom it is taught.

1.1Purpose

List the proficiencies the students will develop during the course.

1.2 Software Covered

States the software that the students will learn to use. Include the version numbers and platforms for the software.

1.3 Audience

Describe the audience and the audience’s situation. For example, "This course is designed for line managers at Company X who must create budgets for the groups they manage."

1.4 Agenda

State the high-level topics and estimates for the time to teach each topic.

2. Contents of this Instructor Kit

An instructor kit is often packaged into a binder that includes a written instructor guide and CD containing all software and files. Usually, the majority of this section lists and describes the files on the CD.

2.1 Documents

Describe the purpose and format of any documents used during this course. If a document must be printed for the course, state so in its description. State when each document is used in the course.

2.2 Data Files

List and describe the data files used in the course. Stating when each file is used helps the instructor trace any problems during the course to a faulty installation. For example, suppose an exercise in loading data does not produce the intended results. If the instructor knows that FileX is used in this exercise, the instructor can check the installation of that file while troubleshooting the workshop.

2.3 Applications

If the course requires the installation of any applications, include the installation files and instructions.

2.4 Hardware

If the course requires special hardware that is not available at the training site, include the hardware in the instructor kit.

3. Prerequisites

This section describes all prerequisites for the course. Prerequisites can include physical items, software, and knowledge.

3.1 Room Equipment

List and describe the non-computer equipment the instructor needs to teach the course. Some items that might appear on this list are:

• A whiteboard.
• A flip chart.
• An overhead projector.
• Give-aways for students.
• Name cards for students and instructor.
• Items used during training games or demonstrations.

3.2 PC Hardware

List the minimum requirements for the student computers, and the instructor computer. Some of the requirements:

• The amount of memory. Does the instructor computer need more memory to run the training application and slide show concurrently?.
• The amount of free hard disk space. Do the instructor files take up extra disk space?
• Processor speed.
• Display resolution.
• Floppy, CD, and/or DVD drives.
• A printer.

3.3 Software

The software on which you are training is an obvious choice for this list. Also consider any applications needed for opening files used during training. For example, if you load a graphics file into the training application during class, will you need a graphics application to examine or edit the file before loading it? If you supply documents in .pdf format, will the students need Adobe Acrobat to view them? If the training application exports data to a spreadsheet, will you need a spreadsheet application to examine the data?

3.4 Instructor Proficiencies

This can consist of a list of tasks the instructor is proficient in. Or, it can state that the instructor must have a certain amount of experience with the application.

Most in-class exercises begin with a list of the proficiencies developed during the exercise. One easy way to complete this section is copying those lists into this subsection.

3.5 Instructor Knowledge

An often-overlooked prerequisite for many technical training courses is instructor knowledge of the business processes that happen before and after training. The instructor should also know who supports the users after training.

Students often ask questions that go just beyond the scope of the application being taught, such as:

• What is the source of the data that the training application accepts?
• What happens to the data or files that the application outputs?
• Who is responsible for supporting the users after training, as they begin to use the application?

3.6 Student Proficiencies

Many software courses list "Basic PC skills" as a student prerequisite. Be more specific. For example, many users who claim they have "Basic PC skills" do not know how to:

• Navigate around a hard disk and find a file from within the Open File dialog box.
• Turn on the display of file name extensions. With the file name extensions turned off, "file.txt" and "file.dat" are both listed as "file."
• Right-click and use shortcut menus.

If you do not state exactly which "Basic PC skills" the student needs, the instructor may need to spend valuable class time teaching teaching remedial PC skills.

3.7 Access Rights

Many training courses are taught off-site, at a client’s offices or a rented training center. While developing the course, you have access to the application and your computer. Do not take for granted that the instructor and students will have this same access when off-site.

When writing this subsection consider whether:

• The students can access the training application from the computers in the training room.
• The instructor has administrative rights to install the training software on the training computers.
• The students can access any network files they may need from the training room.

4. Setup Directions

This section includes setup directions for both the student and instructor computers. Refer to the section on software prerequisites and determine if the instructor needs to install the training application, and supporting applications used during class.

These directions do not always need to be detailed, step-by-step instructions. However, if you assume the instructor knows how to perform some parts of the installation without detailed directions, list this assumption in the Prerequisites section under Instructor Proficiencies.

4.1 Starting Point

Give a starting point for the installation. For example, before installation:

• What software must be on the student and instructor computers?
• What settings must be configured?
• What hardware must be connected?

4.2 Installing and Testing the Student Files

This subsection gives directions for installing the applications and files used by the student.

4.3 Installing and Testing the Instructor Files

This subsection gives directions for installing the applications and files used by the instructor. Sometimes the instructor setup is a completely different process from the student setup. Other times it is an additional process.

4.4 Installing the Slide Show

This subsection gives directions for installing the slide show. The installation may be as simple as copying files to the instructor’s computer, or it may use an installation application.

5. About the Training Application

This section tells the instructor what is unique about the training application. It supplies the kind of information that an instructor will discover after hours of exploring the training application. Save your instructor some preparation time and include a section about the training application.

5.1 Limitations, Instabilities, and Non-functionality

The development of a training course often starts while the product is still in development. For software courses, this means that the training course is often developed using an application that is not completely functional. The instructor must know what parts of the training application are unstable or unusable. Discovering these while presenting the class will undermine the students’ confidence in the instructor and the application.

5.2 Login Information

The instructor and students may use different login information. If all students access the same networked application during class, each will need a separate login.

5.3 Where the Data Is

A training application rarely contains as much data as a fully-functional production application. The instructor must know which settings will show data during demonstrations. Few things are more embarrassing for an instructor than desperately trying random settings during a demonstration, in an attempt to show how the application processes data.

5.4 Differences Between Student and Instructor Applications

The instructor’s application might contain more data than the students’ application, to make demonstrations possible. Or, the instructor’s application may have the finished versions of in-class exercises. The instructor must know about these kinds of differences before class.

5.5 Installing Fail-safe Data

Most software courses require a student to complete a series of in-class exercises. The result of one exercise often provides the starting point for the next exercise. Therefore, if a student fails to produce the desired result from an exercise, the rest of the class exercises can become impossible to complete.

Fail-safe data is data that can be copied into the training application to simulate the successful completion of an exercise. This gives the student the correct starting point for the next exercise.

If you supply the instructor with fail-safe data, include instructions for copying that data into the student application.

6. Module Notes

Each module, or chapter, in a training course usually covers a specific task or group of related tasks. Most modules follow a lecture-demo-exercise sequence. The subsections described below are based on these assumptions. Repeat each of these subsections for each module, or unit, in the course.

6.1 Points to Emphasize

Is there any information that the client asked you to emphasize during the presentation? Are there any procedures or steps that, if omitted, will cause a loss of data or failure in later procedures? Hopefully, all of the information that you have included in the course is important. But this subsection is for information that is essential to the success of the students, in class or when they return to their work.

6.2 Demonstration Script

You don’t need to script the instructor demo click-by-click. Just tell the instructor enough to re-create the demo you have prepared. Of special importance is stating exactly which data to use during the demo, and where the data is located.

6.3 Pre-exercise Checklist

This is a checklist of the menu options and features that the instructor taught during this unit. Just before the instructor tells the students to start the in-class exercise, the instructor can scan this list and determine if (s)he covered all of the topics necessary for the students to succeed at the exercise.

6.4 Starting Point for Exercise

Most students follow along with the instructor during demonstrations. This means that their screens will usually not be as they left them after the last exercise.

Describe the starting point for the in-class exercise. State where in the software the students should be, and what data they should be viewing. A screen shot may be a good idea.

6.5 Fail-safe Files for Exercise

The exercises in most software courses build upon each other. For example, Exercise 2 usually uses the results of Exercise 1 as its starting point. If a student does not produce the correct result from an exercise, this can jeopardize the success of subsequent exercises.

If this is the case in your course, provide fail-safe data for each exercise. State where the data is located and how to activate, or populate, that data if the student does not succeed at the exercise.

6.6 Slide Show Printout and Instructor Notes

You may know exactly why you’ve included each bullet point on each slide, but the instructor to whom you turn over your course may be left guessing. Instructor notes give the instructor more detail about the slides.

The slides do not need to be printed out at full-page size. Two to three slides per page gives the instructor enough detail.

Interview on Packt Publishing

Packt Publishing is the publisher of my book User Training for Busy Programmers. Based on that book, they published an interview with me on their site. We discuss some of the hard, real-world lessons I've learned as a technical trainer. It's a quick read, so if you're interested in training, check it out.

"User Training for Busy Programmers" is not just for programmers

I wrote User Training for Busy Programmers because I felt sorry for the programmers I worked with. Several of the software companies I have worked for had their programmers develop and deliver user training for their product. This was usually because the company started small, and did not have the budget to hire a full-time trainer. So the programmers were given the task of end user training. As the company grew, the programmers became too busy with programming to continue training and they became profitable enough to bring in a full-time trainer. In those cases, the programmers were very relieved to have me join the company!

I realized how common it was for small and medium sized software companies to have programmers, customer service representatives, and even salespeople conduct end user training. While many of these people have a natural talent for teaching, they are not professional trainers. They usually learn how to develop and deliver a software class "the hard way," by trial-and-error. And their employers have no intention of bringing in a professional trainer to take over the end user training. I wrote this book for them.

So don't be fooled by the title. Even if you're not a programmer, if you've been told to develop a software training class and you don't know where to start, this book is for you.

Writing User Manuals from the Middle Out

You need to write the user guide for a complex product. There must be a dozens of functions and hundreds of tasks that can be performed with the product. Where do you begin? How to start writing? Conventional wisdom says: start at the beginning with an introduction to the product, and work your way through each function or task in the order the customer will use them. Don't! Here's a tip I learned the hard way after my ninth or tenth year tech writing: start in the middle, and work your way outward.

This article presents a method of writing user documentation that you may find easier and more effective than starting at "Chapter 1:"

1. Start by writing procedures for each task or menu option. This is the "middle" of the document, and results in a collection of subsections.

2. Then, add material just before and after each procedure. This is working "from the middle out." The result is a collection of sections.

3. Organize the sections into chapters, and add more material to the beginning and end of each chapter.

4. Finally, organize the chapters into a manual.

I have found that this method of writing user manuals from the middle out saves time, and yields more accurate and useable documentation.

Why Not Start at the Beginning?

When you begin your manual with an introduction to the product, you also begin your research with an introduction to the product. Typically, you ask the Marketing or Sales department to describe how the product will help the user: "What will users do with it?" You ask Development or Engineering to describe the product's structure: "What is it?" You experiment with the product long enough to determine how it's used: "How does the user use it?" Then, you write your introduction. Which will probably contain inaccuracies and be less useful than it could be, for three reasons:

First, you are attempting to describe the purpose of the product ("What will users do with it?") before you have completely experienced using the product. By asking others what the product does, you are only discovering what they believe the product should do. You must first use almost every function of the product to determine what it really does. Remember, the manual is for users and should be written from a user's point of view. You can better convey the purpose and advantages of a product to a user when you have completely experienced the product from the user's point of view. This is why, in the middle-out method, you write the introduction last.

Second, you are describing the structure of the product ("What is it?") before you have experienced how the pieces of the product work together. Describing what the modules of a software application are is not nearly as useful to the user as describing what those modules do, and how they work together. You can best determine what they do and how they work together by experience.

Third, you usually develop the outline for your manual at this stage. Remember that the outline will determine the order in which you present the product's functions and tasks. And, you have not yet performed all of the product's functions and tasks. After you have experienced a complete cycle of using the product, you will be qualified to determine the order in which to present the procedures for using the product. At this point, determining the order for these procedures is guesswork.

In sum, when you begin writing a manual at Chapter 1, the manual becomes a diary of your learning curve. The first sectioins tend to be either ambiguous or self-obvious. They become ambiguous when you are conscientious enough to attempt to state something meaningful about the product, when have yet to gain real experience with the product. They become self-obvious when you attempt to state only those facts of which you are sure. Because you have little more experience than the reader, those facts will tend to be self-obvious. Starting in the middle and working outward avoids these problems.

How to Do It

To create user documentation from the inside out, follow the suggested steps below.

Write the Sections

Following the steps below will result in a collection of sections. Later, you will organize these sections into chapters, and then a manual.

1. Write the directions for each task or function.

Let's assume one of the tasks the user performs with the product is, "Create a new record." Write directions for this task. Don't worry about:

• The purpose of the task (Why create a new record).

• Where it fits into the big picture (When to create a new record).

• What the user must do or know before performing the task (Prerequisites for creating a new record).

The only thing you are writing is how to perform the task at hand.

Repeat this for each task or function the user can perform with the product. When you finish, you will have a collection of directions for performing all possible tasks or functions with the product. Label this paragraph "Directions."

2. Add prerequsites in front of each task.

Add a paragraph of prerequisites in front of each task. In our example, the prerequisite might be that the product must be in a particular mode before creating a new record. This paragraph should tell the user only and exactly what conditions must exist before the procedure can be carried out. Label this paragraph "Prerequisites."

3. Add results after each task.

A results paragraph states what the user should see to confirm that the task was successful. It also states what has changed as a result of the task. Label this paragraph "Results."

4. Add background knowledge before the prerequisites.

Examine each task and determine exactly what the user must know to successfully perform that task. Put exactly and only the background knowledge the user must know for a task immediately before the prerequisites for that task.

If several tasks require the same background knowledge, you should probably organize them into a chapter or section and place the background knowledge only once at the beginning of that chapter or section.

5. Add next steps after the results.

State what user must, should, or can do next.

After following the five steps above, you have a collection of procedures. Each procedure comprises a section, consisting of:

• Background information

• Prerequisites

• Directions

• Results

• Next steps

Organize the Sections into Chapters

Only now that you have performed every task possible with the product, and determined the prerequisites and results of each task, can you see how they fit together into the overall process of using the product. Now you are ready to determine the proper sequence for performing the tasks, the purpose of each task.

Organize the sections (procedures) into logical groups. You may organize the procedures in the order in which the user is most likely to perform them. Or, you may group procedures with similar functions together. Whatever scheme you choose, each group of sections becomes a chapter.

Now examine the procedures in each chapter and ask, is there any information that the user must know to perform these procedures? At the beginning of each chapter, add exactly and only the information the user must know to perform the procedures in that chapter. Label this section "Introduction."

Determine the Purpose of Each Procedure

Good user documentation doesn't tell the user only how to perform a procedure. It also tells the user when. Now that you have experienced and organized all of the tasks for the product, you are qualified to determine when it is appropriate to perform each procedure. A "When this... Do this..." table is one effective way of presenting this information. You can place this "When..." information in:

The introduction to the manual. You would probably include "When..." information for all of the procedures here. This is usually the easiest place for the user to find the information.

The introduction to each chapter. You would probably include "When..." information for only the procedures in the chapter here.

Each section. You would probably include "When..." information for only the procedure in the section here. This is usually the most difficult place for the user to find the information.

Finally: Write Chapter 1

Now, look at the whole manual. Is there any background info that a user must know before using any of the procedures in the whole manual? Write it down. Call it "Chapter 1: Introduction."

Assemble the chapters, generate a table of contents, and you've got yourself a manual!