Tag: branching scenario

How Long Should We Let Learners Go Down the Wrong Path?

In a comment to my post on Managing the Complexity in Branching Scenarios, Nicole Legault made a interesting point. “Why make a learner go so far down a wrong path? I think it’s best to correct and try to get them back on the right (or best) path.”

To some extent, I agree with Nicole. I’m not sure how much value there is to learners in going down seven steps of the wrong path with no way to recover. Where I perhaps disagree is about how the correction should happen. I try to give learners the opportunity to correct their own mistakes. However, that’s different from correcting them and forcing them back on the right path.

There are a couple of ways to handle wrong answers in scenarios.

Limited Branching

One way is limited branching. Instead of a true branching scenario with multiple endings, this is essentially a single correct path and a single ending. When you make an incorrect choice, you get some customized feedback and perhaps see limited consequences of your decision. In the long run, there are no real consequences for mistakes. You are forced back to the correct path, regardless of your mistakes.

Although he doesn’t call it that, limited branching is the model explained in Tom Kuhlmann’s Rapid eLearning Blog as an easy way to build scenarios. Tom points out that this model is simpler doesn’t get you overly bogged down in complexity.

In limited branching, you can get the wrong answer every single time, and the scenario still propels you forward. This works OK if your scenario is a series of independent decisions rather than multiple decisions in a single large scenario. If you’re teaching a process with multiple steps, where each step is contingent on the previous step, this method doesn’t create as realistic of an assessment.

Immediate Failure and Restart

The opposite end of the spectrum from limited branching (where you can make endless wrong answers) is immediate, catastrophic failure. If you make a single incorrect decision, you restart the scenario back at the beginning. Personally, I don’t like scenarios where a single wrong answer results in catastrophic failure unless that’s what would happen in real life. Some errors really are major and should result in immediate restarts.

If you’re creating training for nurses, administering 10 times the needed dose of a medication is a catastrophic failure. If you’re creating a scenario to show what to do in an active shooter situation, a decision that results in someone dying is a catastrophic failure. In both of those scenarios, forcing learners to restart at the beginning is appropriate.

 

2 or 3 Consecutive Wrong Answers

Most of the time in scenarios, we’re working with gray area. In real life, we often have opportunities to change paths and correct mistakes. Where a single isolated mistake can be corrected, the cumulative effect of several wrong answers is the real concern.

In my scenarios, I usually try to limit it to two or three consecutive wrong answers before a restart. I give people opportunities to get back on the right path by making better choices. If they keep going down the wrong path, they have to restart and try again. I won’t force them to correct; learners need the opportunity to fail.

In this example, there are good (green), OK (orange), and bad (red) choices. If you choose C (red) at the beginning, you may reach a poor ending after just 2 choices. However, if you improve your choices, you can get back to a good (green) choice by correcting your mistakes.

Flow chart showing that two consecutive wrong answers lead to a poor ending Flowchart showing a branching scenario with an opportunity to recover from mistakes

Limiting it to two or three consecutive wrong answers also helps limit the complexity of branching scenarios. You don’t have to create a full-length path of increasingly wrong answers.

Giving people a short, but incorrect (or partially incorrect), path also gives you the opportunity to show delayed consequences.

 

 

 

What do you do?

How do you handle wrong answers in a branching scenario? How long do you let learners go down an incorrect path before either forcing a restart or forcing them back on the correct path?

ID and eLearning Links (7/23/17)

Posted from Diigo. The rest of my favorite links are here.

Instructional Design and E-Learning Links

Managing the Complexity of Branching Scenarios

On reddit, someone asked how to manage the complexity of branching scenarios and keep them from growing out of control. One of the issues with branching scenarios is that you can get exponential growth. If each choice has 3 options, you end up with 9 slides after just 2 choices, and 27 after 3 choices. This is 40 pages total with only 3 decisions per path. For most projects, that’s more complexity than you want or need.

Branching scenario with exponential growth

So how do you manage this complexity?

Use Twine

One way to make this branching easier to manage is by creating your scenarios in Twine. Twine makes it very easy to draft scenarios and check how all the connections flow together. No matter how complex your scenario is, Twine makes it easier to create it. Cathy Moore has an example of a scenario she built in Twine. This scenario has 57 total decision points, but it only took her 8 hours to create.

