3 cool ideas to steal for your training scenarios

Looking for inspiration for your training scenarios? Here are some ideas from the world of fiction that you could try.

1. Offer multiple levels of backstory

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.

Example of branching scenario with multiple levels of backstoryArcane 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.

2. Display the backstory in the margins

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.

Example of branching scenario with backstory in the margins

3. Show how the story changes

Example of an interactive comicThis 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.

More posts about scenarios and interactive fiction


Design challenging scenarios that your learners love

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.

Branching or mini scenario: which do you need?

Scenario-based training design: Branching or mini scenario?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.

Mini-scenario: Short but mighty

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 real-world decision is self-contained. You might make the choice as part of a longer conversation or process, but its consequences don’t seriously affect anything later in the process. An example: “Andreas, a 33-year-old single man with no health issues, wants a health plan with international coverage and no copay. Which plan do you offer?”
  • You want to help people practice the same task with different variables. The health insurance example could be repeated with several other customers, including a 55-year-old woman, a couple planning to have a baby, etc. You don’t need to practice the entire conversation; you just practice recommending the right product.

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

  • Employees of a hotel need to quickly recognize and report possible child trafficking in many situations (at the check-in desk, in the parking lot, when cleaning a room, etc.). The basic decision is, “Is this suspicious enough for me to contact the authorities?” The mini-scenarios let them practice that quick decision in many situations, and people see only the scenarios that are relevant to their job roles.
  • People providing in-home care need to decide what to do when asked to administer medication they might not have been trained to administer. They can practice with several different types of patients, medications, and situations, including emergencies.
  • Bank cashiers need to practice deciding whether checks presented for deposit are acceptable, and how to respond to the customer presenting the check.

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.

Branching scenarios

Examples of branching scenariosA 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:

  • Recognizing and recovering from mistakes, especially when the recovery might require several decisions (see this post for more on this)
  • Making decisions in extended, ambiguous situations
  • Deciding when to stop gathering information and act

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:

  • There are multiple grey areas — multiple decision points where people make a judgment call that can pull them on or off track.
  • Decisions made at one point limit or expand the options available at another point.
  • People commonly make a mistake at one point in the process and need to recognize and recover from it later.

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.

Teaching scenario, aka “control-freak scenario”

Example of branching scenario that doesn't branchA 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.

There’s a lot more in my book and blog

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.


Own Map It? Please leave a review!

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!

Design challenging scenarios that your learners love

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.

Mini-scenarios: How to help people recover from mistakes

In a previous post, we looked at some ways to help people learn from their mistakes in branching scenarios. How can we do the same thing in the much more limited world of the mini-scenario?

How to design scenarios to help people recover from mistakesA mini-scenario is a one-scene story in which the player makes a choice, sees the consequence, and that’s it. The consequence could be a fast-forward peek into the future, but the player makes a decision in just one scene.

Mini-scenarios are far easier to write than branching scenarios, but they can be limited.

Let’s look at ways to break out of those limits and help people practice recognizing and recovering from mistakes.

Have me recognize and fix someone else’s mistake

Let’s say that I’m a salesperson who needs to learn how to manage sales conversations with Martians. This involves some cross-cultural fancy stepping. To help me practice recognizing and recovering from mistakes, you could write a mini-scenario like the following.

You’re going to coach Bob through a sales conversation with a Martian. He’s wearing a mic so you can hear the conversation and has an earpiece to hear your suggestions.

He has arranged to meet his prospect, Jrod, at Starbucks. You’re already in a nearby booth, pretending to work on a laptop.

When Bob arrives, Jrod is sipping a frothy drink that’s topped with whipped cream and sliced ham.

“That looks delicious,” Bob says. “It would never occur to me to add ham.”

Jrod looks steadily at Bob without saying anything.

What do you say to Bob?

