I’m kicking off a series of posts about scenario-based training. Let’s start with the big picture: The design process.
Many people start writing a scenario too soon. They invest a ton of time only to find their work rejected by the client or learners.
Use the steps below to make sure you’re writing a challenging scenario and going in a direction everyone will like. It’s far easier to adjust a few notes than it is to throw out a story you spent hours writing.
The main takeaways:
Analyze the problem! Make sure you understand why the task is hard to do properly.
Prototype first! Write one decision point and get approval for that before you write another word.
For a branching scenario, sketch and test the plot before writing the story.
Here are the details, mostly copied from my book Map It. For lots more about every step, see the book.
1. Analyze everything. Don’t skip this!
Write a project goal. Identify how you’ll measure success for the project as a whole.
List the specific, observable actions people need to take on the job to meet that goal. Prioritize those actions.
For the high-priority actions, ask, “Why aren’t they doing this now?” or “What might make this difficult?” First consider the environment (tools, systems, and culture), to avoid assuming that the problem comes entirely from a lack of knowledge or skills.
Note the non-training solutions you’ve probably discovered from the above discussion, and identify the behaviors that will probably benefit from practice activities.
Identify the best format (live, elearning, etc.) for each activity idea and the best time for the person to use the activity (such as right before performing the task, in short sessions spaced out over time, etc.). Don’t assume a “course” is the best solution, because it rarely is.
If the skills addressed in the scenario are complex or controversial, determine how you’ll provide a debrief or other way for people to discuss issues and see the larger picture.
2. Prototype one decision point
First, draft one challenging question.
Pick a typical behavior that will be addressed with a scenario activity. You’ll turn it into a prototype decision point. It can be a standalone mini-scenario or one decision point in what will become a branching scenario.
Interview your SME for the prototype activity. Get the understanding you need to create a believable question, tempting options, and realistic consequences for those options. Capture the common mistakes and why people make them in addition to the best choice and what makes it difficult to make.
Write a stem. The stem is the setup and question for your decision point. Use the insight you got from the SME to recreate the real-life issues that tempt people to make the wrong choice.
Write the options. Include the common mistakes that the SME identified and make them sound like good choices.
Write unique feedback for each option. Show the consequence of the choice by continuing the story. You might also provide instructive feedback (“You should have done X”), possibly as an optional explanation, but first show the consequence.
Next, add any supporting information, and make it optional.
Decide what is the minimum information the player must have to make the decision in your prototype.
Decide when and in what format you’ll provide the minimum supporting information. My usual recommendation: Put it in a real-world job aid, if that’s appropriate, and have people refer to the job aid when they’re considering the question. Don’t present the information before the activity; let people pull it if they need it. Also provide a snippet of the information in the feedback to reinforce or correct each choice.
3. Test the prototype before you write another word
Create a mockup of the prototype decision point and test it on the SME, client, and a group of learners. If the prototype is a decision point in a longer scenario, describe the bigger story that the question is part of, but don’t write it yet.
Your prototype will help determine how people will choose options, what information they’ll have available and when, whether they can go back to make a different choice, how they receive feedback, and what the feedback contains.
If you’re creating one-scene mini-scenarios, once your prototype is approved, you can confidently crank out several more scenarios using the same format. Consider sending them to your SME in batches, so the SME can consider one batch while you write the next.
If you’re creating a branching scenario, you aren’t done yet.
4. Branching scenario: Additional steps
Once your prototype is approved, you’ll:
Identify the story endings. You might have one “best,” some “fair,” and a few “poor” endings. Decide in general what decisions a person would make to reach each ending.
Write a high-level plot as a flowchart or in a tool like Twine. Use notes only; don’t write a script. (I use Twine because I can complete all remaining steps in it, it’s flexible, and it’s free).
Consider writing the best path first and then filling in the less-good paths. Connect paths so players can realize that they’re heading toward a bad ending, make a better choice, and end up on a better path.
Get feedback on the plot. Consider including future learners in the review. You’ll probably need to describe what happens, since you’ve written only notes. Make sure the plot is realistic and complex enough to be challenging. Most first drafts are too simple.
Once the plot is complex enough and approved, flesh out your notes to turn them into a story.
Write debrief questions as you flesh out the plot. You’ve probably chosen a branching scenario because the skill to be practiced is complex and full of grey areas. Help people see the big picture and process what they’ve learned by planning to ask thought-provoking questions during a debrief.
Get feedback on the complete story. Again, I recommend including learners in the review.
See chapter 13 of Map It for detailed questions to consider at each review. And for lots more about scenarios and to get my help in writing your own, consider signing up for the next scenario design online workshop.
This is the first in a series of posts about scenario design. Make sure you don’t miss the next one — sign up to receive email updates of new posts.