Creating roleplay scenarios (2) scripting
This is part 2 of my description of the first e-learning scenarios I've worked on.
This is best done face to face with more than one SME, and possibly recent trainees who know the likely mistakes all too well. You have to allow a couple of hours at least for the first one. Later ones may not be so difficult.
The output from this stage is a Word script that shows each question, numbered. For each choice in the question, there will be the number of the question or screen that choice leads to. There will also be a note of any tracking that needs to be done.
|
Mr White: I'm just calling to let you know I've changed my address. The new address is 67 Morrison Gardens, South Crossferry, CF30 4GR (2) Thanks for letting us know, but I'm afraid you need to
put it in writing. (3) Sorry we can't do this by phone. (cus service=-1) (4) Thanks - what's your account number? (got acc
no=’yes’) -------------------------- 2: Need this in writing Mr White: Well, HSBC take it over the phone. Why can't you? (5) For your security we need your signature before we can
make a change to the account. (5) Sorry that's just our procedures. (cus service=-1) |
You can write it from scratch, but it’s very helpful to use Quandary as a tool in the meeting. In Quandary you complete forms, creating the scenario as you go along. At any point you can run the scenario to test it.
Why not just use Quandary instead of our templates? Because while it works well would be very difficult to make it resemble our other elearning in look and feel. We also rejected it before because its output was over 50k per page limit to which we were subject at the time.
It doesn’t take long to learn Quandary and it gives the process a creative and interesting focus that you simply don’t get with a Word document.
When you’ve finished in Quandary you can output the scenario to Word and that’s 90% of your script done.
After we'd created the first couple of scenarios in Quandary, the SMEs wrote more scripts from scratch.
Creating the scenario
Start with the ‘best practice’ path and go through all the actions and consequences. That will give you both the scenario and option 1 for each question. When you’ve finished, at each stage decide what the most common wrong or less-than-best-practice actions would be, checking that you’ve covered all the ones you thought of in the planning stage. Don’t feel you have to have a set number of choices on every screen. Often there will only be two realistic choices, sometimes only one. Then create a new 'node' for the real life consequences of each one.
Re-ordering and tracking
When you’ve finished you’ll have something like the example above but without the tracking. You then have two tasks:
- Jumble up the options for each scene so that the ‘best’ one isn’t always first
- Add the tracking. Make sure you know what the minimum and maximum anyone could get for a particular score will be. This is tricky and will probably be revised when you have it in code.
There's nothing much to say about the coding side of it as it was all our internal templates - there are dedicated tools on the market of course, but we haven't found anything that provides the flexibility of tracking your own variables in code. Of course if you didn't have HTML developers that would be a different story - the other tools would enable the SME to create the product themselves. But for us 80% of the effort was in the planning and scripting- creating the product itself took less than a day for each one. They were then trialled with some trainers and recent trainees, and a day or two of edits produced the final version.
Comments