Instruction and Feedback Models for Software Training
By Anthony Karrer, Alan Laser, and Laura Sund Martin

A previous article, "Simulation Levels in Software Training," presented a lexicon for describing different interaction levels in simulation-based software training. It outlined screen capture, point-and-click, data input, multiple path, and full simulations. With that terminology established, it's time to put a common vocabulary around instruction and feedback models for simulation-based software training. In other words, what are the different ways we can use simulation to teach end-users how to effectively use the software application, and how can we confirm that end-users are actually learning?

The approach

From a high-level perspective, there are various approaches to teaching someone an application. In a breadth-first approach, training attempts to illustrate every screen and field, describe each task, and so forth. Alternatively, training can ask users to look at various application functions in an exploration approach. However, many agree that the most effective way to learn an application is by using a scenario-based approach, which has users mimic work units that they'll be performing on the job. Work units are a series of job-related activities that form a cohesive task. For example, entering a new user into the system is a work unit, but entering US$50,000 as the credit line is a directed function rather than a work unit.

Training without work units fail the user on two levels. First, there's less motivation: Without context, why should the user care? Second, it forces users to connect the dots between individual functions. In basic terms, training without work units explains what and how but forgets to include why and when. It's a good idea to develop effective software training by analyzing work units. By starting there, software training will inherently establish context for activities.

Overcoming arguments against scenario-based training. It's difficult to find meaningful and realistic activities for some software training, especially for broad applications used across a wide domain. For example, it's difficult to develop scenarios that are directly related to a specific user’s job for general word processing applications. Training programs for these applications must overcome this problem by finding relatively universal--and realistic--tasks that users will perform. For example, rather than asking users to create a letter, ask them to respond to a customer complaint in writing. This exercise gives context to the activity and suggests input data.

Likewise, some argue that scenario-based learning fails to cover every screen or field within a software application. To avoid this problem, make sure that the training module answers the question, When does a user need a screen or field to perform their work? If the user doesn’t use a particular screen or field, determine if it's important in other ways. For instance, if a screen contains information that the user may need to review at some point, then training should include a corresponding scenario. But if an end-user's work will never use certain screens, should training cover them merely for the sake of completeness? Perhaps, but keep in mind that the goal of training is to help users be effective on the job. If the field or screen isn't part of their work, covering it can distract from the training goal.

Selecting scenarios. Scenarios must be relevant and comprehensive--and compelling. For example, a software training application aimed at a system administrator included reconfiguring a kernel as one of its work units. Although few system administrators would ever need to do this, it would be a badge of honor to know how.

To ensure that scenarios include everything the user needs to know, developers should create a matrix that checks scenarios against screens and fields. This sort of development requires an iterative design process in which scenarios are chosen, modified, or deleted until the net effect appropriately covers all of the necessary functions.

Feeding information to the user. After basic scenarios are established, feeding the appropriate information to the user is the next important task, as well as ensuring that information is interesting. If you're asking users to enter new customer data, then you must provide the customer name and so forth. The challenge is to offer information without making the user feel as though he or she has become a robot. In other words, telling the user to enter "1234 in the user number box" isn't interesting or compelling. Including basic customer information up-front is more effective. On the flip side, don’t make it too difficult to find information or force users to go back and forth between multiple screens.

The models

By now, you've defined specific scenarios and need to determine how to ask users to perform each task. There are a variety of techniques to use, but the most fundamental interaction models are Show, Teach, and Try.

Show modules are a passive experience in which the maximum simulation level is a screen capture and the occasional point-and-click module. Teach modules usually occur as point-and-click or data input simulations. Try modules require a data input, multiple path, or full simulation. Basically, the level of guidance for the user is inversely related to the level of the simulation. (See Figure 1.)

Show modules require a step-by-step visual walkthrough of an application using screen capture and point-and-click simulations. In addition, they detailed narratives on how to perform each task. However, because people learn by doing, learners retain only a small percentage of what they read or view. The advantage in time and cost savings must be weighed against the disadvantage of low retention. This type of module is most appropriate when the intent is to familiarize the user with an application rather than instruct him or her on how to perform specific tasks.

Teach modules allow the user to take control of the demonstration. Following a step-by-step narrative, the user completes the task by performing each step. Because this is most likely the first time they've ever seen the application, be sure to provide feedback for each interaction. To be valuable, this type of interaction requires an input-level simulation, which allows for higher content retention rates because the user is actually performing the activity. (See Figure 2.)

