How to make mandatory training relevant

Compliance training sheep“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.

action mapping goal template

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.

Mini-scenario for alien leave

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.

Lots of slides followed by activity

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.

Instead of presentation, just an activity that links to info

Same activity with link to policy

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.

Credits

Photo of Jorge: David Boyle in DC via Compfight cc

All other images: Cathy Moore

Two examples of interactive job aids

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

Will action mapping work for my project?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.

Question about type of organization

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.

Results screen showing variable use

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.


 

Scenario design: There are still some seats available

The June session of the live, online scenario design course still has some seats available. Learn to design scenarios by designing scenarios, with my personal feedback. There are sessions for people in the Australia-Pacific region as well as the Americas and Europe. Check it out.

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

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.

How to design software training, part 2: Practice activities

Practice activities for new softwareAre you expected to “train” everyone on new software? In my previous post, I recommended that you first try everything but training. Make the software easier to use (yes, it’s often possible!). Create job aids and help screens.

Did that work only partially? Are you convinced that people need formal training? This post is for you.

What you’ve done so far

As described in the previous post, you’ve already:

  • Set a measurable goal that justifies the existence of the project.
  • Listed the specific, observable job tasks that people use the software to complete.
  • Identified why each task might be difficult and looked for ways to make it easier.
  • Asked for improvements to the software to make it easier to use.
  • Created easy-to-find job aids, help screens, and cheat sheets.
  • Tested those changes to see if they were enough on their own.

Now you’re convinced that people need formal training as well.

Expand your definition of “training”

Your organization might define training as, “Everyone goes to a room and is shown how to use the software” or “Everyone takes an online course that walks them through it.” They view training as a one-time event that’s delivered the same way to everyone, regardless of their pre-existing knowledge.

Let’s consider two marketing employees who are expected to learn MegaMailer, which sends promotional emails to subsets of customers.

  • Kate: In her previous job, Kate used a program called Mail-a-lot to send emails to a database of customers. MegaMailer takes a similar approach.
  • Ben: Ben has also sent out marketing emails, but he did it by copying and pasting the recipients’ addresses into the TO: field of the email. He’s never used a database of customers.

Conventional MegaMailer training would force both of them to sit through a presentation about what is a database, record, and field. But Kate already knows all that. What’s a different approach?

“Let Kate skip the stuff about databases,” some people would say. “She can start with the presentation about MegaMailer’s interface.” But what if we go a step further?

We can avoid unnecessary presentations and provide spaced practice if we try this:

  • Create self-contained activities that help people learn by doing.
  • Make these activities available on demand, on the job. Don’t lock them inside a course.

Create activities

1. Create self-contained activities, not presentations

Consider plunging people into realistic simulations or scenarios in which they complete a task similar to the task on the job.

You could give them a faithful recreation of the software, some simple screenshots to click on, or the actual software, but using fake data (a “sandbox” where people can play safely).

An example activity for Ben and Kate could be: “We’re going to send a mailing about the MegaChomper BigBoy toy to all big dog owners. First, you’ll create a list segment of all customers who own dogs that weigh more than 15 kilos.”

Ben and Kate see this activity first, not a presentation about the software. They immediately begin using the software for the same kinds of tasks they complete on the job, but with optional help.

2. Link to basic knowledge instead of forcing everyone to see a presentation.

In the “create a list segment” instructions for Ben and Kate’s activity, the words “list segment” could be linked. Kate already knows what that means, so she doesn’t click the link. Ben isn’t sure, so he clicks the link to learn the basics about lists and segments.

3. Provide how-to information as optional help instead of walking everyone through it.

People who are already familiar with the type of software will want to plunge in and try it. Others will want a lot of guidance. Make them both happy by providing optional guidance.

For example, when Kate sees that she needs to create a segment of big dog owners, she confidently jumps into the software because she’s done it before with another program and suspects it won’t be very different. Ben has a lot less experience, so he clicks “Show me how to do it” and sees a short video of the steps involved.

The amount of help could be tailored more finely. For example, Kate might like just a hint showing the first menu item to use. However, Ben might want a lot more help. In addition to the how-to video, he might like a second, more in-depth presentation that explains what a database is, how fields like “DogWeight” were created, how the information about dog weight got into that field, and so forth.

For an example of different levels of how-to help, see this activity for complex medical software, designed by Allen Interactions.

4. Start easy and build skills gradually

