Home / Learning & Development / Mini-scenarios: How to help people recover from mistakes

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…”
etc.

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.

Click Here For Original Source Of The Article

Ads by WOW Trk

About Mildred Blankson

I am a Human Resource Professional with a Masters Degree in Human Resource Management. I have several years of experience in Human Resources and i hope this blog will be a great resource in helping you find the perfect job or candidate that you seek.

Check Also

Branching or mini scenario: which do you need?

What type of scenario do you need? Will a one-scene mini-scenario be enough, or do you need a branching scenario? Learn more.

Leave a Reply

Your email address will not be published. Required fields are marked *

css.php