By Cathy Moore
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?
A 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 toolkit now available
Design challenging scenarios your learners love
- Get the insight you need from the subject matter expert
- Create mini-scenarios and branching scenarios for any format (live or elearning)
It's not just another course!
- Self-paced toolkit, no scheduling hassles
- Interactive decision tools you'll use on your job
- Far more in depth than a live course -- let's really geek out on scenarios!
- Use it to make decisions for any project, with lifetime access
7 comments on “Mini-scenarios: How to help people recover from mistakes”
Comments are closed.
Dear Cathy, thank you very much for another very helpful blog post. However, I do have one question about the “fixing my own mistake” issue. I don’t really understand how the first example (me as coach) is different from the second one, in terms of “blame”, because in both it’s me who makes the mistakes. So I might annoy my learners with the first one as well, because they would never as a coach tell Bob to skip the small talk. To me it doesn’t really make a difference if it’s: What do you say to Bob? (S.1) or What do you reply to the Martian? (S.2). Do you understand what I mean?
Nina, thanks for your comment. I see your point, which is valid for any type of decision, even a multiple-choice fact check: If we include a “dumb” option as an answer, we risk annoying our learners.
My focus was more on two things:
(1) Who faces embarrassment “on the job?” In this case, the real-world task is selling to a Martian, and the potential for embarrassment is doing something stupid in front of the Martian.
In the first example, Bob is selling to the Martian. He’s the one who could make the embarrassing mistake, and your job is to help him recognize & recover from it. While you could make a mistake in helping him, you’re behind the scenes. He’s the one who suffers the embarrassment on the job.
In the second example, you’re the one doing the real-world task, so you’re the one who could make the embarrassing mistake. You’re not hiding behind the scenes watching someone else suffer.
(2) Are we offering a dumb option, or are we forcing the learner to do something dumb?
If we include a “dumb” option in the advice to Bob, it’s still annoying to the learner. However, it at least doesn’t force the learner to imagine themselves doing a dumb thing in public, on the job, in front of the sales prospect. The annoyance is probably more like “The training person who wrote this included a ridiculous option that I obviously would never choose.”
In contrast, if the training designer describes *you* as doing something dumb, it’s in public, and you had no option. You weren’t choosing among actions that included a dumb thing; the designer *made* you do the dumb thing. This is more annoying, at least from my perspective.
Thank you for the explanation, Cathy. I get your points and it makes more sense to me now.
Love your posts so much that I often scroll to the bottom of the page.
I did this again today, but saw the copyright notification date, which is 2016.
Not sure, but should you change it to 2018?
Gavin, thanks for your concern. I’ll update the copyright notice as soon as I figure out how. 🙂
I really like these examples. It helps avoid the blaming. I don’t want to be like the teacher pointing out what’s wrong all the time. Please continue to give more examples. I’m working on the wording of questions and answers to avoid this punitive feeling.
Agree with Marie – the examples really help operationalize the guidance – keep’em coming! Especially liked the guidance on avoiding the knowledge check – helps me recognize and rectify this “bad” habit….