A. “Keep praising her good taste. Martians like to feel superior to humans.”
B. “Quick, change the topic to the solar storm we’re having. You’ve gotten too personal.”
C. “Don’t freak out. Martians are quiet at first. Tell her something about yourself.”
D. “Stop making small talk. Martians want to talk business immediately.”

This sounds like the beginning of a branching scenario, but it’s a mini that focuses on one specific skill — starting out right with a Martian prospect. The decision happens in one scene, and the consequence ends it.

Maybe if I choose D, “stop making small talk,” I get the following consequence.

“So,” Bob says heartily. “I understand you need some widgets.”

“Is there someone else I can talk to?” Jrod says. “Is there a Martian on your staff?”

Explore other options.

The story has ended, because we’re just practicing the opening of the conversation.

Obviously, it’s not a happy ending, and I don’t need you to tell me that, so you don’t. You’ve just shown me the unhappy consequence, and now you let me go back so I can learn a better approach.

I click “Explore other options” and go back to the original question. Maybe this time I look at the optional help you’ve provided and which I ignored the first time.

Now I choose A, telling Bob to keep praising her good taste. Here’s the consequence.

“I’ve always admired the Martian ability to combine flavors,” Bob says. “And colors! No human would think of wearing a purple cape with green shorts as you have.”

Jrod sips her drink. “I need 5,000 megawidgets by Friday,” she says. “Would this be possible?”

Explore other options.

It looks like I’ve chosen well and the conversation is now going in a good direction. If you want to make it abundantly clear, you could add a paragraph that fast-forwards the story to describe how Jrod ends up buying 10,000 megawidgets.

However, even though I’ve gotten a good ending, I still have the chance to “explore other options.” I could go back and try other things, seeing the consequences of other options, learning more about cross-planetary communications.

What did you just do?
You used a one-scene mini-scenario to help me practice one isolated skill: How to start on the right foot with a Martian prospect.

You combined error recognition and recovery in one scene. I had to recognize what error, if any, Bob has made, and tell him how to fix it. In our example, Bob actually started out well, so I also had to practice recognizing and continuing the best behavior.

Have me fix my own mistake, but risk annoying me

Above, you had me recognize whether someone else has made a mistake. You could increase the pressure by having “me” make the mistake, but you also risk ticking me off. You might have me make a mistake that I’m sure I wouldn’t make in the real world.

Here’s how it could look.

You’ve just been called by Hofdup, the widget decision-maker for a Martian company.

“We may need a large number of your widgets,” Hofdup says. “However, you would have to reduce the price 85%.”

“May I ask how many widgets you’re interested in?” you say.

“No, you may not,” Hofdup says, sounding offended.

What do you say now?

A. “To determine if the discount is possible, I need to know the number of widgets.”
B. “I’m sorry, I realize that you know best. I would be happy to discuss this with you in your office.”
C. “I meant to say that…”

I might already know that you don’t question a Martian early in the conversation, but you had me make that rookie mistake. And now you want me to clean up after a mistake I like to think I would never have made.

So use “you” with caution, only when you’re sure that your players would make the mistake themselves. Otherwise, it’s probably safer to have someone else screw up.

Avoid the temptation to write a storyfied knowledge check

I’m a scenario purist. I think an activity earns the label “scenario” only if the player is making decisions and seeing realistic consequences.

You or your stakeholders might not be quite so pure. As a result, you might write something like this:

Martha has completed the TPS form for the Acme project. See the form.

What will happen if she submits this form?

A. The client will be charged too much.
B. The form will go to another analyst instead of the customer satisfaction rep.
C. She will have to create a second TPS form because she left out a widgetification step.
D. The project will start as planned and the customer will be notified.

The above options only let me demonstrate my ability to recognize errors. They don’t let me resolve those errors. I don’t take any actions like I would in real life.

I’ll also get finger-wagging feedback. If I choose C, I’ll get something like, “Incorrect. Martha has included all the widgetification steps, but she’s charging the client too much. She has added a…”