Choose simple tasks for the first few practice activities. In our imaginary example, creating a list segment is the first step to creating a mailing, and it’s also one of the easier steps. Maybe we’ll have Ben and Kate practice creating a few more segments before they move on to the more complicated step of using an HTML template to create the content of the email. This is a type of scaffolding.

For an example of in-activity scaffolding, see if you can learn Zeko. The story reinforces vocabulary you’ve learned so far while adding new terms.

5. Provide realistic feedback, if possible

Strong scenarios and simulations don’t stop you and say “Incorrect!” They just show you what happens as a result of your decision, and you conclude from that how well you did.

This can be tricky with software simulations, especially if the tasks are complex, with lots of ramifications. So this might be too much for your project, but for our imaginary marketing scenario, feedback might look like the following.

  • Kate is supposed to send the mailing about the MegaChomper BigBoy toy only to customers whose dogs weigh more than 15 kilos. When she creates the list segment, she incorrectly tells the software to send the email to all customers except those whose dogs weigh more than 15 kilos.
  • Instead of saying “Incorrect!” we show the natural consequence of her mistake: Owners of tiny dogs complain about annoying emails that advertise toys that their dogs can’t even pick up.

When should we show the feedback? That depends.

If Kate is just practicing list segmentation, we could show it immediately. She creates the segment, and we flash-forward to show the future result.

If she’s further on in the activities and is practicing the entire mailing process, we can withhold the feedback until the end. This is especially useful if our process includes a check step. Maybe the process looks like this:

  • Create the list segment.
  • Choose the correct HTML template.
  • Enter the content of the email in the template.
  • Double-check the list segment to make sure it’s correct.
  • Schedule the email for sending.

This gives Kate a chance to recognize and fix her earlier error, as well as having her practice the entire process.

If she doesn’t catch her error, the end result will be annoyed emails from owners of small dogs, plus an optional explanation of what she did wrong. If she does catch her error, she can fix the segment before sending the email, and she sees the happy consequence of lots of MegaChomper sales.

Make the activities available on demand, on the job

In our example, we’ve created several standalone practice activities. Each one is self-contained because it links to supporting information. It’s not an activity trapped in the middle of a presentation.

As a result, people can try the activities as they need them. Maybe all the activities are linked on an intranet page. We can (and should) show a recommended path through the activities. But people can still directly access an individual activity.

This is especially useful for reinforcement. Let’s say that Ben carefully worked through all the activities about list segments and using the HTML template. He then was put on a project that involved creating lots of HTML emails while someone else created the list segments.

Two months later, Ben needs to create a list segment but has forgotten how. He goes to the bank of activities and chooses some list-segment activities to practice again. Once he’s confident, he creates the segments he needs for his current project.

I’m not just making this up

This activity-driven approach might make intuitive sense, but intuition can’t always be trusted. Luckily, there’s also research that supports the plunge-them-into-it technique.

Again, you’ll want to provide structure, such as a recommended path through the activities, and carefully increase the difficulty with scaffolding. You want people to feel competent, not frustrated.


 

Announcements

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

Learn more.

Hey, New Zealand and Australia!

NZATD in mid-May: I’ll be in Auckland in mid-May to speak and run an informal workshop at the NZATD conference, along with many other colleagues with valuable things to say. I’m also available for a few on-site consulting visits in the area.

Scenario design course for you: The June scenario design course includes a session for people in Asia-Pacific time zones. Check it out here.

Listen to me rant, again

Celisa Steele of the Leading Learning podcast recently interviewed me, with a focus on how associations can adapt action mapping for professional education.

This new page on my site links to several other recent interviews about action mapping and scenario design.

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

Software training really required?“How can I design good training for new software? What’s the right balance between help screens, job aids, and training?”

That’s the top question in our idea collector, so let’s go at it.

Here’s part 1, in which I say, “Try everything but training.” We’ll cover needs analysis, job aids, help screens, and the radical idea of making the software easier to use.

Later, I’ll publish part 2. In that part, we’ll look at how to design practice activities for times when the everything-but-training approach isn’t enough.

 

1. Justify your work with a measurable goal

Action mapping begins with identifying how the organization will benefit from the project. The goal justifies the existence of the “training” (and of your job).

Here’s a template:
action mapping goal template

To identify the measure for new software, you might ask, “Why did we buy this software? What problem will it solve? How will we know it worked?”

For example, if the organization is installing a new customer relationship manager, why? Have potential new customers been slipping through the cracks? If so, maybe your goal is this:

Sales to new customers will increase 5% by [date] as all sales reps correctly use NewCRM to identify new prospects and build relationships with them.

