Now it is time to develop a training scenario that you can use to teach the process.
In software training, your goal is to develop competence in a specific process or set of tasks. The exercises that your clients practice these skills on are what build their competence. The slides, handouts, and lectures support the exercises. For each class you need to design a training scenario that is appropriate for the process and tasks to be taught in that class.
This scenario should simulate a business situation that the students will face. In our auto insurance claim example, the scenario could involve processing several different types of claims. When designing this scenario, we would describe each type of claim and list any special features of the application that the claim uses.
Your scenario design will read almost like a narrative of a day in the life of your student. Remember that the scenario is a summary, or description, of a business situation. It is not step-by-step directions for using the application.
The following example is a part of a training scenario. In this scenario, the course teaches users how to process insurance claims. Notice that the scenario covers variations of one task: processing a claim. Notice also that the scenario addresses the workflow for these claims. It states what tasks the user will do, in what order, without telling us how:
Don’t confuse the overall scenario with an individual exercise. The scenario is the setting for all of the exercises. Each exercise teaches one of the tasks, or learning objectives.
The following example describes the usage of a new online requisition system. Notice that this scenario tells us where the requisition system fits into the larger business process of purchasing supplies for a given company. The scenario takes the users through the entire process of using the software, from entering a requisition to receiving the requisitioned items:
During this scenario, the instructor plays the role of other people involved in the requisition process. On the job, the requisitions entered by the users require approval from the Department and from Finance. To simulate this approval, the instructor will play those roles. Notice also that the instructor will "change the status of the order to Delivered
". The software must be set up so that the instructor can give these approvals and change the status during the class. The scenario designer must consider how many requisitions the students will create in the class, and how long it will take the instructor to simulate the approval and delivery of these requisitions.
The following example is another training scenario:
If you’re not teaching a software toolkit, you can safely skip this section. Software toolkits present a special training challenge. When teaching a toolkit, you’re not teaching a predictable process. You’re teaching a set of tools and techniques that can be used in many, unpredictable ways.
An Application Programming Interface (API) is one example of toolkit training. A programming language is another. In these courses, each function or group of functions would comprise one chapter. The question is how do we design the scenario for our in-class practice so that it flows logically, and gives the students experience with the many possible ways of using the functions?
End-user training is like teaching someone how to build a wooden box. You might need to teach how to put the hinges in different places or how to attach different clasps, but the basic process is very predictable.
Software toolkit training is like teaching someone how to use the woodworking tools in a shop. It’s difficult to predict how your students might want to use and combine those tools. How do you ensure that they leave knowing how to build whatever they desire, whether it is a box or a table?
This unpredictability makes scenarios for software toolkit training very difficult to develop. You have many options for developing scenarios for a toolkit course. As usual, the options that are best for your students require the most work from you.
Developing a toolkit course around the single most probable usage of each item you are teaching is the easiest option. Design each in-class exercise to demonstrate the most probable usage of the function or group of functions. Don’t make the output of one exercise become the input for another, or make all the exercises part of a common scenario. Instead, design each exercise to stand alone.
Leave time to discuss more exotic usages in the class. After each exercise, encourage the students to ask about how the function(s) can be applied to their situations. This usually gives satisfactory results...if the course designer leaves enough time in the schedule for discussion, and if the instructor prepares for questions by learning the students’ situations before the class.
When using this option, student satisfaction can be greatly increased if you give them a choice of exercises to work through at the end of the class. Each exercise can simulate the situation of one type of client.
Here is how the flow of the class would look:
Why are we talking about the scenario before we’ve even written the course outline? Because the practice scenario is the outline.
At this point, you should:
18.218.127.141