Instead, combine error recognition and resolution as you did in the first two mini-scenarios, maybe like this:

Martha has completed the TPS form for the Acme project. See the form.

What should she do now?

A. Remove the unnecessary dewidgeting fee from the client total.
B. Change the address so the form will go to the customer satisfaction rep.
C. Add another widgetification step.
D. Submit the form so the project starts on time.

You’re still testing the same knowledge, which in learning objective land might be “Recognize common errors in TPS reports.”

But you’re also testing my ability to fix those errors, which is what we really want. “Recognize common errors” is an enabling objective for what really makes a difference on the job, which is “Submit error-free TPS reports.”

In the rewrite, you’ve combined error recognition with error fixing. This time, I get “showing” feedback that continues the story. Instead of wagging a finger at me, you let me draw conclusions like the adult I am.

For example, if I have Martha add a widgetification step, I find out that the project took longer than Sales promised due to excessive widgetification and the client demanded a partial refund as a result.

When do you need a branching scenario?

As we saw in the previous post, a branching scenario can help you provide more realistic practice in recognizing and recovering from errors. Rather than focusing on just one step of a longer process, you can help people practice recovering from early mistakes at several points in the process, with different consequences.

However, there are other reasons to choose one type of scenario over another. In the next post, we’ll look more closely at how to decide between a mini-scenario and a branching one. Sign up for blog updates to make sure you don’t miss a post.

Photo credit: Matt From London Flickr via Compfight cc


Scenario design course open for registration

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.

New: Invite me to your workplace to brainstorm

In a one-day visit to your workplace, I’ll help you:

  • Identify and conquer the forces that are inspiring information dumps
  • Help your team transition from content producers to valued performance igniters
  • Establish new procedures that make it easy for everyone to create activity-rich materials
  • More deeply embed action mapping in your workplace

I’m available around the world and will be in New Zealand in mid-May. Learn more.

3 ways to help people learn from mistakes in branching scenarios

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.

First, identify why I make mistakes on the job

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.

  • Make sure your options include the common mistakes, cleverly disguised as reasonable choices.
  • Add time pressure to the story, if it’s realistic. For example, in the story, the problem has to be resolved ASAP.
  • Add emotional pressure. For example, if managers aren’t addressing possible addictions among staff because they “don’t want to pry,” make the possibly-addicted worker in the story clearly unwilling to talk, to make the “I don’t want to pry” resistance more intense.
  • Have other characters tempt the player to make a common mistake. For example, if “everyone knows you should do X” is a common misconception that’s causing mistakes, have a fictional colleague say “Hey, you should do X” just like they do in the real world.
  • Add debating advisors. Recreate the type of confusing debate that can lead to mistakes by having “helpers” offer conflicting advice. See Connect with Haji Kamal for an example.
  • Have players debate among themselves. If you run the scenario in small groups, require each member of the group to defend a particular choice whether they agree with it or not. For example, Pat always has to defend option A, Kyle has to defend option B, and so on. There are several other ways to use scenarios in live sessions.

Then decide what you want me to do

The answer to “Should they be able to change their decision?” depends on what you want players to do.

1. Learn a brand new thing by doing it

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.

2. Practice recognizing and recovering from mistakes in a thing I already do but don’t do well

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:

  • Recognize that I’ve made a mistake (notice that the buyer is starting to lose interest)
  • Find a way to recover from the mistake

The flowchartI 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.

Example of mistake recovery in branching scenario

3. Practice doing a scary thing until I feel confident

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.

“But we need to assess them”

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.

How can you do this with mini-scenarios?

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.


Scenario design course open for registration

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.

New: Invite me to your workplace to brainstorm

In a one-day visit to your workplace, I’ll help you:

  • Identify and conquer the forces that are inspiring information dumps
  • Help your team transition from content producers to valued performance igniters
  • Establish new procedures that make it easy for everyone to create activity-rich materials
  • More deeply embed action mapping in your workplace

