Wednesday, February 27, 2013

Draft a Branching Scenario in 6 Steps

By Shelley A. Gable

How often have you encountered eLearning packed with information, yet lacks an outlet to apply that new knowledge in a meaningful way?

Designing eLearning around problems that learners encounter on the job can help avoid this pitfall. Scenario-based training prompts learners to solve problems they will encounter on the job, helping to ensure we prepare them to perform their jobs successfully.

Branching scenarios can simulate many workplace problems especially well. In a branching scenario, an eLearning slide might only provide the start of a situation. Perhaps the first segment of a conversation or an initial glimpse into a problem. Based on the information available, learners choose their next step from a few options provided. And instead of giving them feedback like “correct” or “incorrect,” their choice takes them to a slide that describes the next segment of the scenario...a segment that’s a direct consequence of the option they chose. The scenario continues like this, over a series of a few slides, until learners reach an outcome.

Here’s how I approach drafting a branching scenario…

--1-- Identify a scenario.

This step likely seems obvious; however, depending on the scope of your training, it warrants some thought. Of the array of situations your training needs to prepare learners for, do a few seem especially worthy of developing into branching scenarios? Perhaps it makes sense to focus on situations that learners will encounter most frequently. Or, situations that tend to challenge newbies the most.

Additionally, I’m most likely to use branching scenarios for situations that require a series of judgment-based decisions and where the consequences of a decision are immediately evident.

--2-- Identify outcomes.

On the job, what range of outcomes is typical for the situation?

For instance, a sales scenario might have three typical outcomes: the customer accepts the sale (successful outcome), the customer decides to “think about it” (partially successful), or the customer declines the offer (unsuccessful).

Alternatively, depending on the business result you are targeting, a sales scenario might have typical outcomes more like this: the customer buys the deluxe package (successful outcome), the customer buys the basic package (partially successful), or the customer declines the offer (unsuccessful).

--3-- Flowchart the steps and decisions that lead to the most successful outcome, based on observed behavior of exemplary performers.

To identify the decisions that lead to the successful outcome, I like to ask clients to walk me through the steps and decisions they’ve observed in their best employees. This usually results in a linear set of steps from the scenario’s starting point to the successful outcome.

--4-- Flowchart the decision points and decisions that most directly lead to an unsuccessful outcome, based on common mistakes of novices.

Next, I ask clients to walk me through the steps and less optimal decisions they’ve observed in less experienced employees. This usually results in a separate set of steps from the scenario’s starting point to the unsuccessful outcome.

An important tip here is to specifically prompt clients to recall the less optimal decisions they’ve actually observed. In other words, I’m not asking them to think of possible incorrect decisions someone might make…I’m asking for the incorrect decisions people actually have made. This helps keep the scenarios realistic. And hopefully, learners who slip into common mistakes during training will remember the consequences presented in the scenario, helping them to remember how to avoid those mistakes on the job.

--5-- Review the flowchart and identify realistic opportunities where a learner may be able to recover from a bad decision to get back on the “successful” path (or move from an “unsuccessful” path to the “partially successful” path).

In most situations in life, an initial bad decision doesn’t doom you to be unsuccessful in an endeavor. In real life, when the consequence of a decision shows you that you’ve made the wrong choice, you may be able to correct the situation with better decisions and still succeed. This is what I try to tackle next when outlining a branching scenario – where these crossovers can occur between the various paths.

--6-- If a middle outcome exists (e.g., “partially successful” or something similar), flowchart the path to that.

Often, I find that creating the “partially successful” path doesn’t require adding decision points to a scenario. Sometimes, it simply results from a different path among the steps charted previously.

What’s your approach?

If you’ve designed branching scenarios for eLearning, how did you figure out the branching paths?

Thursday, February 7, 2013

Simple Anatomy of SCORM-based E-Learning

By Jonathan Shoaf

I remember the first time I heard the term SCORM. I was a software developer working on a quizzing product that needed to export data to a variety of e-learning systems. It was suggested we should support SCORM. So I researched but quickly got lost in the minutia of details and acronyms -- AICC, CMI, SCO, XML, ECMAScript, manifest, packaging, and API. On top of that, I found out about the ADL initiative and the Department of Defense involvement in the specification. Woah! Wait a minute. What are we talking about here? I just want to get my content to my customer in a form that they can use it!

It turns out I had to know most of that stuff for my job. But most people producing e-learning content can rest assured that they don't need to know these details. You just need to know that e-learning content sometimes needs to be exported to SCORM so that it can be used in an LMS. Here's everything you need to know about the anatomy of a SCORM module. The version of SCORM doesn't matter for this simple explanation.

A SCORM module consists of three basic pieces:

1.  Learning Content
2.  SCORM Run-Time
3.  SCORM Package

And here's the best news...with today's e-learning development tools, you only need to be concerned about one of these pieces!

Learning Content

If you are an instructional designer or developer of e-learning content, chances are, you'll only need to worry about the Learning Content piece. This is what the learner sees. It is based on an instructional design or storyboard. This piece contains all the images, audio, video, and text that learners will need to consume. Many times the learning content contains a quiz as well. Ideally, this is where you will spend all of your time developing the course.

SCORM Run-Time

The next piece is the SCORM Run-Time code. E-Learning development tools like Adobe Captivate, Lectora, or Articulate do all of this for you. So don't sweat it.

But for those curious, this is the "language" the e-learning module uses to communicate with the LMS. The run-time code is used to send messages to the LMS like "the course was started", "the learner scored 80% on the quiz", and "the learner has mastered this material". And vice-versa, the LMS can use the run-time language to tell the e-learning module information like the learner's name or a bookmark that tells the e-learning module where the learner stopped previously.

SCORM Package

The last piece of the simple anatomy is the SCORM Package. As before, if you use an e-learning development tool, this is often taken care of for you. There are a couple of things worth mentioning about the package. The package is simply a compressed (aka zipped) folder of files. There is a magical file included called the imsmanifest.xml file that instructs the LMS on how to use the files in the package. There are rare times where you may need to tinker with this package.  For example, to add a referenced file like a PDF or video.

How does your understanding of the SCORM anatomy differ from this? What about SCORM has been a challenge for you?