Category: e-Learning

What to Write First in Branching Scenarios

Writing a branching scenario can be intimidating or overwhelming. Unlike a linear course, it’s not as easy to know where to start writing. Do you write the endings first? Do you write all the mistakes first? Do you start at the beginning and then flesh out each path as you write those choices?

I have found that it’s easiest to write the ideal path from start to finish first. I note decision points and sometimes draft bad choices along the way, but I don’t fully write anything else until I finish the ideal path.

What to Write First in Branching Scenarios

Writing the Ideal Path from the Outline

In my last post, I explained how I create an outline of the steps in the scenario. This is my plot outline for the story if learners take the “ideal path,” making the best decision at every step. For each step in the outline, create a situation in which the learner must choose to take that action. You create a decision point where the best choice is the first step in your outline.

Write the First Decision

Building on the example from my last post, a course on screening potential consulting clients, I have a process with 4 steps.

  1. Send client initial screening questions.
  2. Review client responses for fit and feasibility.
  3. Learn more about client needs during preliminary phone call.
  4. Propose a short road mapping engagement.

Because I did that planning in advance, I know exactly what I’m writing first: a decision where the right choice is sending the client initial screening questions.

Sophie receives an email from a prospective client, Robert.

Hello Sophie,

My company has 4 classroom training courses we’d like to convert to online. One of them is a half day course; the others range from one day to four days long. Can you please tell me what you would charge to convert these courses to online?

Regards,

Robert

What should Sophie do?

    1. Send Robert a price estimate.
    2. Send Robert some client screening questions.
    3. [[Some other OK choice TBD]]

Write the Remaining Ideal Decisions and Consequences

Once you have the first step written, the next thing you will write is the consequence from making that best decision in step one. In this example, the prospective client will reply to the email.

Robert replies with his answers to the screening questions.

[placeholder–questions and answers here]

What should Sophie do?

  1. These answers look reasonable. Schedule a call to discuss it further.
  2. [[OK choice TBD]]
  3. [[Bad choice TBD]]

Continue writing until you get to the end of the ideal path, showing the consequences for good decisions and how they lead to the next decision.

Don’t Write the Mistakes Yet

When I write my initial draft of the ideal path, I focus just on the correct or best choices first. I don’t write all of the mistakes and their consequences on the first pass through writing. As I draft choices, I might write down some of the bad choices if I already know them. For example, in step one, I know the mistake I’m trying to avoid is the first choice above of sending a price estimate without understanding the problem and scope first. However, at this stage of writing, it’s OK to just leave a placeholder for the other choices.

I find it helpful to indicate what kind of choices I still need in the placeholder. For most scenarios, the majority of decision points have a Good, OK, and Bad choice.  You can see how I noted that in my placeholders as “OK choice TBD” or “Bad choice TBD.”

Write the Ideal Ending and Feedback

At the end of the scenario, after learners have made all the correct decisions, write the ending. This should show the positive consequences of those choices. The ending should show what it looks like when people meet the learning objectives. In this example, the ending will show Sophie and Robert working together with a productive relationship.

You may also choose to include some more instructional feedback or coaching. At the end of the scenario, it can be helpful to tell people why the decisions they made were correct to reinforce what they learned.

Use Twine for Writing

I have tried a number of different tools and methods for writing branching scenarios. The open source tool Twine is my favorite for writing scenario drafts and creating quick prototypes. This makes it easy to see the connections between decision points. It’s also easy to leave placeholders for other choices that you will flesh out later.

More Reading

In my next post, I’ll describe how I write the mistakes and flesh out the rest of the scenario.

You might also be interested in my other posts on branching scenarios.

 

Planning a Branching Scenario

After I have completed my analysis for a branching scenario, I spend time planning before I start actually writing the content.

My planning includes three components:

  • A scenario concept and summary
  • An outline
  • A list of mistakes

Planning a branching scenario

Scenario Concept and Summary

I create a summary of the scenario and the narrative. This is included in the design document and signed off by the client and SME before I start writing. I want everyone on the same page for the basic concept of the scenario.

The summary includes the name and role of the main character, plus any other critical characters. I describe the problem the main character faces and how it will be addressed. This is just a few sentences to give the overall feel of the scenario without getting into much detail.

Here’s an example:

Sophie is an instructional design consultant. She’s tired of spending hours and hours writing proposals for clients who don’t end up hiring her or really aren’t a good fit in the first place. She has been contacted by Robert about a potential project. Sophie will attempt to follow a new process for screening clients to see if this is actually a good fit for her skills and to establish a professional relationship with Robert.

Create an Outline