I’m available around the world and will be in New Zealand in mid-May. Learn more.

Scenario design: The process

Process for designing scenario-based trainingI’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:

  • Analyze the problem! Make sure you understand why the task is hard to do properly.
  • Prototype first! Write one decision point and get approval for that before you write another word.
  • For a branching scenario, sketch and test the plot before writing the story.

Here are the details, mostly copied from my book Map It. For lots more about every step, see the book.

1. Analyze everything. Don’t skip this!

  • Write a project goal. Identify how you’ll measure success for the project as a whole.
  • List the specific, observable actions people need to take on the job to meet that goal. Prioritize those actions.
  • Will training help flowchartFor 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.
  • Note the non-training solutions you’ve probably discovered from the above discussion, and identify the behaviors that will probably benefit from practice activities.
  • Identify the best format (live, elearning, etc.) for each activity idea and the best time for the person to use the activity (such as right before performing the task, in short sessions spaced out over time, etc.). Don’t assume a “course” is the best solution, because it rarely is.
  • If the skills addressed in the scenario are complex or controversial, determine how you’ll provide a debrief or other way for people to discuss issues and see the larger picture.

2. Prototype one decision point

First, draft one challenging question.

  • Pick a typical behavior that will be addressed with a scenario activity. You’ll turn it into a prototype decision point. It can be a standalone mini-scenario or one decision point in what will become a branching scenario.
  • Interview your SME for the prototype activity. Get the understanding you need to create a believable question, tempting options, and realistic consequences for those options. Capture the common mistakes and why people make them in addition to the best choice and what makes it difficult to make.
  • Example of a scenario prototypeWrite 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.
  • Write the options. Include the common mistakes that the SME identified and make them sound like good choices.
  • Write unique feedback for each option. Show the consequence of the choice by continuing the story. You might also provide instructive feedback (“You should have done X”), possibly as an optional explanation, but first show the consequence.

Next, add any supporting information, and make it optional.

  • Decide what is the minimum information the player must have to make the decision in your prototype.
  • Decide when and in what format you’ll provide the minimum supporting information. My usual recommendation: Put it in a real-world job aid, if that’s appropriate, and have people refer to the job aid when they’re considering the question. Don’t present the information before the activity; let people pull it if they need it. Also provide a snippet of the information in the feedback to reinforce or correct each choice.

3. Test the prototype before you write another word

  • Create a mockup of the prototype decision point and test it on the SME, client, and a group of learners. If the prototype is a decision point in a longer scenario, describe the bigger story that the question is part of, but don’t write it yet.
  • Your prototype will help determine how people will choose options, what information they’ll have available and when, whether they can go back to make a different choice, how they receive feedback, and what the feedback contains.

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.

4. Branching scenario: Additional steps

Once your prototype is approved, you’ll:

  • Identify the story endings. You might have one “best,” some “fair,” and a few “poor” endings. Decide in general what decisions a person would make to reach each ending.
  • Write a high-level plot as a The flowchartflowchart 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).
  • Consider writing the best path first and then filling in the less-good paths. Connect paths so players can realize that they’re heading toward a bad ending, make a better choice, and end up on a better path.
  • Get feedback on the plot. Consider including future learners in the review. You’ll probably need to describe what happens, since you’ve written only notes. Make sure the plot is realistic and complex enough to be challenging. Most first drafts are too simple.
  • Once the plot is complex enough and approved, flesh out your notes to turn them into a story.
  • Write debrief questions as you flesh out the plot. You’ve probably chosen a branching scenario because the skill to be practiced is complex and full of grey areas. Help people see the big picture and process what they’ve learned by planning to ask thought-provoking questions during a debrief.
  • Get feedback on the complete story. Again, I recommend including learners in the review.

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.

7 ways to make dialog sound natural

