Training design – Cathy Moore View RSS

Is training really the answer? Ask the flowchart. 7 May 2023 11:43 AM (2 years ago)

How to handle the handoff conversation 23 Sep 2020 1:23 AM (4 years ago)

7 things to check before you design training 16 Jun 2020 9:30 AM (4 years ago)

“Show, don’t tell” — How do you do it? 6 Jan 2020 2:36 AM (5 years ago)

How to quickly find the cause of a performance problem 20 Nov 2019 8:51 AM (5 years ago)

By Cathy Moore

“Why” is a useful question when you’re getting to the root of a performance problem. But it has a more powerful cousin: “What for?” Here’s an example.

Your client, Joe, wants ethics training.

“People are lying when they file their performance reports,” he says. “They say they did more work than they actually completed. So I want you to create a one-hour course on ethics.”

You could obey and make grownups sit through a course that tells them it’s wrong to lie, or you could examine the problem more closely. Let’s examine the problem, and start with “why.”

“Why” is easy to dodge

“Why are people lying on their performance reports?” you ask.

“Because they don’t realize how important it is to be honest,” Joe says. “That’s why they need a course on ethics.”

Joe has answered your question in good faith, but you haven’t made any progress. Joe hasn’t seen any reason to doubt his assumptions.

Let’s rewind and try again, this time with “what for?”

“What for?” uncovers motives

“What do they lie for?” you ask.

“They want to look good even when they can’t do the work,” Joe says. “We have a competitive culture.”

Now we’re getting somewhere. Our next question can be “why” because we’ve steered Joe down a better path.

“Why can’t they do the work?” we ask.

“They have too much on their plates,” Joe says. “And if they ask for help, their managers tell them to stop whining.”

Obviously, a one-hour course on ethics will do nothing for Joe. And now he’s willing to look more deeply at the problem to find a better solution.

This is a variation on an example from the Partner from the Start toolkit, which helps you stop being an order-taker and steer clients toward the most effective solutions.

Another example

“Our patients complain that nurses are abrupt,” our client says. “The nurses just do their tasks quickly and leave. So we need a course on bedside manner.”

Why?
Q. Why are the nurses abrupt?

A. Because they don’t understand the importance of bedside manner. That’s why we need a course.

What for?
Q. What are the nurses abrupt for?

A. They don’t want to get drawn into a conversation with the patient, because they have to hurry to the next one. We’re understaffed.

There’s a solution to this problem, and it isn’t a course on bedside manner.

Listen to the types of answers you’re getting

We analyze performance problems to see if training really is part of the solution. If you’re asking “why” and hearing about alleged ignorance (“they don’t understand,” “they don’t think it’s important”), clients will continue to assume that training is the solution. To have them look deeper, try “what for?”

Discuss this post on LinkedIn.

 

3 classic tips for writing training scenarios 20 Aug 2019 8:33 AM (5 years ago)

5 new scenario-based training examples to inspire you 31 Jul 2019 6:25 AM (5 years ago)

By Cathy Moore

I’ve added several branching scenarios to this collection of scenario-based training examples, along with questions to help you evaluate the designers’ choices.

The new examples include five activities you might not have seen before:

• Can you convince Carla to analyze the problem instead of throwing a course at it?
• Your patient is HIV positive. Should you tell his wife?
• Your student is stressed and might be cutting herself. Can you convince her to talk to the counselor?
• Can you recognize gang activity and respond appropriately?
• Something is bothering Hana. Can you persuade her to talk about it?

You’ll consider several design decisions, including:

• What level of production is really necessary?
• Should players have to choose every word they say in a conversation, or just some phrases?
• How much information should we present, and how much can people easily figure out on their own?
• How often, if ever, should we interrupt with hints or correction?

Try the example scenarios.

 

 

Save your clients from themselves 7 May 2019 11:00 AM (6 years ago)

Burn your training request form 12 Mar 2019 6:28 AM (6 years ago)

By Cathy Moore

If your organization is typical, you have a training request form. Look at it now. It probably commits 10,000 sins.

For example, it might ask the client to:

• Identify the format and length of “the training”
• List the content that should be included
• Specify the date and location for “the training”
• Identify the number of people to be “trained”

With this form, you’re saying, “My job is to produce whatever training you want, whether or not it will actually work.” It turns you into a worker in a course factory.

If you want to have a real impact and win the respect of your organization, you need to set your clients’ expectations from the start.

1. Not “training” but “development”

If you must have a form, call it something like “development request.” Make clear your job is to improve performance, not create training on demand.

2. Don’t use the forbidden words