You can use Twine as your initial prototype, or you can use it as your final product. I have used Twine as my initial draft and prototype, then exported everything to Word as a storyboard for developers to build the final version in Storyline.

Planning a Scenario

Before I sit down to write a scenario, I always know my objectives. What are you teaching or assessing?

I usually have an idea of how long the ideal or perfect path will be. If you have a multi-step process, that’s your ideal path. If there’s going to be 4 decision points on the shortest path, I know what those are before I start writing.

I also usually know at least some of the decision points based on errors or mistakes I need to address.

There’s a limit to how much you can plan before you just start writing it out though. I find it’s easier to just open up Twine and figure it out within that system.

Allow Opportunities to Fix Mistakes

One trick for managing the potentially exponential growth is by giving learners a chance to get back on the right path if they make a minor error. If they make 2 or 3 errors in a row, they get to an ending and have to restart the whole thing.

For example, maybe you’re teaching a communication skill where they should start with an open-ended question before launching into a sales pitch. Choice A is the open-ended question (the best choice). Choice B is a closed question (an OK choice). Choice C is jumping right into the sales pitch without asking (bad choice). After the customer response for choice B, I’d give them an opportunity to use the open-ended question (A) as their follow up. Reusing some choices helps keep it from growing out of control. In this image, reusing choices cuts the total number of pages from 40 to 20.

Flowchart for branching scenario with 20 pages Make Some Paths Shorter

Not every path needs to be the same length. In the above image, one branch from choice C is shorter. It ends after 2 choices instead of 3. You might make a short path if people make several major errors in a row. Past a certain point, it makes sense to  ask people to reset the scenario from the beginning or backtrack to a previous decision.

Good, OK, and Bad

In branching scenarios, not everything is as black and white as a clear-cut right or wrong answer. You can have good, OK, and bad choices and endings. In this example from my portfolio, green is good choices/endings, orange is OK choices/endings, and red is bad choices/endings. In this scenario, if you choose 39 (bad), you have 3 options: 40 (back on the good path, recovering from the mistake), 41 (OK), and 42 (a bad choice leading to a restart). This example has 15 endings, which is still more than I would like; if I was redoing it now I would probably collapse a few more of those endings together.

Branching scenario flowchart with good, OK, and bad choices and endings

Your Ideas?

Do you have any suggestions or tips for managing and reducing the complexity of branching scenarios? Please share in the comments.

How to Get Started Writing a Branching Scenario for Learning

In a recent conversation, a colleague asked, “Once you and your client have agreed on a branching scenario approach, how do you get started writing it? How do you get from the broad concept of training on X topic to actually creating the scenario?”

The short answer is to “begin with the end in mind.” Let me walk you through the process of analysis and preparation I do before writing a scenario.

Get Started Writing Branching Scenarios

Begin with the End in Mind

At the end of the training, what do you want people to do differently? It’s important to ask what you want learners to DO, not what you want them to KNOW. Cathy Moore has been beating this drum for years. If we’re aiming for behavior change, then we need to focus on what behaviors we want. It’s not enough to simply increase awareness.

Get Specific with Behaviors

Julie Dirksen describes this as the “photo test.” If you took a photo or video of the desired behavior, what would it look like? For example, a client might ask you for training on “quality customer service” or “better communication between nurses and patients.” As part of your analysis, ask what that really means. It’s not enough to just get a list of principles or broad best practices. You need specifics and examples.

“Quality customer service” might mean cashiers asking customers if they found everything they were looking for and calling for someone to get it if they missed something. That’s a specific behavior we can observe and assess.

“Better communication between nurses and patients” might mean asking open-ended questions to learn what concerns are most important to the patient. That’s another behavior we can observe.

Identify Common Mistakes

Ask your SMEs questions about mistakes. In a branching scenario, it’s not enough to know what the right behavior looks like. You need to know the wrong behavior you need to change too.

  • What are the common mistakes people make?
  • Where do people get stuck in this process?

If you have access to learners or people who have recently learned the skill, ask them too. They may have more insight than the SMEs.
The mistakes you identify become the distractors in the questions for your branching scenario. The mistakes and places people get stuck help you determine where to put decision points. If certain parts of the process are fairly clear and unproblematic, you can make those sections of the scenario passive review. That way, you can focus on what you really need to meet your objectives in the scenario.

