Tag: branching scenario

Branching Scenario Prototype in Twine

I built this branching scenario in the open source tool Twine. This scenario is moderately complex, with a total of 17 pages (or passages in Twine terminology) and 8 different endings. The ideal path has 5 decisions to reach the best conclusion.

I generally use Twine as a prototype for review and testing purposes. You can use Twine as the finished product though, especially if you do some formatting to make it look better. This is currently pretty rough (just text on a white background), but that’s OK for a prototype.

If you use Twine as a prototyping tool, you can build the finished version in Captivate, Storyline, or another tool of your choice.

Try the scenario out yourself by clicking below (the scenario will open in a new tab).

Click to open the scenario in a new tab.

This is the map of the entire scenario. You can see how many of the choices are reused.

Twine map of the entire scenario

Want to learn how I created this?

Read the previous posts in the series to see my process for creating this scenario.

 

Can’t get enough? Check out all of my posts on Storytelling and Scenarios.

 

 

ID and eLearning Links (12/3/17)

  • This is the link I send people to debunk the blanket claims about “people forget X% after Y time.” The reality is that how much people forget depends on who your audience is, what they’re learning, and how you train them.

    tags:training instructionaldesign research myth

    • The amount a learner will forget varies depending on many things. We as learning professionals will be more effective if we make decisions based on a deep understanding of how to minimize forgetting and enhance remembering.

    • To be specific, when we hear statements like, “People will forget 60% of what they learned within 7 days,” we should ignore such advice and instead reflect on our own superiority and good looks until we are decidedly pleased with ourselves.

    • Many of the experiments reviewed in this report showed clearly that learning methods matter. For example, in the Bahrick 1979 study, the best learning methods produced an average forgetting score of -29% forgetting, whereas the worst learning methods produced forgetting at 47%, a swing of 76% points.

  • Mini-scenarios and branching scenarios provide better assessment than traditional multiple choice, but this provides some other options for deeper assessment that can still be scored by a computer.

    tags:assessment scenario e-learning instructionaldesign feedback

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

Instructional Design and E-Learning Links

Writing Mistakes and Consequences

In my previous post, I explained how I write the ideal path for a branching scenario first. Once that is complete, I write the mistakes or errors and consequences for those choices.

First, Draft One Alternate Path to Its Conclusion

I start writing a single alternate path from beginning to end. This is the easiest way for me to create continuity in the narrative. I have the ideal path already created at this point, but you can see below that some choices are dead ends. Other choices are still marked as TBD for placeholders.

branching-ideal3

In this case, I’ll go back to the very first decision and start writing the mistakes and consequences. When I was drafting the ideal path, I knew the worst choice was to send a price estimate right away. I’ll start there and finish writing that path. In this case, this mistake is a big one that will result in an immediate failure and restart.

Sophie provides a fixed-price quote based on her limited information. Robert immediately accepts without negotiating, making Sophie wonder if her price was too low.

One month into the project, Sophie realizes what a terrible mistake she has made. She severely underestimated the scope of the project and the time required. She’s frustrated, and her client is frustrated at how long everything is taking. Sophie works long hours for weeks–so many hours that her effective hourly rate is much lower than usual.

Once the project is finished, Sophie vows to never give a price estimate again unless she has more information.

Draft Another Alternate Path (and Another, and Another…)

Once the first alternate path is written, go back to the beginning of the scenario. Find the first decision point that isn’t fully fleshed out, and start writing there. As before, try to write one complete path from start to finish.

In this example, I go back to the first choice. In my first pass at drafting the ideal path, I left a placeholder for “Some other OK choice TBD.” Now I need to create a third option and follow through on the consequences.

In this case, a partially correct choice would be to ask specific questions about the project. (The best choice is to ask high level questions about the business goals first, rather than getting into the details of the training too early.)

Sophie realizes she doesn’t have enough information to provide an accurate estimate. She asks Robert to clarify how long the courses actually are.

Robert replies with the details.

  • Course 1 is a half day (3.5 hours).
  • Course 2 is one day (about 6 hours).
  • Course 3 is two days (about 12-13 hours).
  • Course 4 is four days (about 26 hours).

What should Sophie do next?

[[Send Robert a price estimate for the whole project.|Send Robert a price estimate.]]
[[Ask Robert what level of eLearning he wants.]]
[[Ask Robert some high level questions about goals and budget.|Send Robert some client screening questions.]]

I continue like this with each choice until every path reaches its conclusion. I use my notes from my conversations with the SME and other stakeholders, plus any other research, to determine realistic consequences.

Good, Bad, and OK

By default, I usually aim for one choice that is the best (the ideal path), one choice that is clearly bad, and one choice that is OK or partially correct. If you’re stuck on what choices or mistakes to provide, try aiming for that pattern in each choice.

I do vary that, especially later in the scenario. By the time someone has made multiple good choices and is nearing the end of the ideal path, there might not be any terrible choices. It may be Good-OK-OK instead. If someone has made a large mistake, there might not be any good options; maybe the best recovery is an OK choice.

In Twine, I tag my choices as Good, Bad, and OK. In PowerPoint or other tools, I usually color code them in a flow chart as green, yellow/orange, and red. This helps me keep track of the structure. It also helps voice over or actors know the tone if this will be turned into audio or video later.

Let People Recover from Mistakes

Not every mistake should result in immediate failure and a restart. Just like in real life, sometimes people can recover from their mistakes. Branching scenarios can help people practice that skill of moving past an error.

In the example above, I want the learners to have a chance to realize they’re getting into the details too early and to back up. After asking about the length of the training, they can choose to ask high level questions instead. That gets them back to the ideal path.

Screenshot from Twine showing choices reused

Crossing Paths

I usually have some paths that cross, as shown in the screenshot above. This is one reason I really like Twine for drafting branching scenarios, regardless of what tool or format the final version will be.

Often, I create several ways to get to the same path or ending. Reusing some choices or endings helps reduce the complexity of the scenario.

After a Failure

You have several choices of what to do next after you reach a failed ending of a scenario.

  • Ask learners to restart and try the scenario again. This is what I did in the immediate failure of providing a price estimate with woefully inadequate information above.
  • Let learners back up one step so they can make a better choice.
  • Let learners go back to a milestone or checkpoint so they don’t have to redo the entire scenario. This is especially helpful in longer scenarios with many decision points.

I explain the pros and cons of these restart or retry options in detail in a previous post.

Testing and Revising

Once I have a complete draft of everything, I test the options, reading through each path and revising to fix anything broken. I prefer to do this testing at least a day after I finish the initial draft. It’s easier to see my mistakes when I have time to set it aside for a while and come back later.

I also review my notes. Did I include all of the mistakes that were critical to include? Does the flow make sense? Is there anything too repetitive that should be collapsed into a single path or rewritten?

After that, it’s ready for me to send for review by the SME and other stakeholders. I post the Twine version as an interactive prototype so they can test it themselves. I also export to Word so it’s easier to track changes in wording (especially with multiple reviewers).

Looking for more?

Check out my previous posts on branching scenarios:

 

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)