Design a branching training scenario

A branching scenario trains judgement by letting people make the decisions they face at work and see what happens. It works when the situation is specific and believable, every option is something a real person might choose, and consequences unfold in the story before any instructional feedback appears. Weak scenarios have one obviously correct option, "wrong" choices nobody would make, and an instant "Incorrect!" that teaches nothing. Full branching explodes in size, so practical designs fold paths back together and let a poor choice make later decisions harder rather than spawning a whole new tree.

Design a branching scenario with 4 decision points on the main path.

Audience:
ph:audience

1. If the skill is too general to stage as one situation (for example "leadership" or "communication"), ask which specific situation to stage and stop. If real mistakes people make are not given, base distractors on common, plausible errors and mark them for a subject-matter expert to confirm.
2. Scenario brief: the learning goal as an observable behaviour, the setting, the learner's role, the other characters (with what they want), and what is at stake. Keep it to one situation the audience actually meets.
3. Branch map: a Mermaid flowchart of scenes, choices and endings, using a foldback structure: poor choices lead to a recovery scene with a harder state, then rejoin the main line, so the total stays manageable (about 2 to 3 times the number of decision points in scenes).
4. Scenes: for each decision point write:

• the situation in 60 to 120 words, with realistic dialogue;
• three options: the strongest choice, a plausible but flawed choice, and a common mistake. All three should be tempting to someone in the audience; none is silly or rude for no reason;
• for each option, the consequence shown in the story (what the other character says or does next), then a short feedback note that explains the principle in plain terms.

1. Endings: a strong, a mixed and a poor ending, each showing realistic outcomes, with a path back ("try again from scene 2").
2. Debrief: 5 or 6 questions that move from what happened to why it worked and how it applies at work, plus the 2 or 3 principles the scenario teaches.
3. Build notes: how to run it as e-learning (variables to track, such as trust or time, and where they change) and as a live session (the facilitator reads scenes, groups vote, discuss, then reveal).

• Keep the options similar in length and tone so the best one is not given away by being longest or kindest-sounding.
• Show consequences before feedback. Feedback explains; it never scolds.
• Do not invent organisation-specific policy, legal rules or safety procedures; use placeholders such as [refund limit] where they matter.
• Characters are diverse and realistic without stereotypes; no character is a caricature villain.
• Write for [AUDIENCE]: vocabulary, setting and stakes they recognise.

Scenario brief

Short paragraphs and a character list.

Branch map

A Mermaid flowchart TD code block with node ids that match the scene headings.

Scenes

One ### heading per scene: situation, then options A/B/C each with Consequence and Feedback.

Endings

Strong, mixed, poor.

Debrief

Numbered questions, then key principles.

Build notes

E-learning bullets, then live-session bullets.