Branching Scenarios Design
There is a point in many branching scenario projects where things start to get complicated very quickly. You create a character, give them a problem, write some dialogue, and then add a choice. But every choice needs a response, every response seems to need another decision, and before long the storyboard has turned into a small transit map.
It is easy to conclude that branching scenarios are simply difficult to build. I think the problem is often more specific than that: we start with the story and then try to work out where the decisions should go.
A branching scenario is not really a story with choices added to it. It is a decision-making experience, with enough story around it to make the decision feel real. Once you make that distinction, the design process becomes much easier to control.
Start With What The Learner Actually Needs To Do
Suppose you are building training for managers on giving feedback. A common starting point might be, “Teach managers how to give effective feedback.” There is nothing wrong with that as a learning topic, but it does not yet tell us what the learner needs to practise. They may need to understand a feedback model, know the organization’s process, or recognize the characteristics of good feedback. None of those necessarily requires a branching scenario.
Now change the starting point slightly: “Help a manager respond when an employee becomes defensive during a feedback conversation.” That is different. There is judgment involved. The manager knows they need to give feedback, but now they have to decide what to do when the conversation does not proceed neatly.
This is why I like to begin scenario design with questions about behavior. What should the learner be able to do? What difficult decision will they face in the real world? What commonly goes wrong? The character, dialogue, setting, and visual treatment can all come later. First, you need to understand the decision you are trying to help someone make better.
Find The Moment Where Judgment Matters
Once we have a situation, there is another temptation: write the entire conversation. But most workplace conversations contain a lot of moments that do not require much judgment. The learner does not need to make a decision after every sentence. Instead, look for the point where reasonable people might genuinely respond differently.
Perhaps the employee says, “I don’t think this is fair. The brief changed twice, and nobody told me what you actually wanted.” Now the manager has a real decision to make. Do they defend the feedback? Ask a question? Back away because the employee is upset? Acknowledge that expectations shifted, but continue addressing the performance concern?
The useful questions at this stage are quite practical. What should the learner say? What should they do first? What information should they consider? What risk should they address?
That also helps control complexity. You do not need to simulate every sentence of a 20-minute conversation if the learning really depends on 2 or 3 judgment moments within it.
Write Choices A Smart Person Could Actually Choose
This is where many branching scenarios quietly turn back into multiple-choice questions.
You give the learner three options, but one is clearly the correct answer, one is obviously terrible, and the third exists mostly to fill the screen. The scenario may look realistic, but the learner is not doing much thinking.
A stronger approach is to make each choice represent a different way someone might genuinely interpret the situation. One manager might think, “I need to establish authority before this gets out of control.” Another might think, “They are upset, so I should probably leave the performance issue for another day.” Someone else might decide they need more information before responding.
These are not random distractors. They represent different mental models. So avoid absurd answers, choices that differ only in wording, or trivia disguised as decision-making. Instead, build options around plausible approaches: avoiding the issue, addressing it too aggressively, asking questions first, or following a process without considering the context.
Instead of asking, “What are three answer options I can give the learner?” I would ask, “What are three believable ways someone might think about this situation?” That small change tends to produce much better scenarios.
Let Learners See What Their Decision Changes
Feedback is another place where scenario design can easily fall back into quiz design. The learner makes a choice, and the course immediately tells them they are correct or incorrect. But that is rarely how decisions work in real life. Real life gives us consequences.
Perhaps the employee becomes defensive. Perhaps they stop talking. Perhaps they reveal information the manager did not previously know. Perhaps trust increases because the manager handles the conversation thoughtfully. Or perhaps the immediate conversation appears to go well, but an important issue remains unresolved. Those outcomes are more useful because they make the relationship between decision and result visible.
When I design scenarios, I like the consequence to affect something the learner should care about: trust, safety, performance, time, cooperation, customer confidence, or organizational risk. The instructional explanation can come afterwards, once the learner has seen what their choice produced.
For example, instead of telling a learner, “Incorrect. You should have asked more questions,” the scenario might show the employee responding, “Fine. If you’ve already decided what happened, I’m not sure what else you want me to say.” Now the learner has something to interpret. The feedback can explain why the response reduced openness, but the consequence has already done some of the teaching.
This is also why I distinguish between consequences and punishment. The goal is not to make the learner suffer for choosing the “wrong” answer. It is to make cause and effect visible enough that they can understand the impact of the decision and, ideally, recover from it.
Not Every Branch Needs To Keep Branching
Once you start showing different consequences, the obvious question is: what happens next?
This is where complexity can multiply very quickly if we assume that every decision must create an entirely different future. It does not.
A branch can end after the learner sees the consequence. It can return to a shared path. It can loop back for another attempt. Or, when the learning genuinely requires it, it can change a variable that affects what happens later.
A quick compliance decision might simply be decision, choice, consequence, end. A leadership conversation might show three different reactions and then bring everyone back to the next common moment in the conversation. A more sophisticated simulation might allow earlier decisions to affect later outcomes. All three can be good design.
The question I would use is: what is the least complex structure that still allows the learner to practise the thing that matters? Branching complexity should follow the learning need rather than become a goal in itself.
Image Credits:
- The images within the article were created/supplied by the author.