“Upon examining the data,” your scenario character says, “I have become increasingly uncomfortable with the proposal, specifically its requirement that we induce wombats to fly.”

Who talks like that? No one in the real world. However, you might find your scenario characters talking like that in your first drafts. Here’s how to fix it.

Droid turns into a human

1. Make sure you’ve actually written dialog. Show, don’t tell.

Not this: Barbara says she is concerned about the delay in processing TPS reports.

Instead: “It takes too long to process TPS reports,” Barbara says.

Let the readers draw conclusions like they do in the real world.

Not: Peter doesn’t want to talk about what happened at his previous job.


“Peter, what happened at your last job?” Louise asks.

“Who wants coffee?” Peter says. “I’m going for a refill.”

2. Start late. You might be tempted to write the small talk that starts a conversation, so it sounds realistic. Instead, fast-forward to the meat for more impact. Imagine how a movie would show it.


Jason goes to Emma’s office.

“Good morning, Jason,” Emma says. “Thank you for coming in. I know it’s a long trip for you.”

“I’m happy to help,” Jason says. “What can I do for you?”

“Well, the auditors called me yesterday, and…”


Jason goes to Emma’s office.

“I need to cancel our account,” Emma says. “The auditors found problems.”

3. Use contractions: “She is our best chainsaw juggler” becomes “She’s our best…” Not allowed to use contractions? Fight back with the tips in this post.

4. Don’t stuff the dialog with story. If they wouldn’t say it in real life, don’t make them say it in your scenario.

Not: “Diane, I’d like to hear your opinion about how to handle cultural differences on the new Zeko project, since you have been with the firm for eight years and have worked on numerous projects with companies in Zekostan.”

Instead: Bob calls Diane, who has eight years’ experience on Zeko projects. “How should we handle cultural differences on the new project?” he asks.

5. Choose informal words. “Wish” becomes “want,” “assist” becomes “help.” Find simple alternatives in The A to Z of Alternative Words (PDF) from the Plain English Campaign.

6. Break sentences into fragments of different types. It varies the rhythm, makes people sound more human, and gives them character.

Not: “If you want to play the banjo, you will need to go outside.”

Instead: “You want to play the banjo? Go outside.”

7. Use “said” and “asked.” Avoid having people “growl,” “smile,” “snarl,” or “laugh” their lines, which gets distracting and over-dramatic.

Often, you don’t even need “said.”


“How much are you willing to invest?” Jorge asks.

“Ninety bajillion dollars.” Andrea opens her briefcase. “I have it right here.”

Scenario design workshop: A few seats are still available

Want to improve your scenario design skills? There are some seats available in the scenario design workshop that starts on November 8. You’ll apply what you’re learning to a real-life project from your job. We’ll meet in the afternoon in Europe and mornings in the Americas.

Scenario-based training headquarters

I’ve gathered a lot of ideas about scenario design in one spot. You’ll find example scenarios, design tips, research summaries, and more.

I hope to see you at Learning Pool Live

I’m joining Learning Pool Live in London this Thursday, October 20, to give a keynote and short workshop. I hope to see you there!

Scenario example: Chainsaw training!

What’s the best way to teach people to cut down a tree? Probably the best way isn’t the approach recommended in this scenario. However, the scenario isn’t supposed to be realistic. I wrote it to make a point.

Try the scenario below. Do you agree with my point?

(The scenario is embedded in the blog post. If you’re reading this in email or a feed reader and don’t see a clickable interaction, go to the blog post to play it.)

Photo by Stewart Black cc. Scenario was developed in Twine.

Spoiler alert! Play the scenario before you read on.

If you’re familiar with action mapping, you probably saw what I was trying to do. The best ending to the scenario required you to do some (extremely quick) analysis of why it’s hard to cut down a tree without squashing your house or car.

The analysis asks, “What decisions do people have to make? Why are those decisions tricky? How can we help people practice making the decisions in a safe place?”

