How to Write Alternate Paths

By Christy Tucker 3 years ago

After writing the ideal path for a branching scenario, write the mistakes and consequences. These create the alternate paths in the scenario.

How do you create alternate paths in branching scenarios? In a 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. I use Twine to make the process of creating alternate paths easier.

First, Draft One Alternate Path to Its Conclusion

I start by 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.

Screenshot in Twine showing the ideal path and placeholders for alternate paths

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 Choices

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

Screenshot from Twine showing choices reused

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.

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?

This post is part of a series showing the entire process of creating a branching scenario from start to finish.

Originally published 11/21/2017 as “Writing Mistakes and Consequences.” Updated and republished with a new title 10/20/2020.

Tags: , ,