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, “ 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.