Identify Consequences of Mistakes

For each mistake you identify, find out the consequences. Ask your SMEs and sources this question.

  • What are the consequences if people make this mistake?

The consequences of those mistakes become the feedback in your scenario. Asking a patient a closed question rather than an open-ended one results in a one-word answer. Forgetting to ask customers if they found everything results in lost sales and less satisfied customers.

Keep Probing for Specific Behaviors

Sometimes SMEs have a hard time switching from talking about abstract principles to describing behaviors. If they answer your questions about mistakes and consequences with broad answers, keep probing for specific examples and behaviors. You may have to ask these questions several different ways to get what you need.

  • Tell me more about that mistake. What do you think is going through people’s heads when they do that?
  • What does it look like when they make this mistake?
  • What does that consequence look like in practice?
  • Can you give me an example?
  • Tell me about a time when you saw this happen in a real situation.
  • What happened next?
  • Where do people get confused? What do they do when they’re confused?

Sequence Decision Points

Once you have a list of mistakes, you can list and sequence the decision points. Often, you’ll be following a specific process where it’s clear what needs to happen at each step. In those cases, you outline the process and note where you’ll insert decision points that give learners a chance to make the mistakes you identified.

If you aren’t following an established process, think about a logical flow of events. Sometimes a particular mistake obviously happens at the beginning or end of a process. Look for the set points of the process and flow the rest of the steps around that.

Rough Flowchart

At this stage, I only do a very rough flowchart or outline. I find the flow is sometimes easier to determine by simply sitting down and writing it rather than planning out every branch in advance. However, if you’re just getting started with branching scenarios, you might benefit from planning out in more detail. In the planning process, I often only do the sequence for the main correct path; I fill in the branches later as the scenario develops.

Storyboard or Draft

Once I have a rough flowchart and I know my primary decision points, I start storyboarding or drafting. I check my storyboard against my list of behaviors from the beginning of the analysis. Did I include all the critical decisions and behaviors? Did I include all the common mistakes?

Your Process?

What is your process for preparing before creating a branching scenario? Let me know in the comments.

Do You Need a Villain in a Learning Story?

I recently attended an interesting webinar by Joe Ganci on how to use science fiction to improve eLearning. In the presentation, Joe talked about elements of storytelling common to science fiction and how to incorporate those aspects for better stories in elearning. If you’re attending the Learning Solutions Conference later this month, you can hear this presentation live. (You can attend my presentation on voice over script pitfalls too!)

One of Joe’s points was that great science fiction stories have a compelling villain that allows the heroes to be heroic. The same goes for storytelling for learning. Even if the major conflict is a tight budget or short timeline, Joe argued it’s better to personify that challenge. Provide a manager who explains the budget limitations or a harried customer who needs an project finished quickly.

To some extent, I agree with Joe. Instead of simply an abstract challenge of time or resources, you can humanize it by showing why the budget is tight or how being late will impact a real person. Stories help you make learning more concrete.

Bearded businessman with evil expression

However, I’m not quite convinced that a “villain” is what we need in learning. In the real world, the bad guys and good guys aren’t always so clear cut as in the movies. Real people are rarely motivated by simply being evil. They may be confused, misguided, angry, or disorganized. That doesn’t exactly make them a villain though.

I’m worried that forcing a villain into a story might make it too over-the-top or comical. That can work if that’s what you’re going for, but I think that’s challenging to pull off well in most corporate environments.

Maybe my problem is with the word “villain.” If we call that character an “antagonist” instead, then it works well. The antagonist doesn’t have to be evil like a villain; they just have to create the conflict or challenge that drives the story. I think that’s really what Joe is getting at. The harried manager telling you the budget is tight isn’t really an evil villain, just someone doing their job in a way that creates a challenge for the learners.

What do you think? Is it beneficial to include villains in learning stories? I am ambivalent and looking for your perspectives. Answer the poll and let me know. (Email readers, you may have to click through to the site to respond to the poll.)

If the none of the answers in the poll fit, or you want to explain more, leave a comment and tell me what you think.