I start with a rough outline or checklist of steps in the ideal process. Let’s say I’m creating a course on screening potential consulting clients, and I have a process with 4 steps. Each of these steps will be a decision point in the scenario.

  1. Send client initial screening questions.
  2. Review client responses for fit and feasibility.
  3. Learn more about client needs during preliminary phone call.
  4. Propose a short road mapping engagement.

It’s possible that when I write the scenario that I’ll realize I need to add another choice in this process, but this gives me the basic flow.

Identify Mistakes

Based on my analysis (including conversations with SMEs, learners, and/or other stakeholders), I also create a list of mistakes or errors people could make. This list tends to be fairly fluid for me; I try to brainstorm more mistakes and problems that I’ll actually use in the scenario. Some mistakes might be critical for the learning objectives, while others might be possible options.

Continuing the previous example, here is a list of potential mistakes I might use.

  • Agreeing to a client request for a project before screening for fit (critical–must include)
  • Sending client screening questions without a budget question
  • Ignoring red flags in client responses (not enough money, unrealistic timeline, etc.)
  • Rejecting a client because they don’t know what they want (that’s what road mapping is for)
  • Jumping right into asking about project logistics without understanding goal/problem
  • Writing a big proposal for free

I try to include both major, critical errors and some errors that are partially correct or in the gray area. Sometimes this list of mistakes also includes notes on consequences, although usually I have that in my notes from the SME.

I find it helpful to include both the outline and list of mistakes in the design document if possible. I haven’t always done it that way, but it seems to help set clear expectations with SMEs and clients.

Start Writing

Once I have all of those pieces together and approved, I start writing. In my next post, I’ll explain my process for creating the first draft.

Geometric background image: Storyblocks (7-day free trial, unlimited downloads $149/year)

Immediate and Delayed Consequences in Branching Scenarios

In branching scenarios, we can use a combination of immediate and delayed consequences and feedback. Consequences are what happens as a result of decisions; feedback is what we tell learners after decisions.

Immediate & Delayed Consequences

Use Immediate Consequences Often

Immediate consequences are the intrinsic effects of decisions. A customer who responds angrily, software that doesn’t produce the desired result, or time lost on a project could all be immediate consequences. These consequences don’t directly tell the learner, “Sorry, that was incorrect.” Learners have to perceive and understand the cues in the scenario. They have to draw conclusions based on those cues.

If your learners will need to follow cues when they apply what they’re learning, it’s helpful to provide real-world consequences in your scenario. It’s beneficial to practice interpreting cues.

Immediate consequences that simulate real-world cues can also be more engaging than the omniscient narrator dictating what you did right or wrong.  It keeps learners in the mindset of the story without hitting them over the head with a reminder that they’re learning something.

Use Immediate Feedback with Novices

Immediate feedback is different from intrinsic consequences. This is the instructional feedback or coaching that directly tells learners why their decisions are right or wrong. While this can pull people out of the “flow” of a story, immediate feedback can be helpful in some situations.

First, novice learners who are still building mental models of a topic may benefit more from immediate feedback. Novices may not have the expertise to sort through real-world cues and draw accurate conclusions from them.  Therefore, it may be more important to provide immediate feedback after each decisions in a branching scenario if your audience is new to the topic.

In his research report “Providing Learners with Feedback,” Will Thalheimer explains the benefits of immediate feedback for novices.

“On the surface of it, it just doesn’t make sense that when a learner is piecing together arrays of building blocks into a fully-formed complex concept, they wouldn’t need some sort of feedback as they build up from prerequisite concepts. If the conceptual foundation they build for themselves is wrong, adding to that faulty foundation is problematic. Feedback provided before these prerequisite mental modelettes are built should keep learners from flailing around too much. For this reason, I will tentatively recommend immediate feedback as learners build understanding.”

Provide Instructional Feedback Before a Retry

I always use feedback before restarting a scenario.  If a learner has reached an unsatisfactory ending in a scenario, it’s beneficial to do a short debrief of their decisions and what went wrong. Especially for more experienced learners, some of that feedback may be delayed from when they made the decision. You can summarize the feedback for several previous decisions on the path that led to the final decision.

This feedback should happen before they are faced with the same scenario decisions again. Otherwise, they could make the same mistakes again (reinforcing those mistakes) or simply guess without gaining understanding.

Thalheimer’s research also supports this.

“When learners get an answer wrong or practice a skill inappropriately, we ought to give them feedback before they attempt to re-answer the question or re-attempt the skill. This doesn’t necessarily mean that we should give them immediate feedback, but it does mean that we don’t want to delay feedback until after they are faced with additional retrieval opportunities.”

Use Delayed Feedback with Experienced Learners

