Branching Scenario in Storyline

When I completed building this branching scenario in Storyline, I ran into a couple of issues. Here’s how I built the scenario and solved those problems. Check out the completed scenario yourself.

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.

Handwritten list of slides in the scenario

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.

Story view showing the branching structure and the "Not Built" slide isolated in the upper right corner.

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:

  1. OK2a on email (used when you make this choice as part of the email thread)
  2. OK2a on phone (used when you make this choice during a phone conversation, transitioning back to email)
  3. OK2b on email (the second half of OK2)
Comparison of email and phone showing similar text: "To give you an accurate estimate, I need to know how complex you want the elearning to be."

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.

Comparison of medium gray and light gray backgrounds for conversation bubbles. The light gray has higher contrast and is easier to read.

(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.

Branching Scenario in Storyline

4 thoughts on “Branching Scenario in Storyline”

  1. Pingback: Better to Write in Second or Third Person for Scenarios? - Experiencing eLearning

  2. Hi Christy
    I really enjoy reading your blog on branching scenarios. Terrific stuff. One question though – you mentioned that you could have displayed a layer by checking if a user had visited a previous slide. Could you explain what you mean? i.e. what storyline trigger/variables would you have used to make this happen?

    1. Basically, you create a variable to check if a slide has been visited or not. If that slide has been visited, you show one layer; if not, you show a different layer.

      For example, I would create a variable called “PhonePromptVisited” and set the default value to false. On the slide with the Phone Version above, I would set a trigger that when the timeline starts on that slide to change that variable to True.

      Next, on slide OK2, I would create a layer called Phone. I’d set a conditional trigger that when the slide timeline starts to Show Layer: Phone IF PhonePromptVisited = True.

      Does that make sense? It’s a little hard to explain in a comment. If you need more, I’ll put this in the queue to create a new blog post about it, with screenshots so you can see how I built it.

      Edited to add: There’s a good post explaining how to use variables to see if a slide is visited or not here:

Leave a Reply