Throughout the form, avoid terms that refer to a specific solution. There is no solution yet. You won’t decide whether training is part of the solution until you’ve analyzed the problem.

For example, don’t use these terms in the form:

• course
• training
• workshop
• content
• blended
• assessment

3. Ask about the problem instead

Ask about the issue that the client is seeing. You might use questions like these:

• What change would you like to achieve with this project?
• How will you know that the change has been achieved?
• Who will change what they’re doing as a result of this project?
• How will the organization benefit?
• What has been tried in the past to bring about this change?

Your goal is to get an idea of the possible business goal and how the client currently views the problem. Both could change during your discussions with the client.

Template available

A development request form that you can adapt is now available as part of an online toolkit.

The Partner from the Start toolkit is a menu-driven series of challenges, guidance, downloads, and real-world tasks that will help you start projects right and avoid creating information dumps.

Discuss this post on LinkedIn.

 

Learning objectives: Our frenemy 8 Jan 2019 6:07 AM (6 years ago)

By Cathy Moore

“Never design anything without first writing the learning objectives.”

We all know this. It’s a useful rule, but only when the objectives are useful.

And there’s the problem — conventional learning objectives can work against us. They’re our friends, but not always.

What do I mean by “conventional learning objectives?” This sort of thing:

• List the three steps of widget certification.
• Explain the difference between widget certification and widget approval.
• Describe the widget supply chain.

Here are three questions that will help you set boundaries with our frenemy.

1. Do people actually need to “learn” something?

Conventional learning objectives might be your friends if both of the following are true.

1. A knowledge or skill gap clearly exists.
2. Closing that gap will help solve the problem.

Is there really a knowledge or skill gap? Maybe the problem is mostly caused by bad tools, an inefficient process, lack of incentives, or some other environmental issue. With your client and SME, first identify what people need to do on the job, and then walk through this flowchart before agreeing to develop training.

Will closing the gap solve the problem? Maybe it’s true that people don’t know the intricacies of the supply chain, but installing that information in their brains won’t make them better widget polishers. Don’t deliver content just because someone told you to.

2. Are we writing useful objectives for the formal training bits?

If our analysis shows that we really do need to design a learning experience, then, yes, we need objectives. Are the actions we wrote earlier good enough, or should we let learning objectives elbow their way into our project?

Here’s an example from my book.

Let’s say that we want firefighters to educate the public about preventing forest fires and quickly put these fires out when they occur. Our official goal is, “Fire-related losses in our region will decrease 10% by next year as firefighters prevent and extinguish brush and forest fires.”

Which of the following do you think I’d accept as actions to reach this goal?

a) Identify the techniques used to extinguish a brush fire
b) List the principal sources of combustion in a deciduous forest
c) Describe common public misconceptions about campfires
d) Quickly extinguish a brush fire in a dry mixed forest
e) Define “incendiary device”

If you said that only d, “Quickly extinguish a brush fire,” was an action by my standards, you’ve gotten my point.

An action is something you see someone do as a normal part of their job. It doesn’t take place in their head or in that abstract world I call Testland. The action should be the focus of our analysis and design, and it should be the statement we use to “sell” the material to the stakeholders and learners.

“But the other statements are good objectives!”

In the world of conventional instructional design, the other statements are also observable objectives.

For example, we can watch a firefighter write a list of the techniques used to extinguish a brush fire, and we can point at that list and say, “See? They know it.” And that’s the problem — we’re just measuring whether they know it. There’s no guarantee that the firefighter will actually apply this knowledge, which is what we really want and what we should be helping them do.

“Identify the techniques” is an enabling objective. It describes information necessary to perform the action. It goes in the information part of the map — I’d list “techniques to extinguish a brush fire” as required knowledge that’s subordinate to the action about putting out fires.

Our goal is to create realistic, contextual practice activities. We can do that only if we focus on what people need to do. If instead we let knowledge-based objectives distract us, we’ll create the usual information dump followed by a quiz, which is the approach that helps make us irrelevant.

3. Who needs to see the objectives?

The client

If you’re using action mapping, your client helped create the list of actions, so they’re already familiar with them. If you need to submit a formal document, I recommend an outline rather than a big design-everything-at-once document. (See this big interactive graphic of the action mapping workflow.)

In that outline, you can include your action map, which shows the actions and the information required by each. The actions are your main objectives, and the bits of information represent the knowledge that supports those objectives.

If your client wants to see conventional learning objectives, consider listing your actions as “performance objectives.” Then, indented and subordinate to each performance objective, list its enabling objectives.

