Looking for inspiration for your training scenarios? Here are some ideas from the world of fiction that you could try.
Branching scenarios often represent decisions that take place in a complex world.
For example, let’s say your scenario describes a manager, Sarah, who has to decide what to do about a long-term employee whose performance is suddenly slipping. In the real world, Sarah would have a long history with the employee that would influence her decision. That’s the backstory.
It can be hard to cram a lot of backstory into an online scenario. One way to do it is with links that provide snippets of history, as I describe in chapter 10 of my book. It’s common to do that in Twine scenarios.
Arcane Intern (Unpaid) by Astrid Dalmady provides two levels of this additional information.
For example, you can click to look inside “your” bag. Once you’re in the bag, you can click more links for another layer of information.
From those additional links, you can navigate one step back to the bag or all the way back to the waiting room.
The story also appears to require you to click the backstory links. In training-land, a stakeholder could argue that this sort of control is necessary to make sure players have the information they need later to make a good decision.
I’m not convinced, especially since I rant regularly that we should let learners decide how much information they need. If we let players decide how much information to gather, they’re practicing a skill they need on the job: They need to recognize what information they need to make a good decision, and go get it.
In most Twine games, when you click a link for more information, you go to another screen. But in Harmonia by Liza Daly, the extra information appears in the margins.
This approach could help reduce cognitive load — the player doesn’t have to juggle the information in short-term memory while also making decisions.
This prototype of a comic shows one story that you can change by clicking a different decision in an early panel.
Choose a different fruit in the second panel, and the rest of the comic changes to show the consequence of your choice.
You could create a text version of this. For example, you could display a short story of an event at work that has one clickable decision early on. The default text that displays shows the result of one branch of the decision. The player can read that, and then click the decision to see how the story changes.
This could be a way to satisfy a stakeholder who says, “Make sure they see the consequence of Common Mistake X!” I’d prefer to let players make decisions from the beginning like the grownups they are, but this is a compromise you might need someday.
Learn to design scenarios by designing scenarios, with my personal feedback: The June session of the live, online scenario design course is open for registration. There are sessions for people in the Australia-Pacific region as well as the Americas and Europe. Check it out.
You want people to practice making decisions in a situation that has grey areas — that’s perfect territory for a scenario. But what type of scenario do you need?
Will a one-scene mini-scenario be enough, or do you need to invest the (considerable!) time in creating a branching scenario?
Here are some ways to figure that out.
Just one question
A mini-scenario is just one question. It gives you a realistic challenge, you make your choice, you see the realistic consequence, the end. The consequence might be a fast-forward peek into the future, but you make a decision in just one scene.
The following is a bare-bones mini-scenario. Ignore the fact that I obviously made up the options. Look at what the scene is requiring you to do and what type of feedback you get.
Bill needs to pass a scalpel to Sara during surgery. What should he do?
a) Put the scalpel in a sterile kidney dish and hold the dish out to Sara.
b) Hold it by the neck and place the handle in Sara’s palm.
c) Put it on the surgical drape for her to pick up herself.
d) Toss it gently in her direction, handle first.
Feedback for b: Sara is distracted by a loose clamp and moves her hand just as Bill places the handle in her palm. The scalpel cuts Bill’s thumb.
The feedback shows the consequences. It doesn’t say, “Incorrect. You should never…”
Other people use “mini-scenario” to mean different things. For me, “mini-scenario” doesn’t mean an activity that forces people to go back and do it right, an easy activity, or something that happens only within a limited timeframe. The choice you make in a mini-scenario could have consequences that appear years later, but it’s still a mini-scenario by my definition because it’s just one decision.
Another way to look at it: You can make a mini-scenario using any multiple-choice question tool that lets you provide unique feedback for each option. It can be long or short, but it’s just one decision, so it’s a mini-scenario in my world.
When to use minis
Mini-scenarios are useful when…
The consequence of the player’s choice could happen immediately or in the future.
In the example with Andreas, if you choose the right plan, the feedback could say that five months later, Andreas gets hit by a bus in Zambia but is treated at no cost thanks to you having sold him the correct plan.
If you choose the wrong one, poor Andreas has to limp to an ATM and withdraw large amounts of cash.
So even though the consequence happens in the future, this is a mini-scenario because just one decision was required.
Examples where mini-scenarios are appropriate
String them together for a pseudo-story
A series of mini-scenarios can be strung together to create what feels like a story, but the consequence of one decision doesn’t determine how the next decision is made.
A typical example is a “day in the life” story of disconnected decisions. For example, we play the role of a security guard who has to recognize and resolve unrelated issues during the day. Our decision about the tripping hazard at 10 AM doesn’t affect what we do about the unlocked door at 1 PM.
You can dig pretty deep in a mini
Players make just one decision, but that decision can be difficult. See the previous post on using mini-scenarios to practice recovering from mistakes to see an example.
A branching scenario contains multiple questions (“decision points”). The consequence of one decision affects the next decision.
Two people going through the same branching scenario could see different questions and story lines.
Try these examples of branching scenarios if you aren’t already familiar with the format.
When to use branching
Branching scenarios are useful when a decision made at one point determines the input for a decision made later. A classic example is a tricky conversation in which you ask the wrong question, limiting the information you have to work with in a later part of the discussion.
They help people practice:
A common mistake is to assume you need a branching scenario if you want people to practice a longish process. However, you need branching only if:
If you decide that you don’t really need branching, you might consider offering several mini-scenarios that focus just on the tricky step in the process, as described in Mini-scenarios: How to help people recover from mistakes.
A third type of scenario might look at first like a branching scenario, but there’s just one path. Two people going through the activity will see the same questions because there’s only one way through the story.
To progress in the story, you have to answer “correctly.” If you choose a “wrong” answer, you’re forced to go back and try again until you get it right. Then the story continues.
I call this a “control-freak scenario,” because that’s how it feels to the player. You’re not allowed to experiment. You’re punished for bad choices by being made to go back and try again until you get it right.
Learn more about control-freak scenarios and when (rarely!) they might be useful.
My book Map it digs deep into how to design these types of activities. And to make sure you don’t miss another post in this series on scenarios, sign up for blog updates.
I have a favor to ask. Do you own my book Map It? If so, please consider leaving a quick review on Amazon to help others decide if the book will be useful for them. Thanks!
Learn to design scenarios by designing scenarios: The June session of the live, online scenario design course is open for registration. There are sessions for people in the Australia-Pacific region as well as the Americas and Europe. Check it out.
Let’s say I’m in your branching scenario, and I’ve made a not-great choice. You show me the not-great consequence of that choice. Now what?
Can I go back and change my decision, or do I have to continue in the story, looking for ways to recover from my mistake?
It depends on what you want me to practice. Here are some ideas to consider.
Your analysis of “What makes this thing hard to do?” has probably shown you many reasons why people make mistakes during the task.
First, fix what you can, such as by improving processes, tools, or job aids.
Then, if you decide that practice activities will help, create activities that tempt people to make the same mistakes they’re making on the job. In your safe, fictional world, they can finally see the consequences of their mistakes and practice recovering from them.
There are a bajillion ways to tempt people to make mistakes, which may someday become a separate blog post, but for now here are some ideas.
The answer to “Should they be able to change their decision?” depends on what you want players to do.
Recommended: “Explore other options”
If you want me to learn to sell widgets to newly-arrived Martians, first tell me that you aren’t tracking anything I do. Then throw me into a sales conversation with some optional help. As I muddle through, show me the consequence of each choice and include the chance to “explore other options.”
“Explore other options” can take me back one step or more, depending on how the conversation is structured, so I can quickly see how a different statement changes the conversation.
I’m learning by trying stuff out, so I should be encouraged to try stuff out. I shouldn’t be penalized for making a not-great choice.
Also, of course, you’re just showing me the consequence of my choice. You’re not interrupting with “Incorrect!” or other preachiness.
My not-exactly-realistic Chainsaw Training scenario is a learn-by-doing activity.
Recommended: Make me continue in the story, looking for ways to repair the damage
If I already sell widgets to Martians but don’t do it well, throw me into the sales conversation with optional tips, as above. However, when I see the consequence for a choice, I don’t have the chance to go back and “explore other options.” I’m stuck with that choice and its consequences.
If my choice was not great, I need to do two things, just like in the real world:
I continue the conversation, maybe finding a way to save it, and at the end of the scenario I see the final consequence. Only then do I get a chance to start over.
For this to work, the scenario has to have what participants in my scenario design course have called “redemption paths.” If I’m going down a not-good path and realize it, let me choose an option that will bring me to a better path.
Here’s an example from the Connect with Haji Kamal scenario. The heavier line shows the preferred path. At several points, I can realize I’m going in a poor direction and make a choice that brings me to the better path.
Below, I can realize that I haven’t continued the small talk enough. I can abandon my poor path and get onto the better one by asking about the haji’s family.
Recommended: At first, let me explore other options. Later, challenge me to recover from my mistakes.
Let’s say that selling widgets to Martians is fraught with cross-cultural risks. If I say something the wrong way, my Martian prospect could get so offended that interplanetary relations could be damaged.
This is a scary situation, so you’ll want to give me lots of practice in a safe, fictional place. Once I prove that I can make good decisions, you can let me do it on the job with real Martians.
One way to do this is to give me multiple scenarios that increase in difficulty. In the earlier scenarios, let me “explore other options” so I can see the effects of different statements.
Later, maybe when I’ve said I’m ready for a more realistic challenge, give me scenarios in which I can’t go back. I have to recognize and recover from mistakes before they escalate into interplanetary offenses.
If a stakeholder insists on a formal assessment, you can use the same type of branching scenario. However, this time, tell me you’re tracking what I do, and give me no chance to turn back the clock. Crucially, give me redemption options that let me get onto more successful paths when I realize I’ve made a mistake, just like in the real world.
If you were providing optional help that I should have internalized by now, remove it. Make me fly solo.
A scenario can be used this way to evaluate learning as described in Will Thalheimer’s new evaluation model. See it here.
A mini-scenario is a one-scene story in which I make a choice, I see the consequence, the end. It might seem like you don’t have enough room in the story to let people make and recover from mistakes, but there are some techniques you can use.
We’ll look at those in the next post in this series. Sign up here to be notified when the next post appears.
Learn to design scenarios by designing scenarios: The June session of the live, online scenario design course is open for registration. There are sessions for people in the Australia-Pacific region as well as the Americas and Europe. Check it out.
In a one-day visit to your workplace, I’ll help you:
I’m available around the world and will be in New Zealand in mid-May. Learn more.
I’m kicking off a series of posts about scenario-based training. Let’s start with the big picture: The design process.
Many people start writing a scenario too soon. They invest a ton of time only to find their work rejected by the client or learners.
Use the steps below to make sure you’re writing a challenging scenario and going in a direction everyone will like. It’s far easier to adjust a few notes than it is to throw out a story you spent hours writing.
The main takeaways:
Here are the details, mostly copied from my book Map It. For lots more about every step, see the book.
For the high-priority actions, ask, “Why aren’t they doing this now?” or “What might make this difficult?” First consider the environment (tools, systems, and culture), to avoid assuming that the problem comes entirely from a lack of knowledge or skills.First, draft one challenging question.
Write a stem. The stem is the setup and question for your decision point. Use the insight you got from the SME to recreate the real-life issues that tempt people to make the wrong choice.Next, add any supporting information, and make it optional.
If you’re creating one-scene mini-scenarios, once your prototype is approved, you can confidently crank out several more scenarios using the same format. Consider sending them to your SME in batches, so the SME can consider one batch while you write the next.
If you’re creating a branching scenario, you aren’t done yet.
Once your prototype is approved, you’ll:
flowchart or in a tool like Twine. Use notes only; don’t write a script. (I use Twine because I can complete all remaining steps in it, it’s flexible, and it’s free).See chapter 13 of Map It for detailed questions to consider at each review. And for lots more about scenarios and to get my help in writing your own, consider signing up for the next scenario design online workshop.
Are you expected to “train” everyone on new software? In my previous post, I recommended that you first try everything but training. Make the software easier to use (yes, it’s often possible!). Create job aids and help screens.
Did that work only partially? Are you convinced that people need formal training? This post is for you.
As described in the previous post, you’ve already:
Now you’re convinced that people need formal training as well.
Your organization might define training as, “Everyone goes to a room and is shown how to use the software” or “Everyone takes an online course that walks them through it.” They view training as a one-time event that’s delivered the same way to everyone, regardless of their pre-existing knowledge.
Let’s consider two marketing employees who are expected to learn MegaMailer, which sends promotional emails to subsets of customers.
Conventional MegaMailer training would force both of them to sit through a presentation about what is a database, record, and field. But Kate already knows all that. What’s a different approach?
“Let Kate skip the stuff about databases,” some people would say. “She can start with the presentation about MegaMailer’s interface.” But what if we go a step further?
We can avoid unnecessary presentations and provide spaced practice if we try this:
1. Create self-contained activities, not presentations
Consider plunging people into realistic simulations or scenarios in which they complete a task similar to the task on the job.
You could give them a faithful recreation of the software, some simple screenshots to click on, or the actual software, but using fake data (a “sandbox” where people can play safely).
An example activity for Ben and Kate could be: “We’re going to send a mailing about the MegaChomper BigBoy toy to all big dog owners. First, you’ll create a list segment of all customers who own dogs that weigh more than 15 kilos.”
Ben and Kate see this activity first, not a presentation about the software. They immediately begin using the software for the same kinds of tasks they complete on the job, but with optional help.
2. Link to basic knowledge instead of forcing everyone to see a presentation.
In the “create a list segment” instructions for Ben and Kate’s activity, the words “list segment” could be linked. Kate already knows what that means, so she doesn’t click the link. Ben isn’t sure, so he clicks the link to learn the basics about lists and segments.
3. Provide how-to information as optional help instead of walking everyone through it.
People who are already familiar with the type of software will want to plunge in and try it. Others will want a lot of guidance. Make them both happy by providing optional guidance.
For example, when Kate sees that she needs to create a segment of big dog owners, she confidently jumps into the software because she’s done it before with another program and suspects it won’t be very different. Ben has a lot less experience, so he clicks “Show me how to do it” and sees a short video of the steps involved.
The amount of help could be tailored more finely. For example, Kate might like just a hint showing the first menu item to use. However, Ben might want a lot more help. In addition to the how-to video, he might like a second, more in-depth presentation that explains what a database is, how fields like “DogWeight” were created, how the information about dog weight got into that field, and so forth.
For an example of different levels of how-to help, see this activity for complex medical software, designed by Allen Interactions.
4. Start easy and build skills gradually
Choose simple tasks for the first few practice activities. In our imaginary example, creating a list segment is the first step to creating a mailing, and it’s also one of the easier steps. Maybe we’ll have Ben and Kate practice creating a few more segments before they move on to the more complicated step of using an HTML template to create the content of the email. This is a type of scaffolding.
For an example of in-activity scaffolding, see if you can learn Zeko. The story reinforces vocabulary you’ve learned so far while adding new terms.
5. Provide realistic feedback, if possible
Strong scenarios and simulations don’t stop you and say “Incorrect!” They just show you what happens as a result of your decision, and you conclude from that how well you did.
This can be tricky with software simulations, especially if the tasks are complex, with lots of ramifications. So this might be too much for your project, but for our imaginary marketing scenario, feedback might look like the following.
When should we show the feedback? That depends.
If Kate is just practicing list segmentation, we could show it immediately. She creates the segment, and we flash-forward to show the future result.
If she’s further on in the activities and is practicing the entire mailing process, we can withhold the feedback until the end. This is especially useful if our process includes a check step. Maybe the process looks like this:
This gives Kate a chance to recognize and fix her earlier error, as well as having her practice the entire process.
If she doesn’t catch her error, the end result will be annoyed emails from owners of small dogs, plus an optional explanation of what she did wrong. If she does catch her error, she can fix the segment before sending the email, and she sees the happy consequence of lots of MegaChomper sales.
In our example, we’ve created several standalone practice activities. Each one is self-contained because it links to supporting information. It’s not an activity trapped in the middle of a presentation.
As a result, people can try the activities as they need them. Maybe all the activities are linked on an intranet page. We can (and should) show a recommended path through the activities. But people can still directly access an individual activity.
This is especially useful for reinforcement. Let’s say that Ben carefully worked through all the activities about list segments and using the HTML template. He then was put on a project that involved creating lots of HTML emails while someone else created the list segments.
Two months later, Ben needs to create a list segment but has forgotten how. He goes to the bank of activities and chooses some list-segment activities to practice again. Once he’s confident, he creates the segments he needs for his current project.
This activity-driven approach might make intuitive sense, but intuition can’t always be trusted. Luckily, there’s also research that supports the plunge-them-into-it technique.
Again, you’ll want to provide structure, such as a recommended path through the activities, and carefully increase the difficulty with scaffolding. You want people to feel competent, not frustrated.
In a one-day visit to your workplace, I’ll help you:
NZATD in mid-May: I’ll be in Auckland in mid-May to speak and run an informal workshop at the NZATD conference, along with many other colleagues with valuable things to say. I’m also available for a few on-site consulting visits in the area.
Scenario design course for you: The June scenario design course includes a session for people in Asia-Pacific time zones. Check it out here.
Celisa Steele of the Leading Learning podcast recently interviewed me, with a focus on how associations can adapt action mapping for professional education.
This new page on my site links to several other recent interviews about action mapping and scenario design.
Is your eLearning budget stretched too tight for branching scenarios? This article features 8 budget-friendly tips to create realistic branching scenarios with limited resources.
This post was first published on eLearning Industry.