If your stakeholders refuse to commit to a business-performance goal, you might try a weaker but still useful type. For example, you could measure the strain that new software can put on productivity. For example, if the new software is already in place and causing confusion, you can try to reduce the number of calls to the help desk.

If you doubt the usefulness of this kind of goal, imagine the alternative. A too-common “goal” is “All sales reps will be trained on NewCRM by [date].” This says, “We don’t care if the training actually works. We’ll just take attendance. Now give us money.”

For more on setting goals, see:

 

2. Ask, “What do they use the software to DO?”

List the most common tasks that people will use the software to complete. Also consider what might make each task difficult.

For example, is it obvious how to complete the task in the software? Are people working under time constraints?

This flowchart helps you consider all the angles.

For more on this, see the discussion in “Technical training: What do they need to DO?

 

3. View training with suspicion

Many people assume that every new system must be introduced with formal training. But is that always necessary?

“New” doesn’t mean “requires training”

Just because the software is new doesn’t mean that people need to be trained on it. The likelihood that training will be necessary depends on a lot of things, such as:

  • How different is the software from what they’re using now?
  • How tech savvy are the users?
  • How complex are the tasks that the software is used to complete?
  • How horrible is the outcome if someone screws up when using the software?
  • How clumsy is the software interface?
  • How much help is built into the software?

“Hard to use” doesn’t mean “requires training”

If the software is clumsy and its help system is unhelpful, that doesn’t mean that you have to develop training. It means the software should be made easier to use.

L&D staff are often surprised to discover that they can request changes to software — but they have to ask. Don’t assume that it’s too late to change anything.

If the software is from a third party, making it easier to use would help their sales. If the software was developed internally, there’s no excuse for refusing to make it easier. Clumsy software hurts performance.

Make a list of changes that will reduce the need for training. Take screenshots and scribble on them. Write the help blurbs that are missing. Point out where there are too many steps.

“They won’t change it” doesn’t mean “requires training”

If the software is hard to use and the developers have rejected your requested changes, that still doesn’t mean that formal training is your only hope. How about some job aids?

 

4. Try some job aids

A job aid is a reference that gives you just enough information. It can be a piece of paper, a page on the intranet, a short how-to video, a help screen, or anything else.

We can use Moore’s Machete of Awkward Oversimplification to divide software job aids into two groups.

Type 1: Task-based job aids

These are handy guides that quickly tell you how to complete job tasks using the software. Some examples:

  • A short article in a knowledgebase shows you how to record a partial refund in the accounting software.
  • A quick video shows you how to create a template for your marketing emails.
  • The built-in help system highlights the commands you need to use to escalate a customer complaint in the CRM.
  • An extensive, structured document helps you install WordPress, as deconstructed by Dave Ferguson in his handy site about job aids.

These are all aids that help you complete tasks. They aren’t the painfully ubiquitous tour of the menus or alphabetical list of all commands.

Type 2: Code and command references

If users need to type in codes or non-intuitive commands, group the most common ones in a quick reference. As above, try to group the commands by what they achieve. Don’t just list them alphabetically. Some examples:

Let people choose how much information they need

Don’t force-feed everyone with information in your job aids. Let experts skip ahead while novices read deeply. Here’s an example from Dave Ferguson of a job aid designed to satisfy both groups.

Help screen or job aid?

A common practice is to use a help screen to give a quick overview of how to complete a small task. For longer tasks or more detail, the help screen could contain a link to a video, knowledgebase article, or other reference.

People should be able to use the software and view the reference at the same time. For example, a reference that opens to the side is way more useful than one that opens in the same window as the software and blocks it.

For a lot more about job aids from real job aid experts, see Job Aids and Performance Support by Allison Rossett and Lisa Schafer.

 

5. Test your job aids before designing training

Test your job aids on a sample of future users and tweak them as necessary.

If it looks like the job aids alone will get people up to speed, release them into the wild. Tell everyone where they are, make them super-easy to find for the people who missed the memo, and provide a quick feedback mechanism so users can tell you how to improve them.

Let the job aids do their thing for awhile, and then check the measurement in your goal. Has it improved? Also, have managers reported better use of the software? Has the help desk seen a decrease in the number of calls? If so, you might be done. You can make sure you’re done by using Robert Brinkerhoff’s Success Case Method.

In part 2, we’ll look at what you might consider if you decide formal training is necessary.


 

Listen to me rant

Upcoming talks and interviews

