Creating scenarios (2)

Today we had the first scripting session to follow up the scoping call discussed in my previous entry.

One of the members of the team had to bow out, so I had two SMEs and a colleague who was observing. One of the SMEs, S, had come equipped with some stories, the other, J, with some learning points. But when we started the discussion it was obvious the learning points were along the lines of 'they need to understand that …' and 'they need to be aware of …'.  These had to be converted into something more behavioural – 'in this situation, how would you know the person understood that …  What would they do or not do?.

We worked through these stages:

1) What's the situation (story) with best and worst outcomes, in a single sentence.
2) what are the learning points?  These are expressed as a list of actions that the 'good' protagonist will take. They might be positively expressed 'go to xxx system on the intranet' or negatively 'don't respond to pressure to take a shortcut'.  At this stage it's an incomplete list as more emerge when we put flesh on the bones of the story. At the outset we had five, by the end of the meeting, seven. (These form the basis of a Javascript array / checklist in the final coded product.)
3) what's the obstacle? It's good to throw in at some point an unexpected (but realistic) spanner in the works.  In this case a colleague pressuring you to shortcut the 'correct' procedure to save time.
4) what's the rough flow of the story?

Up to this point we were still in talking and flipchart mode. It wasn't plain sailing as it took some time to identify a protagonist and situation that enough of the learner group would identify with, but who would realistically be likely to meet all the elements of the story. We were hampered by the SMEs being SMEs in the policy but not in the day to day work in offices. In our organisation it's very hard to get input from the 'bottom line' especially from the retail parts of the business where any attempt to take them away from public-facing work even for a day is strongly resisted. In this case we had to agree that the SMEs would take the complete script away for an informal reality check with colleagues. If we'd tried to make this a formal part of the project as I'd have liked to, there would have been too many hoops to jump through.

We then set up a new project on my laptop in Quandary. It gives you a quick and easy interface to design branching scenarios. We went through the central flow we'd put on the flipchart, making a page for each action and adding as links the action that would take you to the next page. The 'good' path turned out to be about 8 screens. Getting something like the final wording and agreeing the correct action led to the addition of a couple more learning points to the checklist.

Finally we went to each page and put some less desirable (but still realistic) choices. One or two of these led back to the main path, but two led to completely different sub stories, each with an unhappy ending that pointed out the benefit of using the correct procedure.

The final stage of the meeting was for my two SMEs to bash the Quandary version to see that each link went somewhere and that the different paths made sense when they converged.  With a couple of exceptions they did.

The session had taken three hours. At the end the SMEs had a clearer idea of what preparation they needed to do before starting another scenario. I output the rough script to Word so they could check it for accuracy and realism.

When they come back with revised versions the next stage will be to code it into our templates, with the Javascript tracking. Or perhaps we'll be ready to script another session first.

Item added to cart.
0 items - £0.00