© Digital Insight Corporation. "Digital Insight" is a trademark of Digital Insight Corporation. Used with permission.
Figure 2: This screenshot illustrates a Teach lesson in action. The user is prompted to perform a very specific task: Select Jonathan Livingston from the dropdown box, which is highlighted in a red box for additional guidance. This simple task is part of a larger overall lesson objective. After the user makes the correct selection, training cycles to the next task.

Try modules ask a user to test their knowledge of a particular task. Rather than in-depth instructions, the user receives a general description of the task. By this level, users are expected to know enough about the application to accomplish the task. Comprehensive feedback is critical for these modules to be effective, and some mistakes may even end the scenario. The goal is solidify the learner’s knowledge. (See Figure 3.)

© Digital Insight Corporation. "Digital Insight" is a trademark of Digital Insight Corporation. Used with permission.
Figure 3: In the Try example, the user has already accomplished the task during an earlier Teach interaction. Specific instructions have been replaced with a general description and the red highlight box is missing. At this point, the user is supposed to know that the first part of setting up Judy as a wire administrator is to select her name in the dropdown box, just as he or she did in Figure 2. However, the Boxes and Clues buttons in the bottom allow the user to revert to Teach Me mode if they become lost or frustrated. Finally, the instructions in the left panel remain as the user progresses.

Feedback

Giving helpful feedback at the right time is key to effective software training. Although feedback for a multiple-choice test is a fairly simple matter (after the learner answers a question, he or she is told whether the answer was correct), feedback in a simulated application is more complicated because the user has more options.

Feedback based on user interaction within a simulation can take one of three forms:

• simple feedback, which is a message that indicates whether the user is correct
• task-specific feedback, which gives the user information relevant to individual tasks
• error-specific feedback, which provides information about each mistake that the user makes.

Developers also must determine how far a user can continue before the program catches an error. Most simulations have rather limited ranges, in order to minimize cost and to help users from running too far afield.

Teach and Try modules use three levels of feedback. The first level of feedback starts with a simple error message that tells the user that they made an error, but it doesn't give them help in correcting it. In other words, this is a "Please try again" message. The second level of feedback is task-specific and suggests appropriate action, such as "Click on the red button." In task-specific feedback, the message specifies what the user is doing wrong. This is helpful if the user mistook the number one for a lower-case letter l in the User ID, for example. The third level of feedback outlines what the user should've done and may restart the task or move to the next one.

© Digital Insight Corporation. "Digital Insight" is a trademark of Digital Insight Corporation. Used with permission.
Figure 4: This example of task-specific feedback illustrates a Digital Insight training module in Teach mode.

The level that's most appropriate depends on the goal of the training. If training is in test mode, the user might get first-level ("try again") feedback twice, giving them the opportunity to figure out the correct action on their own. On the next wrong action, though, the training should give the second or third level of feedback. The user cannot complete this task, and rather than continue to frustrate them, training should let them continue. Alternatively, if the training is meant to serve only as a review, the second level of feedback can be employed. This allows the user to see the correct answer and perform the action, which reinforces learning.

© Digital Insight Corporation. "Digital Insight" is a trademark of Digital Insight Corporation. Used with permission.
Figure 5: simple feedback. The user only knows that they did something wrong, although in this Try mode, the user can turn on the clues and/or the red boxes which lets them know what to do next.

When and where feedback is presented is just as important as the content within the feedback. If feedback is presented at the time of the error, it's important to keep the user from doing anything else to the simulation while the error is displayed. This prevents users from making additional mistakes while reading or dismissing the feedback.

Expert tips

A common technique in classroom-based software training is for the trainer to show how something is done, then ask learners to perform the task. After practice, the trainer discusses other things the learner should know and related tips. These kinds of expert tips are valuable to the learner, and they can be incorporated into software simulations.

How to include expert tips into online software training is determined by the flow of the training application. Should additional training material appear during the execution of a task? If interruption is okay, then present expert tips as transitional screens. Similarly, if the learner needs critical information before continuing a task, expert tips could be presented as intermediate screens. If interruptions should be avoided, keep tips hidden under a button or icon. It's possible to combine techniques. Designers can insert critical tips as notes in the instructional text and also include tips on a final screen or behind a button. (See Figure 6 and Figure 7.)

© Digital Insight Corporation. "Digital Insight" is a trademark of Digital Insight Corporation. Used with permission.
Figure 6: Important notes are inserted in the instructional text.

© Digital Insight Corporation. "Digital Insight" is a trademark of Digital Insight Corporation. Used with permission.
Figure 7: Helpful hints are inserted at the end of a scenario.

By recognizing these common simulation models--Show, Teach, and Try--and incorporating various feedback levels, designers will be positioned to develop user-friendly software training.

Published: March 2002