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 behaviour. 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 two or three 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.
There is no particular instructional value in having 40 branches if six would have taught the same thing.
Start smaller than you think you need to
For someone building their first branching scenario, I would make the first version deliberately modest: one scenario, one important decision, three believable choices, three short consequences, and one opportunity to retry or reflect.
That structure is simple enough to build and test, but still gives the learner meaningful practice. It also forces the designer to focus on the quality of the decision rather than getting distracted by the mechanics of the branch.
You can always make the scenario more complex later if the learning outcome demands it. It is much harder to rescue an overbuilt scenario once the logic has spread across dozens of slides, variables, and paths.
Test the thinking, not just the triggers
Branching scenarios obviously need technical testing. Every button needs to work, variables need to behave correctly, and learners should not accidentally reach a dead end.
But instructional testing matters just as much.
Read the scenario as though you were the learner.
Do all of the choices feel believable?
Are the consequences proportionate?
Is the correct response too easy to spot?
Can the learner understand why their decision produced that outcome?
Does each branch actually teach something?
And then ask one more question: could I remove this branch without losing anything important?
If yes, remove it. A branch is not valuable because it exists. It is valuable because it gives the learner another meaningful opportunity to think.
AI can help with the writing, but it still needs the decision
AI makes parts of this process much easier. Once you know the learner, situation, desired behaviour, common mistakes, and judgment moment, it can help you generate dialogue, explore alternate responses, strengthen weak choices, or suggest different consequences.
That is useful, especially because writing believable alternatives has traditionally been one of the more time-consuming parts of scenario design.
But the order matters. I would first define the topic, audience, situation, desired behaviour, and common mistakes. Only after that would I use AI to generate options, dialogue, or variations.
AI can produce 20 possible responses very quickly. It cannot tell you which decision is worth practising unless you have first understood the performance problem.
The expertise remains in the framing.
The story is there to make the decision matter
I like good scenario stories. Characters, context, dialogue, and consequences are what make the experience feel different from a conventional knowledge check.
But the story is not the instructional architecture. The decision is.
The learner needs to look at an imperfect situation, decide what matters, make a choice, and see what that choice changes. The story exists to make that moment believable enough that the learner has to use some of the judgment they will eventually need at work.
So the next time you open a storyboard to build a branching scenario, I would not start by asking what the character says first. Start by asking what decision you want the learner to become better at making. Once that is clear, the rest of the scenario has something solid to grow around.
