Keeping Track of Alternate Paths

In my previous post, I explained how I built a single “ideal path” in my branching scenario. What was left was filling in the branches for the alternate paths. In my Twine prototype, I tagged each step with Good, OK, or Bad and numbers 1-5. Each slide title includes a label like [OK 2] or [Bad 4] to correspond with the tags in Twine. The Good choices were the ideal path and previously built. As you can see in the image below, my method of keeping track of what I’ve built so far isn’t very high tech.

At this point, it doesn’t really matter what order you build the slides in, as long as you keep track of what you’ve built. I started from the first decision and built out those alternatives, working through until I hit an ending with a restart. Then I went back to the next decision and built out that path.

Because this branching scenario has a lot of “parallel branching” and results that are reused in multiple paths, I quickly reached a point where I was linking to existing slides for some choices rather than always building new slides. Once a slide was built, I updated the triggers from the previous slide(s) to jump to it.

Using a “Not Built Yet” Placeholder

I created a slide titled “Not Built Yet.” Every time I created a button for a choice that led to a slide I hadn’t created yet, I linked to this “Not Built Yet” placeholder. I could have just left those triggers unassigned, but I found it easier to look in Story view and see which slides still linked to the placeholder. That showed me what was missing at a glance, rather than having to open each slide to view the triggers.

Once the “Not Built Yet” slide was on its own, disconnected from all other slides in the upper right corner, I knew I was done with the initial build.

Problem #1: Missing a Setting

I realized I need one more background with a coffee shop. I have one ending where Sophie refers the client to a colleague and meets up with her a few months later to find out how it’s going. I also needed another character for that colleague. I had missed this one when I was planning the layouts and forgot that it didn’t follow the pattern of emails and phone calls from the rest of the scenario.

This was fortunately a pretty easy fix. I used a photo of a coffee shop by Jazmin Quaynor on Unsplash and blurred it to match the other backgrounds. I also picked another character from the content library.

Problem #2: Reusing a Result for both Phone and Email

This branching scenario is a little more complicated than some I’ve built because it starts on email but moves to phone conversations (at least on some paths). When I made my prototype, I didn’t realize that OK 2 was a choice for both email and phone. In Twine, the jump in setting isn’t as obvious, but it was really abrupt to be on a phone conversation and suddenly jump back to email without a transition. I ended up creating 3 different slides for OK 2:

OK2a on email (used when you make this choice as part of the email thread)

OK2a on phone (used when you make this choice during a phone conversation, transitioning back to email)

OK2b on email (the second half of OK2)

The Twine prototype had 17 blocks; my final product in Storyline ended up with 19 slides because of these extra slides. (Counting the number of slides is one part of QA checking a branching scenario; you should have an identical number as your prototype unless you can account for a difference like this.)

After I built it, I realized I could have condensed this to a single slide with three layers. I could have controlled which layer was shown by checking which slide they had previously visited. However, this solution worked, and I don’t mind a few extra slides.

Problem #3: Broken Triggers

I always hit a point in projects like this where I’m too close to the work and I can’t find my own mistakes. Once I thought I had the scenario complete, I had a few testers check it out. They found a couple of places where the triggers to jump to a slide or to show a conversation were broken or missing. Those are easy fixes, of course, but they show why having multiple testers is so valuable. Hardly anyone will go through every single possible path, but between multiple people, you’ll probably catch these issues.

Problem #4: Unclear Conversations

In the phone conversations, the reading order is left to right. However, two of the testers felt that visual language convention wasn’t clear, and they weren’t sure the order of dialog. I added a short fade in for the conversation bubbles, bringing the one on the left in first and the one on the right on a slight delay. Hopefully the fade and timing change will help clarify the reading order.

Problem #5: Readability and Contrast

One tester suggested reducing the transparency of the white box and lightening the gray shapes to improve the contrast and readability. You can see the difference here; it is definitely easier to read, especially on smaller screens.

(As a side note, this is one of the times when Storyline really annoys me. In Captivate, I would have used object styles, so I could have changed every conversation bubble and transition box in 2 minutes. In Storyline, I had to change the color of each object on every slide individually.)

Time to Build

The total time to build this scenario, including the time to make the changes noted above, in Storyline was 9 hours. Since this was 20 slides, that works out to about 30 minutes per slide.

Thank You

Thanks to my testers who volunteered their time to review this and provide feedback to improve it.

George Tucker (Hi Dad!)

Nejc Žorga Dulmin

Leslie Marquez

Corrie Fisher

Jerson Campos

Complete Branching Scenario Process

Read more about the process of creating this scenario, starting from the very beginning of planning.