Podcasts about instructional designMarch 7, online: Join the discussion about action mapping, scenarios, and who knows what else at TLDCast. 11 AM US Eastern time / 4 PM GMT.

May 16-18, Auckland, New Zealand: I’ll be presenting at the NZATD Conference along with many interesting colleagues. In an informal post-conference session, we’ll discuss ninja mind tricks that will help us understand and change our clients’ mindsets and move us out of the order-taking role.

Listen to the recording

Interview: Jo Cook recently asked me good questions in this five-part interview. I ranted a bit about instructional design degree programs and pointed out that spaced learning gives advantages to trainers as well as learners, in addition to covering some action mapping concepts.

Interview: Connie Malamed also asked good questions about action mapping and the state of the instructional design world for her podcast. We considered whether instructional designers should be responsible for “solving all workplace problems,” the advantages of branching scenarios, the many ways to deliver stand-alone activities, and when action mapping isn’t appropriate.

Webinar with lively chat: Many blog readers and I recently talked about three ways to motivate learners in a chat-filled webinar. View the recording and try some sample activities.

Can we use scenarios to teach concepts?

Here at action mapping central, we’re all about scenarios — realistic activities that help people practice what they need to do on the job.

“That’s all fine,” some people say. “But people need to be taught basic concepts before they can apply them. You can’t just throw people into an activity without first teaching them the concepts.”

I say that yes, we can throw them into an activity that requires knowledge that they don’t yet have. The trick is to make that knowledge available for them to draw on as they need it.

Here’s a basic example.

Measuring tape

Add fractions without knowing how to add fractions

Let’s consider the plight of people in the US, the land of feet and inches. When calculating building supplies, Americans often need to add fractions.

Our learners are American construction workers or similar people who often need to figure out the total length of two boards. We’re designing elearning.

A lot of designers would say, “First we need to show them a video on how to add fractions. Then we need to provide an example in which Pablo the friendly foreman adds the length of two different boards and explains step by step how he does it. Then we’ll let the learners do it with two other boards. This is tell, show, do, which everyone knows is the best way to teach.”

Let’s try it a different way. Let’s make me one of the learners. Math was not my best subject.

  • I’m plunged into an activity that requires me to figure out the total length of a 5-foot, 2 1/2″ board plus a 3-foot, 4 3/8″ board. I’m trying to determine if I can put them end-to-end to get the length required for my porch deck. I realize I have no clue how to calculate the total length.
  • I click the optional link called “How to add fractions.” I see a quick tutorial on how to do it in general. If I had remembered anything from math class, this tutorial probably would have been enough for me.
  • I apply what I learned in the tutorial to the problem, but I’m not sure I’m doing it right. The answer I got is one of the options, but something seems wrong about it.
  • I click the other link, called “See how to solve it.” This shows me the first step to solving the problem and then displays a “Next” link, giving me the option to see the next step. When I click “Next,” I see the next step, and I finally understand what I need to do. I go back to the problem and solve it. If I didn’t get it after seeing the first two steps, I could have kept clicking until I saw all the steps and the actual solution.
  • The course also offers a downloadable, printable job aid that includes a quick reminder of how to add fractions, so I can look at it on the job.

​This is a very different way of “teaching” stuff. Its advantage over “tell, show, do” is that it puts control in the learner’s hands. People who already know how to add fractions simply complete the activity and move along quickly, while people like me who don’t know the method stop, learn it, and then apply it.

​Since this is self-paced elearning, we could adapt it to the learner. If someone views the support materials before solving the first fraction-adding problem, we schedule another fraction-adding problem for them (and maybe another and another, depending on how they seem to perform). In contrast, the people who solve the first problem without help move on immediately to a different type of activity, because they’ve shown that they can already add fractions.

The advantages

Each person gauges for themselves how much they know, seeing and filling their own knowledge gaps. Everyone goes at their own pace, digging deep into the how-to material or skipping it. No one has to sit through a presentation about stuff they already know.

And, importantly, the designer shows that they respect the learners as functioning adults with life experience. For a lot more about that, see the recording of our recent webinar on motivation.

For research that supports this approach, see my post Throw them in the deep end and the FAQ Where’s the research support for scenarios?

Scenario design course: Seats still available

There are still seats available in the scenario design course that starts on Feb. 6. Learn to design scenarios by designing scenarios, with personal feedback from me. Sign up here.

Vote for topics

What do you want to hear about in this blog or future webinars? Enter your own ideas and vote on others’ here. To add an idea, click “Give feedback.”

Photo credit: lungstruck Flickr via Compfight cc; cropped