Then your design focused on helping people practice the tricky things that would directly support the goal of reduced property damage. You didn’t push information into their heads and then see if they could recognize it on a test.

Of course, it’s important for customers to know the obvious stuff, like how to hold the saw when you’re cutting into a tree. We’d certainly cover that in the videos. Unfortunately, it’s tempting to focus only on that obvious stuff. The result would be “How to Use a Chainsaw” and not what we really need, which is “How to Use a Chainsaw without Destroying Your House.”

I learned to cut down trees the way most people probably should: A more experienced person went into my woods with me. He helped me analyze each tree, set up the winch and rope, plan the cut, and adjust when things began to veer horribly out of control. But if that weren’t possible, I’d look for training that let me practice the decisions in a safe place.

What do you think? Let us know in the comments.

More scenario examples

I’ve set up a scenario design headquarters on my site. In that section, you’ll find more scenario examples, along with a research summary, a link to all scenario posts, and some tips on using Twine, the free editor I used to create the scenario in this post.

Related posts

For more on letting people learn from their mistakes, you might check out these posts:

Scenario mistakes to avoid #2: “Eat! Eat! You need to eat!”

“You need to eat more!” she says, heaping your plate until it rivals Mount Everest. “Eat! Eat!”

We all know the stereotype. Unfortunately, we can find ourselves turning into that stereotype when we feed information to people.

“You have to know this!” we say, filling the screen to bursting. “And this! And this!”

A huge platter of paellaIn scenario-design land, we can find ourselves doing this:

“First we’ll feed them everything they need to know, and then we’ll feed them some more as we show them how an expert does it, and finally we’ll let them waddle, overstuffed and dazed, through a scenario.”

Example, only slightly exaggerated

In the first post in this series, widget technicians had to diagnose squealing widgets. In the “Eat! Eat!” design approach, we’d “teach” them this way:

  • Tell the “widget story” — how widgets were invented and our company’s proud role in widgets’ ascendence to importance.
  • Explain how prompt customer service has helped us stand out in the widget field.
  • Explain that despite the stellar quality of our engineering, any widget could eventually develop a squeal.
  • Show a video of a squealing widget.
  • Show all the moving parts in a typical widget and what they do.
  • Explain that most squealing widgets have a wobbling synderhobble, and the squealing will stop when the synderhobble is screwed back into place.
  • Open a squealing widget, point to the wobbling synderhobble, and screw it back into place.
  • Say, “Now you do it.”
  • Watch as the “learners” obediently imitate what they saw five seconds ago by opening their widgets and screwing the synderhobble back into place.
  • Display a bulleted list of the other, less common causes of squealing widgets.
  • Move onto the next topic: Wobbling Widgets.

What’s wrong with this?

We make people eat when they’re full

We assume that everyone in the audience is equally and profoundly ignorant of the topic. But our audience consists of adults with decades of experience tinkering with gadgets — that’s why they signed up to be widget technicians. Some of them have already worked with widgets or with widget-like technology. Yet we stuff them with information they might already know, slowly suffocating what motivation they might have had.

We make people rely on short-term memory

Worse, our “scenario” came immediately after we showed them what to do. We used a version of “tell, show, do” that short-circuits independent thought.

Mike, a new widget technician, watched us screw the synderhobble into place, and 20 seconds later he had half-heartedly imitated what he saw. He was actually thinking about the vintage motorcycle he’s been taking apart in his garage.

Did Mike learn what we wanted him to learn? Was the behavior we wanted “Screw a synderhobble into place?” or was it “Correctly diagnose the cause of a squealing widget?”

Screwing the synderhobble into place is easy. Correctly diagnosing the cause of a squealing widget while an irritated customer waits impatiently is much harder. But instead of having people practice the hard stuff, we fed them the answer immediately and had them practice the easy task.

An alternative

The first post in this series describes an activity that would help Mike practice the harder stuff: He’s on a fictional phone call with a customer whose widget is squealing.

