Category: Storytelling & Scenarios

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.

Objections to Stories for Learning

“Not everyone can be a storyteller.”

“Stories are a waste of learners’ time.”

“Stories don’t work for all kinds of training.”

Have you heard any of these objections? Maybe you’ve even raised some of these objections yourself. Here’s how I would respond to each of these objections.

Objections to Stories for Learning

“Not everyone can be a storyteller.”

Imagine you’re on the phone with someone explaining a bad day and everything went wrong. What happened first that made it a bad day? What happened next? What did you do about it? How did you feel? Did anything change by the end of the day?

Can you imagine yourself telling the story of a bad day? Congratulations–you’re a storyteller! We tell stories about ourselves all the time. We explain our lives in narrative form.

No one is born a storyteller. Telling stories is a skill like anything else. You can develop it with practice and training. Maybe you’ll never write the “great American novel,” but that’s not what you need for creating stories for learning. You need specific skills for creating relevant stories to meet learning goals. Stories for learning are often short, maybe even only a few sentences long.

You CAN learn to be a better storyteller. This is a skill like anything else. With practice, feedback, and the right strategies, you can improve your story writing skills.

“Stories are a waste of learners’ time.”

In a LinkedIn group discussion, someone (we’ll call him “T”) argued, “Learners aren’t there to be entertained. They have a very low tolerance for time-wasting content. If you include games or stories, use them sparingly, and don’t patronize your learner.”

First, I think it’s arguable whether or not learners want to be entertained. However, I think it’s fair to say that learners primarily want to accomplish a goal or solve a problem. We should use stories when they help us meet our objectives. If a story doesn’t support the objectives (or distracts from the objectives), we shouldn’t use it.

Stories can be a waste of learners’ time. “T” shared an example of content with a pirate theme that had nothing to do with the course content. Learners had to click 12 times to get through the intro story before they got to any substance. I agree with “T” on this example; that’s a waste of time. It’s a flashy wrapper around content. It doesn’t add context or relevance.

If you’re going to use stories, focus on how they can help you meet your learning objectives. That might mean using stories as examples or mini-scenarios for assessment. You have a range of options for storytelling available; pick the kind of story that best meets your objectives. Make your stories relevant, not just flashy distractions.

“Stories don’t work for all kinds of training.”

Stories aren’t always appropriate or necessary, but they can work in most kinds of training. For example, software training can use stories for motivation, to show why certain features are used, or to model the thought process of using the program.

For compliance training, every regulation, rule, or policy has a reason behind it. (It may not be a great reason, but set that aside for now.) Chances are, the rule exists because someone broke it. What are the consequences? Why does it matter if people follow the rule?

In compliance training, you can use stories to show people the consequences of violating policies rather than just telling them. You could start by showing a disaster or accident to hook learners in the story. After the intro, go back in time. Show the sequence of events and decisions that led to things getting so bad.

A fantastic example of this is The Lab from the Office of Research Integrity (Flash required). Ethics in research is a topic that could be dry and boring, but this brings it to life and shows the real long-term consequences of decisions. The very first words in the video are “It was a bad day.” You see a reporter questioning someone about questionable lab results. In this branching scenario, you have an opportunity to go back in time to undo the mistakes and avoid the public scandal. Even if you don’t have the budget for something at this level, you can use this worst case scenario strategy.

You can also set up a scenario where learners have to make a decision following the policy. Use the story to give them motivation to look up the relevant rules.

Other Objections?

What other objections do you hear or have to using stories to support learning? How do you respond to objections? Tell me in the comments.

Image: Graphic Stock

Software Training with Stories

“Stories don’t work for all kinds of training.”

One of the common objections I hear to using storytelling in training is that “stories don’t work for all kinds of training.” Those who are skeptical of storytelling often use software training as an example where stories don’t work. However, I think stories can have a place in some (maybe even most) software training.

Software Training with Stories

When to Avoid Stories and Focus on Features

Sometimes software training should be just about the features. In that case, you’re often doing more technical writing than instructional design. Just get in, show the features, and be done. Short tutorials and demos are great for that, and they don’t always need a story. If your goal is to create 5 minute tutorials to help people solve a problem at a moment of need, they’re already motivated and engaged. You don’t need stories in that case.

