Planning a Branching Scenario

eLearning

Planning a Branching Scenario

by michaelg September 28, 2020

Author: Christy Tucker
Go to Source

After I have completed my analysis for a branching scenario, I spend time planning before I start actually writing the content.

My planning includes three components:

A scenario concept and summary
An outline
A list of mistakes

Scenario Concept and Summary

I create a summary of the scenario and the narrative. My design document includes this summary, so the client and SME approve it before I start writing. I want everyone on the same page for the basic concept of the scenario.

The summary includes the name and role of the main character, plus any other critical characters. I describe the problem the main character faces and how it will be addressed. This is just a few sentences to give the overall feel of the scenario without getting into much detail.

Here’s an example:

Sophie is an instructional design consultant. She’s tired of spending hours and hours writing proposals for clients who don’t end up hiring her or really aren’t a good fit in the first place. She has been contacted by Robert about a potential project. Sophie will attempt to follow a new process for screening clients to see if this is actually a good fit for her skills and to establish a professional relationship with Robert.

Create an Outline

I start with a rough outline or checklist of steps in the ideal process. Let’s say I’m creating a course on screening potential consulting clients, and I have a process with 4 steps. Each of these steps will be a decision point in the scenario.

Send client initial screening questions.
Review client responses for fit and feasibility.
Learn more about client needs during preliminary phone call.
Propose a short road mapping engagement.

It’s possible that when I write the scenario that I’ll realize I need to add another choice in this process, but this gives me the basic flow.

Identify Mistakes

Based on my analysis (including conversations with SMEs, learners, and/or other stakeholders), I also create a list of mistakes or errors people could make. This list tends to be fairly fluid for me; I try to brainstorm more mistakes and problems that I’ll actually use in the scenario. Some mistakes might be critical for the learning objectives, while others might be possible options.

Continuing the previous example, here is a list of potential mistakes I might use.

Agreeing to a client request for a project before screening for fit (critical–must include)
Sending client screening questions without a budget question
Ignoring red flags in client responses (not enough money, unrealistic timeline, etc.)
Rejecting a client because they don’t know what they want (that’s what road mapping is for)
Jumping right into asking about project logistics without understanding goal/problem
Writing a big proposal for free

I try to include both major, critical errors and some errors that are partially correct or in the gray area. Sometimes this list of mistakes also includes notes on consequences, although usually I have that in my notes from the SME.

I find it helpful to include both the outline and list of mistakes in the design document if possible. I haven’t always done it that way, but it seems to help set clear expectations with SMEs and clients.

Start Writing

Once I have all of those pieces together and approved, I start writing.