Branching Scenarios Should Teach Decisions (Not Clicking Until Green)

Picture the pilot debrief for your new branching scenario. Someone asks a sales manager what she thought, and she says it kindly: “I just clicked until the screen turned green.” The scenario had three branches, and every wrong turn ended in the same paragraph of policy text.

If you have sat in that debrief, you know the pause that follows. The build took weeks, and the one thing the room agrees on is that it behaved like a quiz.

Good branching scenario design starts from one decision people face at work, before anyone writes a character. Write each option as an action, let the scene show what it costs, give learners a way back in, and judge the result by decisions on the job. I've filled in a decision card you can copy.

Key takeaways

• A branching scenario teaches only when it is built around one consequential decision people face at work, chosen before any character or dialogue exists.
• Wrong options should be plausible actions a well-meaning colleague would take, and each should lead to its own consequence in the scene.
• A recovery path lets the learner re-enter the decision with new information, and that second attempt is where the practice happens.
• Branching only as deep as the decision requires keeps writing, review and build small without losing any practice.
• Judge a scenario by decisions observed on the job, with a first look about three weeks after launch and a second at 90 days.

Why does a branching scenario end up feeling like a quiz?

Because the wrong answers are easy to spot and every wrong turn ends in the same correction, so the learner solves a puzzle and never makes the judgment call. More branches won't fix that, but better choices and real consequences will.

• Instead of: the screen says “Incorrect” and repeats the same policy paragraph after every wrong turn.
• Try: the scene answers, with the colleague's reply, the client's reaction and what is now harder on Monday.

Nikolay Sapunov names the pattern in a June 2026 post on the blog of Fora Soft, a video-production firm writing about branching video. Teams treat interactivity as proof of learning, and a scenario where every choice earns praise, or where the wrong answer is obvious from the wording, “generates clicks and completions and teaches nothing.” That is one practitioner's opinion with no study behind it, and it matches what your debrief just told you.

I think two habits do the damage. The options describe the situation (“The colleague is under time pressure”) when they should act in it, so learners pick whichever statement sounds most like the policy. Then the verdict screen repeats itself whichever way they went, and they conclude that a choice changes only the color of the screen.

(Nobody has ever listed a green screen as a learning outcome.)

Which decision is worth building a branching scenario around?

One consequential decision that people face in ordinary weeks, where sensible colleagues choose differently under pressure. Pick it before you write a character or a line of dialogue.

Garima Gupta, founder and CEO of a learning firm, argues in an August 2026 bylined article on starting with the decision that scenarios get complicated when design begins with characters and dialogue. Her order puts the real-world decision first, then believable choices and consequences, and “only as much branching as the learning outcome requires.”

I'd start with a four-part filter. If a candidate fails any part, pick another decision before anyone opens the authoring tool.

• Consequential: a wrong call costs someone something real.
• Recurring: it comes up in ordinary weeks.
• Contested: sensible people choose differently under pressure.
• Observable: a manager or a system can see whether it happened.

Then write the decision as something a manager could see someone do. “Speaks up about a skipped check before the item goes out” passes; “understands the four-eyes principle” doesn't.

“Fine, but my sponsor hears expensive and asks if a few slides with a quiz would do.” A narrow scenario is your answer, because one decision branched only as deep as it needs keeps the scope small enough to approve.

The cost point is sharpest for filmed scenarios, since Sapunov notes that every branch multiplies the video you must produce. His post is about video, so I won't claim the same for other builds, though every branch is still another page your SME has to review.

What should a wrong choice show instead of a red X?

It should show what happens next in the scene, the way the colleague or the client would actually react. The explanation of why can come afterward, as a separate step.

Christy Tucker draws that line in a May 2025 post on her Experiencing Elearning blog. “Consequences are what happens as a result of decisions: what they see, hear, or experience,” she writes, and “Feedback is what we tell learners after decisions.” Her example of an immediate consequence is a customer who responds angrily, which never has to say the word incorrect.

So I'd skip the “Correct” and “Incorrect” banners and let the scene answer. A learner who watches the client go cold has to work out why, and working it out is the practice.

The wrong options have to tempt, too. Sapunov's advice is to make them the kind of choice “a real, well-meaning person would make,” and to let consequences sting a little before teaching through them.

Recovery paths are where the practice happens. After a costly choice, bring the learner back into the decision with what they now know, or into a follow-up scene where the damage can still be repaired. In my view, nobody should hit a game-over screen in a practice scenario, because the second attempt is what trains the moment.

