In the spirit of Working Out Loud, here’s the story of the template for writing elearning scenarios I’m now offering on this site.
I’ve worked a lot with subject experts writing scenarios over the years. In each case, it’s been in areas where I had no subject knowledge so it’s been up to the client to provide the detail. Up till now I’ve done it in two ways, each starting with a learning point and a rough synopsis.
- scripted it directly into Quandary, sitting with the expert, and starting with the ‘best’ route and then returning to fill in the less optimal routes. This provided a script which they could check and which I could use to build the authoring tool version
- followed the same process but straight into Storyline, without any graphics or formatting, just to get the basic structure
That process has served me well – especially as I’ve been working with small teams who didn’t need multiple stakeholder signoffs of each stage. We could have drawn a flowchart of the main routes first, and that’s a good method, but with these experts it seemed best to get stuck into the story straight away.
With a current client, however, I’ve had to look for a different way of doing it. We used the Quandary method for the first scenario, but it was then going to be four or five weeks before we could meet to write the second. I started looking for a way in which he could be working with others in his team on new scenarios without my involvement.
It seemed to me that if I could get them in their own time to go through the scenario thought process, rather than the actual story, then I could create the dialogue and interactivity myself. I wanted some sort of job aid that would ask them all the questions I’d ask, capturing the possible decisions and reasons for them; rather than being hypnotised by the technology, I wanted something like a notepad where they could scribble the thoughts as they came, score things out, and capture the flow of ideas in a way that typing into a laptop tends to inhibit. I wanted low-tech!
The good thing was that they had decided they wanted simple scenarios – one decision and its consequences – rather than a complex maze of decision leading to decision.
After a couple of drafts I came up with a 14-step process to capture things like the basic dilemma, why it’s stressful, the good choice and why it’s good (referring to principles that apply to different situations) and the equivalent for the less good choices. These are only the thinking behind the scenario, not the actual words. Those, and the ‘drama’ are up to the creativity of the scripter/developer (me).
The result is Designing Predicaments Workbook.
I tried it out at a meeting with three people from my client’s L&D team and they took to it immediately, to the extent that they suggested teams of their support workers would learn from designing scenarios themselves; this would develop them and at the same time give them a personal investment in the elearning. We used it to design a new scenario in around an hour. I’ve now taken that and written the words, drama and interactivity.
It’s early days and this is only the first draft, so I’m sure it’ll evolve as I collect feedback but I’m optimistic it will help new designers working with subject experts on scenarios.
You can download Designing Predicaments here. It’s a job aid, so it doesn’t contain a lot of talk; I’ll go through some of the key steps in a bit more detail in future blog posts.
If you download it and use it, please put add some feedback as comments here. I’m sure it can be better with your help.
Update Jan 2017
Since I wrote this I’ve written a lot of posts on scenarios including a video series on the Designing Predicaments steps.