I resist writing the enabling objectives using test language (“describe, explain, define…”) because that sets the expectation that there will be a knowledge test. Maybe some of the knowledge doesn’t need to be memorized and could instead be included in a job reference. It won’t be tested, so there’s no reason to write a test-style objective about it.

Or maybe people do need to memorize some stuff, but a separate knowledge test would be artificial. Instead, you could assess with the same type of activities you provided for practice, which would test not only whether people know the information but whether they can apply it.

The learners

Briefly tell people what they’ll be able to do as a result of the activity, and focus on what they care about. Put those over-eager learning objectives on mute because they don’t know how to sound appealing.

• Not this: “When interacting with a dissatisfied customer, appropriately apply the five steps of the Abrams-Martinson Dissatisfied-to-Satisfied Customer Transformation Model” that no one has heard of but a consultant convinced us to use
• This instead: “Turn an unhappy customer into a happy one in 5 quick steps”

Again, I’m not talking just about courses. This applies to activities, which could (and maybe should) be provided individually, on demand. Each activity that stands alone should quickly make clear what people will practice doing and how they’ll benefit.

For more on the distinction between an action and an enabling objective, see Why you want to focus on actions, not learning objectives.

 

“It’s new, so everyone needs training on it.” Nope. 18 Dec 2018 6:00 AM (6 years ago)

By Cathy Moore

“We’re introducing something new,” your client says. “So of course everyone needs to be trained on it.”

Hmmm. Really?

Maybe your client is thinking this: “This new thing is so bizarrely new that no adult Earthling could possibly figure it out without formal training.”

Or maybe they’re really thinking this: “This new thing is a pain in my neck and I don’t know how to introduce it. I’ll have L&D train everyone and call it a day.”

Either way, the client is expecting you to unleash an avalanche of “training” on innocent people who would rather just do their jobs.

Example

“Please train everyone on the new TPS software by June 1,” your client says.

The client expects to hear, “Sure. I’m on it!” Instead, offer an innocent “why?”

“Why are you installing new TPS software?” you ask.

“Because people were messing up their reports in the old software,” your client says.

“Why were people messing up their reports in the old software?”

“It was confusing to use,” your client says. “The new software walks people through the process a lot more clearly.”

“So the new software is easier to use?”

“Yeah, a lot easier.”

“And everyone who will be using it is already familiar with the old software?”

“Yep. They’ve all been entering TPS reports for years.”

At this point, do you agree with the client that everyone needs “training” on the new software? I hope not.

You might propose this: Give the new software to a few typical TPS report creators and watch them figure it out. Their struggles (or lack of struggle) will show what support they really need. A help screen or short reference is likely to be enough “training” in this case.

Use a goal to focus on performance, not training

If you’re using action mapping, you’ll want your client to give you a measurable business goal that justifies the expense of the project.

In our example, the client’s first goal was, “TPS software training is 100% complete by June 1.” This goal is measurable, but it doesn’t show how the organization will benefit. It also gets way ahead of itself by assuming that training is the solution.

Your innocent questions help the client see their real goal. This might be, “TPS error rates decrease 35% by June 1 as all TPS staff correctly use the new software.”

This goal doesn’t assume that training is the answer, and it justifies the expense of the project in terms the organization cares about. It also leaves room for many solutions, including job aids.

What about new products?

“We’re releasing a new product,” your client says. “Please train all employees on it.”

What are the two biggest problems with this request? I’d say:

1. The client assumes training is necessary.
2. They think “everyone” needs training. They’re planning a sheep dip.

Your (polite! helpful!) questions should steer the client to this:

• The reason the product was created in the first place. What organizational improvement is the product supposed to achieve? For example, are we trying to snag some market share from a competitor? Help your client and SMEs focus on meeting that organizational goal, which may or may not require training.
• A breakdown of the “trainees” by job role (sales, support, repair…)
• The very specific tasks a typical person in each role needs to perform with the product (sell it using X technique, explain it when a customer asks Y, repair it when it does Z…)
• The real-world barriers that might make each major task difficult, including problems with tools, time, social pressures, communications, management support…
• The (many!) solutions that could be put in place to remove those barriers

Then, if some training does seem to be necessary, it will be far more targeted and useful.

You could use a similar approach for customer training for a new product:

• Why was the product released? What problem does it solve for customers? What does it do for us as an organization?
• Do we have different types of customers? How can we categorize them?
• What does each category of customer DO with the product? What are the major tasks they perform?
• What could make each of those tasks difficult? How could we make it easier?

Related articles

What to do if they just want “awareness”