What does a decision-first scenario look like on a Friday afternoon?

One team lead, one skipped check and a client who is waiting, with every option written as something she could actually say or do. The decision card after the scene shows it filled in.

Picture a team lead in the operations group of a financial services firm, late on a Friday. A client has called twice about an item that is ready to go out, and she watches a senior, well-liked colleague skip the second-person check so it leaves sooner. Nobody else is watching, and she has about a minute to decide whether to say something.

Suppose the scenario she took last quarter offered three options, one obviously right, and every wrong one ended in “Incorrect. Please review the policy.” She has no first sentence ready and no feel for what silence costs. So she says nothing, the item goes out, and the following week a second colleague skips the same check.

In the decision-first version, every option is an action and each leads to its own scene. Choosing silence takes her to a Monday where the shortcut has spread, and she can step back into the moment knowing that. On the real Friday she already knows how the aside sounds and what it costs her, so she says the first sentence.

If that moment looks familiar from your compliance work, there's more on why rules bend under pressure in an ordinary week.

The decision card, filled in

Every detail on this card is hypothetical. Swap in your own decision, roles and look-for.

1. Decision: Whether the team lead speaks up when a colleague skips the second-person check on an item a client is waiting for, written as one sentence a manager could observe.
2. Pressure: The client has called twice, the colleague is senior and well liked, and nobody else is watching. Put all of that in the scene itself.
3. Options: Three plausible actions, none labeled right: say nothing and finish your own work; ask about the check in front of the team; take the colleague aside and ask for the check before the item goes out.
4. Consequences: Each one plays out as a scene. Silence: the item goes out, and on Monday a second colleague skips the same check. The public question: the check gets done and the colleague bristles for the rest of the week. The aside: the colleague is annoyed, does the check, and the client waits a little longer.
5. Recovery path: After silence, the learner re-enters at the Monday moment with the new information. After the public question, a short follow-up scene lets her repair the relationship.
6. Look-for: One thing a team lead either did or didn't do: raised a skipped check in the moment. Managers check for it about three weeks after launch and again at 90 days, using the same question.

In our Behavior Bridge method, this card goes into the script and storyboard in the Write Before We Build phase. The storyboard gets one consolidated review before anything is built, and the result is the Approved Storyboard, so everyone agrees on the consequences and recovery paths on paper first.

How do you know the scenario changed decisions on the job?

You look at what people decide afterward, in the work, where click paths and completion can't follow. Before launch, name the one decision a manager or a system can see, then look about three weeks after launch and again at 90 days.

The research is thinner than the enthusiasm. A 2025 action case study by Pimblett, Rowe and Fenton in the International Journal of Organization Theory and Behavior followed ten adult learners through thirty interviews around one branching-scenario module. According to the abstract, engagement was strongest when scenarios mirrored real job tasks and let learners make contextual decisions and experience “safe failure”.

That supports building around real decisions. It is also ten learners and a study of engagement, so it says nothing about what anyone did differently at work.

“I can't get the on-the-job data.” You may not need a system. I'd ask each team lead's manager one question with one shared look-for: in the last two weeks, did you see a team lead raise a skipped check in the moment, and can you give one example? For the fuller version, with a baseline and a one-page plan, see how to measure what changes after training.

Back to that pilot debrief. The next time someone asks a manager about the scenario, the answer can be a decision: “I took her aside before it went out, and I knew what to say because I'd already seen what silence leads to.” This week, take your worst wrong branch and rewrite its ending as a scene, starting with what the other person says next.

If you have a branching scenario your learners clicked straight through, send it to us for a free diagnostic: you send one existing module and get the three highest-impact improvements within one to two working days.

FAQ

How many branches does a scenario need?

As many as the decision needs and no more: plausible options, a consequence for each and a way back in after a costly choice. Gupta's advice to branch only as far as the learning outcome requires is a good brake. If a branch doesn't change what the learner decides next, I'd cut it.

My sponsor asked for slides with a quiz. How do I argue for a scenario?

Ask which decision the sponsor wants people to make differently, then propose a scenario around that one decision. Bring the decision card as the single page to agree on before anyone writes a screen. One page is easier to say yes to than a branching map.

Who should write the consequences, the SME or the designer?

In my view, the designer, working from what the SME shares in a working session. Our method uses one Behavior Workshop and one consolidated review before build, and the SME's review is where the consequences get checked for accuracy.