Branching Scenario Revision Requests

How do you manage branching scenario revision requests?

When we work with SMEs and stakeholders on branching scenarios, we inevitably receive feedback and requests for changes. In addition to the normal challenges of receiving feedback, editing branching scenarios can be especially complex. So how do you manage branching scenario revision requests?

Branching Scenario Revision Requests

The question

This blog post was prompted by a great question from Kayleen Holt, instructional designer and owner of Scissortail Creative Services. She graciously agreed to let me republish her comment as part of this post.

What process do you use for making updates to the scenario after you’ve built the scenario in Storyline but then the client requests additional changes in subsequent reviews? If you have to change how the story branches, do you go back to Twine for the structure?

I’ve used a Word document in the past, and as you know, it gets very hard to keep up with when you’re dealing with complex branching–and it’s hard for SMEs to review. I’m excited to try using Twine instead. I’ve played with it but haven’t actually used it in a project yet.

Setting expectations

First, I set the expectations early on that the majority of the changes should happen while we’re in Twine, before I rebuild it in Storyline. I would rather add an additional round of review in Twine than have to go back and change it in Storyline later.

With my consulting clients, that means my SOW specifies that any of those structural changes happen in Twine. Once they approve it in Twine and development starts, it should only be minor text tweaks, not structural changes. If it’s big structural changes, then it’s out of scope, and they’re going to pay for the additional time.

Reality check

In reality, even with setting those expectations, sometimes changes are required. It actually happened to me last year. This was a project with a client I’ve worked with before, but this was their first branching scenario. In spite of setting the expectations, I didn’t get much feedback on the Twine version. Almost all of the feedback happened after I’d build the content in Storyline.

A scenario that was originally 52 passages in Twine ended up as 75 slides in Storyline–significantly more changes than we had hoped. Sometimes you really do need to make the edits, and it’s worth the additional time and cost to do so.

Planning for revision

With this particular project, we knew this topic was subject to change. Therefore, I planned the scenario to make revisions a little easier.

Bottlenecks

In that case, I used sort of a “Short Sims” style approach, like Clark Aldrich’s examples. This scenario had a lot of bottlenecks, which provided pretty easy places to add some additional decisions into the structure. I didn’t go back to Twine for the revisions; I did everything in Storyline.

In the Twine structure below, each passage at the top is a bottleneck where additional decisions could be added without breaking the overall scenario.

Screenshot of a scenario with 52 passages in Twine. Across the top are a dozen bottlenecks in the scenario.

Even if your scenario doesn’t use as many bottlenecks as the example above, including a few bottlenecks really helps make these revisions easier.

No audio or video

That scenario also was text and images only, with no voice over or video. We had deliberately chosen that media because we knew we might need to do more updates later if their content changed. That made the changes in Storyline much faster than if I had also been dealing with audio and video.

Of course, there are times when video or audio are beneficial. If you’re showing non-verbal communication, you probably are better off with video. In those cases, it’s even more important to get as much input as possible in Twine, even if you need multiple rounds of review in Twine before you finalize your scripts.

Changes in Twine or Storyline

In that particular example, if I hadn’t had any bottlenecks, or the changes really fundamentally shifted the structure, I might have backed up in the process and gone back to Twine. I haven’t had to do so yet, but I can envision situations where the stakeholders requested such a fundamental shift in direction that making the changes in Twine would be more efficient.

The good news is that Twine (or a combo of Twine plus a text export) makes it so much easier to review that the SMEs are much more likely to catch any big structural problems earlier. You can’t eliminate the possibility of big changes, but you can certainly reduce the likelihood of massive, scenario-breaking revisions.

Looking for more?

Check out these posts on branching scenarios with Twine:

Leave a Reply

Archives