Most branching scenarios test whether someone can recognise the right answer when it is sitting in a list of four. That is not a decision. That is a quiz wearing a costume, and it is why so much scenario-based learning design changes nothing on the floor.

The format is not the problem. The thinking behind it usually is, and the same broken principles show up across whole 2026 strategies.

Why does scenario-based learning design fail so often?

Because the scenario is written backwards. Someone starts from the content they already have, then invents a situation that happens to require it. The learner feels the seams immediately.

Real decisions do not arrive as a tidy question with four options. They arrive underspecified, at a bad moment, with someone waiting. If your scenario removes all of that, you have removed the thing you were trying to teach.

Good scenario-based learning design starts from a decision people actually get wrong, not from a module that needs a home. Ask your managers which call goes badly most often. Build that.

I have seen beautiful branching builds that nobody needed. Why Most Instructional Design Methods Are Broken covers how that happens.

What makes a decision worth simulating?

Three things. It has to be frequent enough to matter. It has to be genuinely ambiguous. And getting it wrong has to cost something the business can name.

If any one of those is missing, write a job aid instead. For example, a one-page decision guide costs a fraction of a scenario and often works better.

The Kirkpatrick Model is useful here: a scenario should target level three, behaviour on the job, rather than level two, what someone can recall in the room.

How do you write a scenario that cannot be gamed?

Remove the tells. If one option is noticeably longer, kinder or more thorough, people will pick it without thinking. Make every branch defensible to someone, because in the real situation it was.

Then let the wrong path play out. Most builds snap back and correct you instantly. That is comfortable, and it teaches nothing. Consequence needs a moment to land.

The hardest part of scenario-based learning design is writing plausible wrong answers. However, that is also where the learning is, so it is worth the time it takes.

Specifically: ask the people who make the mistake why it looked right at the time. Their reasoning becomes your distractors. Invented wrong answers always sound invented.

Who should actually write them?

Not the designer alone. The designer owns the structure and the pacing. The person who does the job owns what is true.

That pairing is not optional. A scenario written without a practitioner in the room produces situations that feel almost right, and almost right is worse than obviously fictional, because it quietly teaches the wrong instincts.

Keep the loop short. One hour with an expert beats three rounds of written review, and it is the same argument as building the capability in-house rather than buying it in.

What should you measure?

Not completion. Not the score inside the scenario either, which mostly measures how well someone reads your distractors.

Measure the real decision afterwards. Pick the metric before you build: escalation rate, rework, time to a correct call, complaints of one specific type. Agree it with the sponsor while the budget conversation is still open.

In contrast, a scenario with no agreed downstream metric will be judged on how it looks in a demo. That is a bad way to choose what to build next.

How do you know it worked?

Watch what happens when someone hits the same situation live. Does the hesitation shorten? Does the escalation stop arriving? Those are observable without a survey.

Ultimately, the test of scenario-based learning design is behavioural, not emotional. People enjoying it is pleasant. People deciding differently is the point.

Furthermore, ask managers a single question ninety days later: has anything changed in how your team handles this? If nobody can answer, the scenario was decoration.

Three things to do before you build the next one

  • Name the decision, in one sentence, and the metric that moves if people get it right.
  • Get the wrong answers from people who have made them, not from the design team.
  • Let one branch end badly, and leave it there long enough to be felt.

Scenarios are expensive. Spend that money on the decisions that actually cost you something. If you want help working out which those are, book a Discovery call at https://calebfoster.ai.