Tag: prototyping

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.



3 Tricks for Working with SMEs on Branching Scenarios

If you’ve ever worked with a SME on scenario-based learning, you know it can sometimes be challenging. SMEs who are accustomed to working on traditional elearning may be uncomfortable or unsure how to help you write scenarios. I have used these 3 tricks to help SMEs get “unstuck” while working together.

Working with SMEs on Branching Scenarios

Ask for Their Stories

SMEs almost always have a collection of good stories about their topic. The trick is figuring out how to get those stories out of their heads and into a format you can use in a course.

Try these questions to gather for stories and consequences:

  • Can you give me an example of how someone used this technique successfully? What were they able to accomplish by doing it right?
  • What are the common mistakes people make? What happens when they make that error?

You may have to keep probing for more details with follow up questions like, “Tell me more about…” or “What happened next?”

The questions above give both positive and negative examples, plus the consequences for actions. The success story can become the outline for the correct path in your branching scenario. The mistakes help you identify the decision points in your scenario and the consequences following those choices.

Start Writing Even If It’s Wrong

Sometimes it’s hard to get anything from a SME. We’ve all worked with SMEs who were too busy to get on the phone or sit down for a meeting, or who replied to all of our questions with one- or two-word answers. I worked with one SME whose thought processes are so linear that she literally couldn’t read a flow chart unless someone physically sat next to her and pointed at each box while explaining it.

For whatever reason, if you’re having trouble drawing information out from a SME, start writing something yourself. Do your research–review existing training materials, online articles, books, blogs, etc. Make your best guess and start writing a scenario as best you can. The trick is, it doesn’t matter if it’s wrong. At this stage, you’re just trying to get something other than a blank page. Ask the SME to review it and point out all your errors. Even a recalcitrant SME will have a hard time not correcting your mistakes–and now you suddenly have more realistic mistakes or consequences.

Prototype Early

SMEs frequently have a hard time envisioning how a storyboard will translate into a final product. Creating a prototype early helps them see how everything will work and how learners will progress through the scenario.

No matter how hard you work on the storyboard, even with multiple rounds of revision and a final approval, expect at least some small changes once the scenario is built and functioning. Build a few iterations into your project plan. An early prototype helps catch major problems before you build the entire scenario. If your SME is stuck, a prototype of part of the scenario might help them see how to fill in the gaps for the rest of the scenario.

Your Tricks?

Do you have a great trick for working with SMEs on branching scenarios? Tell me about it in the comments!

Read More

Read all my posts about Storytelling and Scenario-Based Learning.

No Perfect Courses

One truth I have learned about instructional design is that I will never create a “perfect” course; there’s always something that could be better if I had more time or more resources or more skills.

When I interviewed for my first ID job, I asked my soon-to-be-peers the hardest part of their job. One answer stuck with me all these years. He said the hardest thing was knowing when to let go of a course. There’s always something more you could do, but at some point, you have to stop fiddling and launch it.

Handwritten word "imperfect" with doodles

When I go back to my old courses, I always find something I could improve—tightening up my language, tweaking the visual design to improve clarity, making an interaction more effective. Partly that’s because I always find something to revise in my writing after I’ve had time away from it. Partly that’s because I’m always learning, so I know how to do something now that I didn’t know when I created the course. I can make courses free of errors (typos, factual errors, etc.), but “perfect” is a goal that doesn’t really exist.

It’s hard for someone with perfectionist tendencies like me to admit that perfection isn’t attainable. This is, perhaps, an argument for rapid prototyping or agile development like SAM. If you release a minimum viable product to your audience, then you can keep iterating closer and closer to the ideal. You can let go of trying to be perfect at the start because you know you have lots of opportunities to fix it.

This is also an argument for planning to review and revise courses on a regular basis. I admit I haven’t been doing enough of this, especially since I’ve been consulting and not working as an internal ID. Too often, I hand off a course to a client and never even find out what happens after launching. I could do a better job selling clients on the idea of reviewing a course 60 or 90 days after launch and making improvements if needed.

Do you agree that there are no “perfect” courses? How do you handle it in your own work?