How to design software training, part 1: Do everything except “train”

Is training really the answer? Ask the flowchart.

How to make mandatory training relevant 26 Jun 2018 3:33 AM (6 years ago)

By Cathy Moore

“How can we make mandatory training more than a tick box exercise?”

That’s the top topic voted by blog readers, so here’s my take.

For “mandatory training,” I’m picturing any material that says some version of “Follow these rules.”

It’s sheep-dip training. Everyone must be “exposed” to it, and a checkmark records that they have been exposed.

How can we make it more relevant?

1. Disobey

A client who says “Everyone must be trained on X” needs our resistance, not our obedience.

Help the client by asking questions, such as:

• What problems are you seeing? Has something happened? Has someone sued?
• Was this problem caused by one rogue employee, or is it a bigger issue? Is it limited to a group of employees, or is it really a problem that all employees are causing equally?
• What are we currently measuring that will improve when everyone is “trained?”

If there’s really no problem, we shouldn’t create a solution. We need to focus on improving performance, not guarding against problems that experience has shown aren’t likely to occur.

2. Set a goal

If it’s clear there really is a need for “training,” or some force far outside your control insists on “training,” then put on your action mapping hat and push for a measurable goal. Here’s one model to follow.

For details, see How to create a training goal in 2 quick steps.

3. Narrow your focus

Make sure your audience is specific. “All employees” is not specific.

If you’re required by forces beyond your control to create something for all employees, you can at least break down the audience by major job roles as described next.

4. Do the analysis. Really. DON’T SKIP THIS.

Focus on one job role in your audience. Ask your client and SME what these people need to do, in specific, observable terms, to meet the goal.

“Follow the data security policy” isn’t specific. This is specific:

• When you must physically transfer data to another location, put the data on a BrandZ thumb drive using HakrPruf encryption and chain it to your left ankle.

Prioritize the actions. Choose a high-priority one, and ask, “What makes this one thing hard to do?” Use the flowchart.

Again, you’re doing this for a specific group of people in a specific job, and you’re focusing on specific, observable behaviors. You’re not asking this once for the entire “course,” and you’re not talking about all employees in every job everywhere.

If those forces far beyond your control insist on applying the same solution to everyone, do this analysis for the major job roles. You probably won’t have a ton of time to do this, but even two hours can save you and everyone else from a much bigger waste of time in the form of irrelevant and ignored materials.

Then, if training is part of the solution, you can have people use only the activities that apply to their job.

Don’t skip this.

If you skip this analysis, what do you have to work with? Generic rules that are guaranteed to become an information dump.

Instead, if you look closely at what people need to do and why they aren’t doing it, you get:

• Ways to fix the problem that don’t require “training”
• Ideas for ways to help people practice the tricky parts
• Respect for the intelligence and experience of the people currently doing the job (notably lacking from most compliance training)

5. Base your design on job tasks, not information

Yes, people need to know stuff. But they need to know stuff in order to do stuff. Design first for what they need to do.

Provide the need-to-know information in the format it’s used on the job. Let people pull the information just like they will on the job.

Here’s a fictional example. Extraterrestrials have landed and are being incorporated into earthling families. As a result, employers have created alien leave policies. Here’s a mini-scenario for managers.

To answer this question, what information does the manager need? The alien leave policy. How should we provide it?

The traditional approach would be to first present a bunch of slides about the policy. Then we’d give people a chance to “apply” what they’ve “learned” by having them use their short-term memory to answer the question.

But why design slides to present information that’s already in a policy on the intranet?

Instead, we can plunge people into the activity and let them use the policy just like they will on the job.

And now that we aren’t developing lots of information slides, we can create more activities. Since they aren’t trapped inside an information presentation, they can travel alone. For example, we can provide them individually over time (spaced practice) as described in this post.

6. Sell it with a prototype

Create a prototype of one typical activity and show it to the stakeholders. Make clear that people will see only the activities that apply to their job. They’ll pull information rather than recognizing what they saw three slides ago, and they’ll learn from the consequences of their choices.

You’re letting the stakeholders see for themselves how you plan to provide the “training,” because then you’ll be in a good position to respond to the following common concerns.

“But everyone must be exposed to all the information!”

Give each option unique feedback. In that feedback, first show the consequence of the choice — continue the story.

Then show the snippet of information they should have looked at, as described in How to really involve learners. Do this for all consequences, not just the poor ones.

See more ideas and examples in Scenario mistakes to avoid: Eager-beaver feedback.