We haven’t shown Mike the history of widgets, and we haven’t told him that the most common cause of squealing is the synderhobble. We’ve just plunged him into the fictional phone call and provided optional help.

In elearning, that optional help could be links, such as:

  • A downloadable job aid: “How to Diagnose a Squealing Widget”
  • A short presentation, “The Moving Parts in a Widget,” that’s always available online

In face-to-face training, the optional help could be a printed version of the job aid and a link to the presentation on everyone’s smart phone. Since technicians often go into the field, this information needs to be portable.

When he’s in the scenario, Mike can look at the help or not, depending on his pre-existing knowledge and his willingness to try and possibly fail. The feedback shows the consequence of his choice, as described in the previous post.

Mike has to think on several levels: What do I know about this already? Is it accurate? What could be causing the squeal? What should I try first? And when he looks for information, it’s because he wants it. The information is a tempting buffet, not a mass forced-feeding.

Mike thinks hard and practices the hard stuff — diagnosing a squealing widget. He’s not daydreaming about the vintage motorcycle, and he’s probably more likely to transfer what he learned to his job. We’ve also made transfer easier by giving him a job aid and some information that’s always available on his phone.

I rant about this a lot, in posts like the following:

For the research supporting this approach, see Where’s the research support for scenarios? in my knowledgebase, the research cited in the post Throw them in the deep end, and books that summarize learning research, including Make It Stick: The Science of Successful Learning and Design for How People Learn.

Action mapping workflow available as an interactive graphic

Action mapping workflowWith help from readers’ feedback on the draft version, I’ve improved the action mapping workflow and summarized it in an interactive graphic.

You can download the graphic and a Word version of the workflow from that page.

Photo credit: Platter of paella by Joanbrebo via Compfight cc

3 quick tips for strong scenarios

Tips and tricksIt can be hard to write subtle scenario questions. Here are some techniques that can help.

1. Put dialog in quotation marks.

This trick helps ban the bureaucratic from your writing. Instead of paraphrasing what people say, stick it in quotation marks and it will magically rewrite itself. Here’s an example.

Before: Nuria has been wrangling widgets for three weeks and is frustrated. It is difficult for her to determine the correct wrangling angle.

During: “I am frustrated,” Nuria says. “I have been wrangling widgets for three weeks and it is difficult for me to determine the correct wrangling angle.”

After: “This is driving me nuts,” Nuria says. “I’ve been wrangling widgets for three weeks and I still can’t get the angle right.”

The minute you put your dry prose in quotes, you realize how very dry it is. Then it becomes easy to make it sound more natural. This trick also moves you from boring “telling” to more vivid “showing.”

2. Ask, “Why aren’t they doing it?”

In action mapping, you set a business goal and list what people need to do on the job to reach that goal. And then for each important task, you ask, “Why aren’t they doing it now?”

Unfortunately, it’s common to skip that question and go straight from “Here’s what they need to do” to “Here’s an activity that will help them practice doing it.” This often results in a scenario question that’s generic and too easy.

Instead, take a little time to identify the main barriers to performance: “Why aren’t people wrangling widgets well?” You might talk to a few people who do the job and use this flowchart to guide the discussion. You’ll find out if training will really help and, crucially, you’ll learn the challenges that people face. You’ll have the understanding you need to design subtle scenarios that target what’s really causing the problem.

3. Branching? Start with the end in mind.

Before you write any part of a branching scenario, think of the endings that will make the points you want to make. You might aim for one best ending, a few “fair” endings, and some “poor” endings. Then write a high-level plot that provides several intersecting routes to those endings. You might first write the “best” path and then add the less-great paths. Test your plot on subject matter experts and some future learners to make sure it’s realistic and not too easy. Only then is it safe to start fleshing it out with dialog and details.

What techniques have you discovered that help you write strong scenarios? Let us know in the comments.