Thalheimer notes that delayed feedback may be more effective for retention (i.e., how much do learners remember). That effect might be due to the spacing effect (that is, reviewing content multiple times, spaced out over times, is better for learning than cramming everything into a single event). The delay for feedback doesn’t have to be long; one study mentioned in Thalheimer’s report showed that delaying feedback by 10 seconds improved outcomes.

Delayed feedback may also be more appropriate for experienced learners who are improving existing skills rather than novices building new skills. Experienced learners already have mental models in place, so they don’t have the same needs for immediate correction as novices. They can get the benefit of delayed feedback.

Use Delayed Feedback with Immediate Consequences

In branching scenarios, we can use a combination of immediate intrinsic consequences (e.g., an angry customer response) and delayed instructional feedback (e.g., you didn’t acknowledge the customer’s feelings). Feedback before a retry or restart could count as delayed if it includes feedback for multiple decisions. If you let learners make 2 or 3 wrong choices before a restart, the combined feedback will effectively be delayed.

Use Delayed Consequences When Realistic

We  don’t always immediately know our mistakes are wrong in real life. Sometimes the consequence isn’t obvious right away. Sometimes it seems like a gain the short run, but causes problems in the long run. If that’s the kind of situation you’re training for, letting people continue on the wrong path for a little while makes sense. Neither limited branching nor immediate failure allow you to show delayed consequences.

Providing these delayed consequences has the advantage of better learning from delayed feedback, plus it creates a more realistic and engaging story. Delayed consequences shouldn’t be forced into a scenario where it’s not realistic, but they are a good way to show the long-term effects of actions.

Think about how delayed consequences could be shown in these examples:

  • A bartender gives away many free drinks. The immediate consequence is that the customers are happy, but the delayed consequence is a loss of profit for the bar.
  • A sales associate sells a customer a product that is less expensive but meets the customer’s needs. The immediate consequence is that the sales associate makes less commission that day, but the delayed consequence is that the customer is loyal and refers 2 friends. In this case, the total commission earned is higher even though the immediate sale was lower.
  • A doctor could skip a screening question with a patient. The immediate consequence is finding something that looks like the problem, but the delayed consequence is the actual underlying problem remaining.
  • A manager asks an ID to create training. The ID gets started building it right away, trusting that the team requesting the training knows their needs. The immediate consequence is a happy manager, but the delayed consequence is ineffective training that doesn’t actually solve the business problem.
  • If you’re teaching ethics, a small ethical lapse early in the scenario might not seem like a big deal. The immediate consequence might be meeting a deadline or increased recognition.  In the long run, that small lapse leads a continued need to cover up your actions. The Lab: Avoiding Research Misconduct is an example with delayed consequences in some paths.

Looking for More?

Read more about branching scenarios:

 

Don’t Restart Scenario-Based Learning, Go Back

In my previous posts, I shared tips for managing the complexity of branching scenarios and some ideas on how long to let learners go down the wrong path. At some point in that wrong path, you have to redirect learners.

The question is: do you restart the scenario from the beginning or do you go back partway, maybe even just one single step?

Restart or Go Back?

Restart

Many scenarios I write have at least one short path of wrong decisions. This path usually starts with a poor choice. I give learners the option to correct their mistake and get onto a better path. However, if they make multiple wrong choices without ever making a good one, I force them to restart.

If the whole scenario is short (3-4 decisions on the ideal path), I usually just force a restart after each ending.

Back One Step

Most of the time, especially in longer scenarios, you can allow people to back up in the scenario rather than restarting from the very beginning. If learners make 4 correct decisions in a row but have a mistake in step 5, do they really need to go back to the beginning? Maybe they just need to jump back one step to where they made a mistake.

Cathy Moore uses this approach in many of her scenarios. For example, in this Ethics Training example, you can jump back to the previous decision. She shows this with a “Go Back” link. Sometimes you can only go back after reading feedback (“What happened?”).

Back to a Checkpoint

If your scenario allows people to make multiple wrong choices, you might have “checkpoints” where you return to. Let’s say that Joanna makes 3 correct choices, followed by 3 incorrect ones. If there’s a checkpoint after 3 choices, she can jump back to that point.

Think about video games. If your character dies in level 8, you don’t have to go back and play through levels 1 through 7 again. You either start at level 8 (a checkpoint) or right before you died (back one step).

Mix it up

You can use these techniques together in the same scenario. Some paths might lead to a restart, while minor errors might just return to one step earlier. It’s not an all or nothing question.

Can You Please Help Me?

Can you do me a favor? If you have a question about how to create branching scenarios, can you ask it in the comments? (If you’re reading this in email, feel free to reply and ask privately.) I’ll reply to every question asked. You might also see your question in a future blog post.

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?