If you have a stakeholder who’s determined to expose everyone, you can point out that they are now exposed. They’re just exposed after making a relevant decision, rather than in a forgettable presentation.

By not presenting information first, you’re helping people see their own knowledge gaps. They’re not pulling stuff out of short-term memory, because you haven’t put anything there. They have to rummage around in their existing knowledge, look at the policy just like they would in real life, make a choice, and learn from the consequences. They get deeper learning, plus they’re dutifully “exposed” to the correct information.

“But they have to prove that they know it!”

Which approach is more likely to avoid lawsuits about misuse of the alien leave policy?

A. Present the policy over several slides. Then require a knowledge test to see if people can recognize a bit of information that they saw 5 minutes ago. If they can, they “pass.” If they can’t, they must put those same slides back in their short-term memory and try again.

B. Present challenges in which people need to make the same decisions they make on the job. Provide the information in the same format that people will have it on the job. Start with easy-ish decisions and increase the challenge. If people make good decisions in enough activities, they’re free to go. If they make not-good decisions, they get more activities and optional help until they make good decisions.

My point

Don’t design for “They should know the rules.” Design for “They should correctly apply the rules on the job.”

For lots more, see my book and just about everything in this blog, especially the following posts.

• How to really involve learners
• What to do if they just want “awareness”
• Why you want to focus on actions, not learning objectives
• Three ways to save gobs of time when designing training
• Will action mapping work for my project? Custom advice for your situation.
• 5 best instructional design books you should read this year.

Credits

Photo of Jorge: David Boyle in DC via Compfight cc

All other images: Cathy Moore

Two examples of interactive job aids 28 May 2018 7:50 AM (6 years ago)

By Cathy Moore

I talk a lot about using Twine for branching scenarios, but it’s also useful for creating interactive job aids. Here are two examples.

Diagnostic tool: Is this a gnome or what?

Want to help people diagnose a problem or identify the best person to contact? Be inspired by this fun example created by Krishan Coupland in Twine: A Primer on the Capture and Identification of the Little Folk of Myth and Legend.

This is basically a text-based flowchart, sending you down paths depending on the characteristics of the creature you’re trying to identify.

This type of interaction has a lot of potential uses in business, where the little folk might be replaced by types of tools, people to contact, troubleshooting steps to follow, or any other type of flowchart-y decision.

I’d prefer a quicker, visual flowchart when possible, but this text-based approach lets you include more detail.

Custom advice made scalable

You can make Twine handle more complex decisions if you use variables.

One of the most common questions I get is, “Will action mapping work for my project?”

To relieve the pressure on my in box, I created a Twine interaction that answers that question. I used variables to keep track of answers.

For example, you might say that your client is a non-profit organization ($org is “nonprofit”) and their goal is to make people feel confident or engaged ($goal is “feelings”). As a result, you’ll see advice tailored for non-profit organizations and feelings goals.

You might want to try the interaction before reading more, or the rest of the post won’t make much sense.

The variables are set when you answer questions at each decision point. Here’s how one decision point looks.

Earlier, the user identified whether their client was external, internal, or themselves. Now they’re being asked what type of organization the client works for.

If they answer “Business,” a variable that tracks the action mapping score ($am) gets 2 more points. This score will help decide whether action mapping is appropriate.

If they answer “Non-profit or government,” the action mapping score increases by only 1, due to the goal-setting issues that often plague those types of organizations.

If they answer “University or school,” the action mapping score doesn’t increase, because it’s likely that action mapping won’t be appropriate. That will get decided in the next question, which asks who the audience is.

The questions continue assigning variables and changing the action-mapping score. Users who want to prepare people for a knowledge test will be told early on that action mapping won’t be appropriate. Others will continue until they see the final advice screen.

The final screen uses the variables that have been accumulating to display text unique to each variable. Here’s a snippet.

In the above excerpt, if you said that your goal was to have people do something differently, you get a confirmation that action mapping will help. However, if you said that your goal was for people to be aware of something, you get some advice on how to change that so you can use the model more successfully.

Several additional paragraphs of text appear on the advice screen, all based on the answers you gave earlier and the variables you were assigned as a result.

This took some time to develop, but it has also saved a lot of time by reducing the number of questions I get. This kind of tool can reduce the need for training and relieve the pressure on help desks by providing instant answers tailored to each situation.

3 branching scenario examples to give you ideas 8 May 2018 4:00 AM (7 years ago)

2 types of elearning scenarios: branching and mini 24 Apr 2018 4:00 AM (7 years ago)

Mini-scenarios: How to help people recover from mistakes 10 Apr 2018 4:00 AM (7 years ago)

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