Scenario design course: New sessions available

Two new sessions of my four-week, hands-on scenario design course have been scheduled, starting on Oct. 28 and Feb. 10. Learn more about the class and sign up for future announcements here. The action mapping book used in the course will be published this year; I’ll be sure to announce it in the blog when it’s available.

Tips & tricks image © Aquir and iStock

Is it ever okay to be a control freak?

Here’s a short scenario that uses a particular type of structure. What do you think about it?

Sample scenario

Spoiler alert! Play the scenario before you read on.

What type of branching is this?

Here’s how the scenario looks as a flowchart in BranchTrack‘s editor. No matter what we decide at decision point A, we all end up at decision point B. It’s like we have no free will!

linear scenario

If you’re feeling cranky, you could call this the “control freak” approach to scenario design: No one may advance without first making the correct choice, and then all people must advance as one obedient mass to the same scene.

If you’re feeling more generous, you might call it a “teaching” scenario.

It might be helpful for raw beginners

The extreme control exercised by the designer could actually be useful in the following conditions:

  • The people playing the scenario are beginners in the subject matter AND
  • We haven’t preceded the scenario with a bunch of information telling people everything they might need to know.

In other words, people new to the topic learn about it through a guided experience first, not through an information presentation followed by a “practice” activity.

Like this kind of discussion? Then you’ll like the scenario design workshops that I’m giving soon in Los Angeles, Chicago, and Sydney.

What could happen if we put the information first?

Let’s run an imaginary experiment. Let’s not start with the scenario. Instead, we’ll give our learners lots of do’s and don’ts about classroom management. We’ll follow that with a video of an expert talking about how honorifics like “Ms” supposedly squash students’ self-esteem, and then, finally, we’ll send them into the scenario to “practice what they’ve learned.”

Now that our learners are no longer absolute beginners, the relentless feedback and forced re-tries are likely to feel annoying and even patronizing.

“But we have to give them information!”

I agree, we do — after the scenario.

We can give people a chance to learn through the (very!) structured experience first, and then help them synthesize what they learned by giving them some reinforcing information. We can trot out the video expert after the scenario, for example, to reinforce the scenario’s message about honorifics.

Putting the scenario first does several things. It:

  • Helps people gauge their pre-existing knowledge, if any
  • Shows the learner through their mistakes that they need to learn this stuff, making them pay more attention to the information that follows
  • Gives them a concrete, memorable story with which to organize the more abstract information that follows, possibly helping with retention and transfer
  • Gives them beginner-level information in an engaging way, possibly motivating them to continue

For more on this activity-first approach, see my post “Throw them in the deep end!”

However, I still recommend true branching for most audiences

I focus on instructional design for adults in the working world. Most people in this world already have at least some previous experience or knowledge of the common topics covered in corporate training (how to treat people nicely, how to sell stuff, how to avoid breaking laws…).

As a result, I suspect that in most situations, a truly branching scenario would be more satisfying for the players. By letting people make mistakes, see the consequences of those mistakes, and draw conclusions, we’re saying, “I acknowledge that you’re an adult with a brain and life experience, and I trust you to be able to learn from more experience.”

Our careful handling of the branches, feedback at the ends of the paths, and optional help or resources along the way will help make sure that players are drawing the right conclusions without getting too frustrated. It’s all about choosing the appropriate amount of scaffolding for our audience.

For an example of a “real” branching scenario for people with some prior knowledge, try playing AutoLoon Ethics Training, which helps you practice your action mapping and consulting skills.

What do you think? And how do you manage stakeholders who want to be control freaks when it’s not appropriate? Let us know in the comments.

Design challenging scenarios that your learners love with my workshops this September and October in Los Angeles, Chicago, and Sydney. The first workshop is on Sept. 19 and spaces are limited, so check out the details and make your plans!

Get your free 23-page ebook: Training Designer's Guide to Saving the World