We often provide software training in advance of the need though. Instead of something learners seek out to solve their own problems, we’re training them about what they’ll do in the future. That training is often much longer; instead of 5 minutes, we might spend hours reviewing everything software can do. Have you ever gone through software training that was just a list of features with no context? How helpful was it? Did you wonder WHY you might use certain features or why a software update would help you?

Examples as Stories

With a few exceptions, nearly any training can benefit from examples. Those examples are often stories. When I taught Microsoft Office as a classroom trainer, I often told stories as examples. I had a collection of stories about colleagues or past students who had solved a specific problem like this one.

“One of my past students had a spreadsheet that needed to be updated every day. She added new data at the bottom, and then she sorted the spreadsheet. The way it was set up required significant manual cleanup. She spent at least an hour or two every day making manual adjustments to the spreadsheet. We found several ways to adjust the structure of the spreadsheet so nearly everything was automated. Instead of one or two hours, the new process only took her about 15 minutes a day. With a bit of initial work to set up the spreadsheet, we saved her at least 5 hours a week of wasted time. That’s why this information I’m about to explain about setting up your spreadsheet for sorting and filtering is so important.”

That’s a real story (it’s the only time in my training career where a student literally jumped up and down with excitement at the end of the course). When I was training Excel, I didn’t just tell students, “It’s important for you to set up your spreadsheets to make it easier for sorting and filtering.” I gave them the example so they understood why it was important and why it would matter to them. I made it concrete and relevant.

In elearning, this example could be presented similarly to how I used it in my classroom training. Instead of having a narrator tell it in the third person, I’d probably reword it to come from the point of view of the user. “I had a spreadsheet that needed to be updated every day…”

Stories to Increase Motivation

When we create software training, we want people to change their behavior. We want them to use the software and use it in specific ways. We want them to be motivated to use the software effectively.

This is especially important when software is updated and people need to change how they use it. It’s not always enough to just say, “here’s a new feature.” Sometimes we need to show people why that feature is going to make them better. Stories and scenarios put those features in context so users are more motivated to try them.

Hands-On Practice with Scenarios

As a software trainer, the books I taught from included examples that were often scenarios. Excel pivot tables are much easier to understand if you have a realistic project where you need answers from data. Those projects are scenarios, whether you’re teaching in a classroom or creating elearning.

The example above with the poorly formatted spreadsheet could easily be converted to a practice scenario. Instead of simply giving people a set of steps to follow, the scenario provides some context.

Why and When to Use Features

If your software training is meant to help people solve a problem while they’re in the middle of working, then microlearning focused on just the features can work. If your software training is intended to give people an overview of complex software, including why and when to use certain features, stories can be helpful.

For example, layer masks are a critical tool in Photoshop. It’s not always obvious to novices why they’re important though. This tutorial puts layer masks in context by creating a realistic scenario (merging together two wedding photos for a client). The author even starts by explaining how to merge the photos with an easy but incorrect and destructive technique. This shows the benefits of using the right technique and addresses a common mistake. There are plenty of tutorials out there explaining various features of Photoshop. Not so many explain how to select the correct tool for the job–that’s what’s valuable in this example.

In complex software, it’s often not enough to know how to use various features. Sometimes you have multiple options for an action, each with pros and cons. In Captivate, you can use a regular Advanced Action or a Shared Action. Depending on your needs, one or the other may be a better choice and make your development more efficient. Stories and scenarios help learners understand how to choose the right tools.

Model the Thought Process

Stories can also be helpful for modeling the thought process that accompanies using software. For example, I once created a software tutorial on how to troubleshoot a particularly problematic task in an LMS. We wanted the online instructors to do some basic error checking themselves before contacting technical support. While I could have simply provided a PDF document with the steps to troubleshoot (and I did provide that as a job aid), I also created an interactive simulation.

In the simulation, an instructor (represented with voice over plus character photos) narrated how she solved the problem. She walked through each step of her thought process. The actual story was pretty thin (an instructor has a problem in the LMS), but the character gave learners enough to relate to. This training gave learners more confidence that they could troubleshoot it because the process was modeled by a character similar to themselves.

How Do You Use Stories and Scenarios?

How do you use stories and scenarios in software training? Do you have a great example of your own? Share it in the comments.

If you’re developing software training and are feeling stuck, feel free to share that in the comments as well. We can brainstorm together ways to use stories to make your training more relevant and engaging.

Save

Save

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.