7 ways to make dialog sound natural

“Upon examining the data,” your scenario character says, “I have become increasingly uncomfortable with the proposal, specifically its requirement that we induce wombats to fly.”

Who talks like that? No one in the real world. However, you might find your scenario characters talking like that in your first drafts. Here’s how to fix it.

Droid turns into a human

1. Make sure you’ve actually written dialog. Show, don’t tell.

Not this: Barbara says she is concerned about the delay in processing TPS reports.

Instead: “It takes too long to process TPS reports,” Barbara says.

Let the readers draw conclusions like they do in the real world.

Not: Peter doesn’t want to talk about what happened at his previous job.

Instead:

“Peter, what happened at your last job?” Louise asks.

“Who wants coffee?” Peter says. “I’m going for a refill.”

2. Start late. You might be tempted to write the small talk that starts a conversation, so it sounds realistic. Instead, fast-forward to the meat for more impact. Imagine how a movie would show it.

Not:

Jason goes to Emma’s office.

“Good morning, Jason,” Emma says. “Thank you for coming in. I know it’s a long trip for you.”

“I’m happy to help,” Jason says. “What can I do for you?”

“Well, the auditors called me yesterday, and…”

Instead:

Jason goes to Emma’s office.

“I need to cancel our account,” Emma says. “The auditors found problems.”

3. Use contractions: “She is our best chainsaw juggler” becomes “She’s our best…” Not allowed to use contractions? Fight back with the tips in this post.

4. Don’t stuff the dialog with story. If they wouldn’t say it in real life, don’t make them say it in your scenario.

Not: “Diane, I’d like to hear your opinion about how to handle cultural differences on the new Zeko project, since you have been with the firm for eight years and have worked on numerous projects with companies in Zekostan.”

Instead: Bob calls Diane, who has eight years’ experience on Zeko projects. “How should we handle cultural differences on the new project?” he asks.

5. Choose informal words. “Wish” becomes “want,” “assist” becomes “help.” Find simple alternatives in The A to Z of Alternative Words (PDF) from the Plain English Campaign.

6. Break sentences into fragments of different types. It varies the rhythm, makes people sound more human, and gives them character.

Not: “If you want to play the banjo, you will need to go outside.”

Instead: “You want to play the banjo? Go outside.”

7. Use “said” and “asked.” Avoid having people “growl,” “smile,” “snarl,” or “laugh” their lines, which gets distracting and over-dramatic.

Often, you don’t even need “said.”

Example:

“How much are you willing to invest?” Jorge asks.

“Ninety bajillion dollars.” Andrea opens her briefcase. “I have it right here.”

Scenario design workshop: A few seats are still available

Want to improve your scenario design skills? There are some seats available in the scenario design workshop that starts on November 8. You’ll apply what you’re learning to a real-life project from your job. We’ll meet in the afternoon in Europe and mornings in the Americas.

Scenario-based training headquarters

I’ve gathered a lot of ideas about scenario design in one spot. You’ll find example scenarios, design tips, research summaries, and more.

I hope to see you at Learning Pool Live

I’m joining Learning Pool Live in London this Thursday, October 20, to give a keynote and short workshop. I hope to see you there!

Scenario example: Chainsaw training!

What’s the best way to teach people to cut down a tree? Probably the best way isn’t the approach recommended in this scenario. However, the scenario isn’t supposed to be realistic. I wrote it to make a point.

Try the scenario below. Do you agree with my point?

(The scenario is embedded in the blog post. If you’re reading this in email or a feed reader and don’t see a clickable interaction, go to the blog post to play it.)


Photo by Stewart Black cc. Scenario was developed in Twine.

Spoiler alert! Play the scenario before you read on.

If you’re familiar with action mapping, you probably saw what I was trying to do. The best ending to the scenario required you to do some (extremely quick) analysis of why it’s hard to cut down a tree without squashing your house or car.

The analysis asks, “What decisions do people have to make? Why are those decisions tricky? How can we help people practice making the decisions in a safe place?”

Then your design focused on helping people practice the tricky things that would directly support the goal of reduced property damage. You didn’t push information into their heads and then see if they could recognize it on a test.

Of course, it’s important for customers to know the obvious stuff, like how to hold the saw when you’re cutting into a tree. We’d certainly cover that in the videos. Unfortunately, it’s tempting to focus only on that obvious stuff. The result would be “How to Use a Chainsaw” and not what we really need, which is “How to Use a Chainsaw without Destroying Your House.”

I learned to cut down trees the way most people probably should: A more experienced person went into my woods with me. He helped me analyze each tree, set up the winch and rope, plan the cut, and adjust when things began to veer horribly out of control. But if that weren’t possible, I’d look for training that let me practice the decisions in a safe place.

What do you think? Let us know in the comments.

More scenario examples

I’ve set up a scenario design headquarters on my site. In that section, you’ll find more scenario examples, along with a research summary, a link to all scenario posts, and some tips on using Twine, the free editor I used to create the scenario in this post.

Related posts

For more on letting people learn from their mistakes, you might check out these posts:

Scenario mistakes to avoid #2: “Eat! Eat! You need to eat!”

“You need to eat more!” she says, heaping your plate until it rivals Mount Everest. “Eat! Eat!”

We all know the stereotype. Unfortunately, we can find ourselves turning into that stereotype when we feed information to people.

“You have to know this!” we say, filling the screen to bursting. “And this! And this!”

A huge platter of paellaIn scenario-design land, we can find ourselves doing this:

“First we’ll feed them everything they need to know, and then we’ll feed them some more as we show them how an expert does it, and finally we’ll let them waddle, overstuffed and dazed, through a scenario.”

Example, only slightly exaggerated

In the first post in this series, widget technicians had to diagnose squealing widgets. In the “Eat! Eat!” design approach, we’d “teach” them this way:

  • Tell the “widget story” — how widgets were invented and our company’s proud role in widgets’ ascendence to importance.
  • Explain how prompt customer service has helped us stand out in the widget field.
  • Explain that despite the stellar quality of our engineering, any widget could eventually develop a squeal.
  • Show a video of a squealing widget.
  • Show all the moving parts in a typical widget and what they do.
  • Explain that most squealing widgets have a wobbling synderhobble, and the squealing will stop when the synderhobble is screwed back into place.
  • Open a squealing widget, point to the wobbling synderhobble, and screw it back into place.
  • Say, “Now you do it.”
  • Watch as the “learners” obediently imitate what they saw five seconds ago by opening their widgets and screwing the synderhobble back into place.
  • Display a bulleted list of the other, less common causes of squealing widgets.
  • Move onto the next topic: Wobbling Widgets.

What’s wrong with this?

We make people eat when they’re full

We assume that everyone in the audience is equally and profoundly ignorant of the topic. But our audience consists of adults with decades of experience tinkering with gadgets — that’s why they signed up to be widget technicians. Some of them have already worked with widgets or with widget-like technology. Yet we stuff them with information they might already know, slowly suffocating what motivation they might have had.

We make people rely on short-term memory

Worse, our “scenario” came immediately after we showed them what to do. We used a version of “tell, show, do” that short-circuits independent thought.

Mike, a new widget technician, watched us screw the synderhobble into place, and 20 seconds later he had half-heartedly imitated what he saw. He was actually thinking about the vintage motorcycle he’s been taking apart in his garage.

Did Mike learn what we wanted him to learn? Was the behavior we wanted “Screw a synderhobble into place?” or was it “Correctly diagnose the cause of a squealing widget?”

Screwing the synderhobble into place is easy. Correctly diagnosing the cause of a squealing widget while an irritated customer waits impatiently is much harder. But instead of having people practice the hard stuff, we fed them the answer immediately and had them practice the easy task.

An alternative

The first post in this series describes an activity that would help Mike practice the harder stuff: He’s on a fictional phone call with a customer whose widget is squealing.

We haven’t shown Mike the history of widgets, and we haven’t told him that the most common cause of squealing is the synderhobble. We’ve just plunged him into the fictional phone call and provided optional help.

In elearning, that optional help could be links, such as:

  • A downloadable job aid: “How to Diagnose a Squealing Widget”
  • A short presentation, “The Moving Parts in a Widget,” that’s always available online

In face-to-face training, the optional help could be a printed version of the job aid and a link to the presentation on everyone’s smart phone. Since technicians often go into the field, this information needs to be portable.

When he’s in the scenario, Mike can look at the help or not, depending on his pre-existing knowledge and his willingness to try and possibly fail. The feedback shows the consequence of his choice, as described in the previous post.

Mike has to think on several levels: What do I know about this already? Is it accurate? What could be causing the squeal? What should I try first? And when he looks for information, it’s because he wants it. The information is a tempting buffet, not a mass forced-feeding.

Mike thinks hard and practices the hard stuff — diagnosing a squealing widget. He’s not daydreaming about the vintage motorcycle, and he’s probably more likely to transfer what he learned to his job. We’ve also made transfer easier by giving him a job aid and some information that’s always available on his phone.

I rant about this a lot, in posts like the following:

For the research supporting this approach, see Where’s the research support for scenarios? in my knowledgebase, the research cited in the post Throw them in the deep end, and books that summarize learning research, including Make It Stick: The Science of Successful Learning and Design for How People Learn.

Action mapping workflow available as an interactive graphic

Action mapping workflowWith help from readers’ feedback on the draft version, I’ve improved the action mapping workflow and summarized it in an interactive graphic.

You can download the graphic and a Word version of the workflow from that page.

Photo credit: Platter of paella by Joanbrebo via Compfight cc

Scenario mistakes to avoid #1: Eager-beaver feedback

What’s the most common mistake scenario designers make? They provide feedback like this:

Incorrect. You should always have the customer wiggle the synderhobble first. Most noise issues are caused by a loose synderhobble.

Or this:

This wasn’t the best choice. If Lars really has witnessed an ethics violation, you need to encourage him to describe it in detail.

Or this:

Great job. You’ve helped the patient manage their anxiety and as a result they’ll be able to describe their symptoms more accurately.

“But that’s good feedback! It’s helpful!”

Yes, that feedback is helpful. It immediately tells me what I’ve done right or wrong and shoves me firmly down the path of good behavior.

But when does that feedback appear? In the middle of a story. Like this:

You’re on a call with a customer whose widget is squealing. The customer is being driven insane by the squeal, but he has to run the widget at top speed to deliver a product that’s due this afternoon. You tell the customer to oil the widget’s cooling fan.

Eager beaver just wants to helpSuddenly a beaver pops its furry head over your cubicle wall. “You shouldn’t have done that!” it squeaks. “You should always have the customer wiggle the synderhobble first!”

Helpful? Sort of. Annoying? Seriously.

The beaver is just eager to help you learn. But has it helped?

For example, how much thinking did you do after you mistakenly told the customer to oil the fan? Zero. You didn’t have a chance to think, because the beaver interrupted and told you what to think.

How much can you learn when a beaver does your thinking for you?

We can be helpful without interrupting

In the real world, we learn from the consequences of our choices. We tell the customer to oil his fan, but the squealing continues, and we realize on our own that the synderhobble might be the culprit. We’ve used some brain cells and effort, and as a result the lesson is memorable.

But in training land, this kind of learning is often considered messy and inefficient. Also, our clients sometimes think that people can’t be trusted to draw the right conclusions.

The real world lets us learn from experience. The training world tells us what to do. Here’s how we can have the best of both worlds:

  • Pose a realistic challenge.
  • Let the learner make a decision.
  • Show the real-world consequence of the decision (the widget continues to squeal).
  • Optionally offer beaver-style feedback.

In elearning, we can offer optional feedback through a link, like this:

Mr. Jackson puts down the phone and oils the widget fan. You can hear the squealing continue in the background. “That didn’t do a thing,” Mr. Jackson says when he gets back to the phone. “And now the shop stinks of oil.”

Why did this happen?

First, we show the real-world consequence. Then, people who want help from the beaver can click the link. Others can continue to try to diagnose the problem on their own.

If your software allows it, you could keep an eye on people’s choices. If someone repeatedly fails to learn from experience, you could unleash the beaver on them even though they didn’t ask for help.

In live sessions, you could pass out squealing widgets and have people try to fix them on their own. “Let me know if you need help,” you’d say. Then you’d stroll through the room, and if you see someone getting too frustrated, you could step in to nudge them toward the synderhobble or just tell them what to do.

For more on showing vs. telling feedback, see this earlier post.

Let a job aid help

Often, we use beaver-style “telling” feedback when a job aid would be better.

For example, the widget exercise could include a link to a diagnostic checklist. The link could appear on the same screen as the question. So when the caller describes the problem and we need to decide what to do first, we can either:

  • Make a decision based on our pre-existing knowledge, or
  • Look at the cheat sheet called “How to Fix a Squealing Widget” and then make a decision

We then see the real-world consequence of our decision. We can click “Why did this happen?” for an explanation that confirms or corrects our knowledge. Ideally, the explanation includes a snippet of the job aid that shows the relevant step. This tells the people who skipped the job aid, “Hey, you would have gotten this right if you’d looked at this thing.”

“But they must all be exposed to all of the information!”

Some clients insist that everyone should be “exposed” to the right way to do it, regardless of whether they made the right choice in the scenario. “They might just guess right,” the client says. “You have to tell everyone the right way.”

Here’s an easy fix: Show the real-world consequence as above, and then provide the “telling” feedback. It’s no longer optional. Everyone gets “exposed” to the information, but the exposure happens as feedback to their choices. Instead of staring at a presentation, people have to think, and they see the information when it most matters to them.

Elearning

The elearning version of this approach might look like this:

Mr. Jackson puts down the phone and oils the widget fan. You can hear the squealing continue in the background. “That didn’t do a thing,” Mr. Jackson says when he gets back to the phone. “And now the shop stinks of oil.”

Why this happened: Most noise issues are caused by a loose synderhobble, not the fan. You should have the customer wiggle the synderhobble first to see if it’s loose.

[GRAPHIC] The relevant part of “How to Fix a Squealing Widget” with a big arrow pointing to step 1, “Wiggle the synderhobble.”

You’d create scenarios for other squealing widgets, including one that represents the widgets that squeal for reasons unrelated to their synderhobbles. Widget support people go through several scenarios representing different situations until they’re using the cheat sheet with confidence, just like they should use it on the job. Along the way, they’re “exposed” repeatedly to the correct diagnostic procedures, with no need for a presentation.

Live training

Here’s one way to do it in a live session: Give everyone a squealing widget and the cheat sheet called “How to Fix a Squealing Widget.”

“You’ve got 10 minutes to fix your widget,” you say.

After 10 minutes, stop everyone and see how it went. Some widgets are still squealing. A few are squealing because their repair people didn’t use the cheat sheet, and a few are widgets that represent the minority that don’t have a loose synderhobble.

In the group discussion, confirm what most people learned: Following the cheat sheet will silence most widgets in one step. The remainder need more diagnostics. Using one of the still-squealing widgets, go through the sheet as a group, applying each step until the squealing stops.

What about branching scenarios?

If you’ve got a branching scenario, you might try this:

  • Plot the scenario with three types of endings in mind: one best ending, a few mediocre ones, and a few poor ones.
  • Build the plot, letting paths occasionally cross so players can realize they’re heading for a poor ending and get on a better path.
  • Make any job aid or other reference available at all times.
  • Have each decision result in a realistic consequence with no “telling” feedback to interrupt the story.
  • If you have any especially tricky decisions or startling consequences, consider offering an optional hint or explanation at that point, in a link.
  • At each ending, first show the end of the story. Then (optionally or not) describe how the player got to that point, point out mistakes they made, and offer hints that will help them do better when they play again.

There are lots of other approaches, of course, depending on how much experience people already have, how open they are to this type of activity, and what types of skills you want them to practice.

How does this work with “tell, show, do?”

If your client wants you to expose people to information, they probably expect you to use the “tell, show, do” formula: First you tell everyone what they might need to know, then you show them how you do it, and then finally you let them do it themselves. Kind of like this classic video on how to diagnose sigmoid rumbling in a turbo encabulator.

In a future post in this series, we’ll look at whether “tell, show, do” is always the best approach and consider some alternatives.

Scenario design courses scheduled for June and November

My hands-on scenario design course has two more sessions scheduled for this year: June (includes Australia-friendly times!) and November.

Let me tell you everything you need to know! Or not.

Plane to ZekostanCongratulations! You’ve just been assigned to work with a design team in Zekostan. You’re leaving in a week.

Your Zeko colleagues know that you’re coming from a very different culture and might have trouble fitting in. Luckily, they’ve developed some materials that help people from your culture prepare for working in theirs.

You can choose one of the following “Prepare for Zekostan” packages. Which will you choose?

PACKAGE 1. A 56-slide online course in which a nice Zeko woman describes some cultural differences, bulleted tips appear on the screen, and you complete a quiz to confirm your understanding.

PACKAGE 2. A one-page PDF of tips, plus eight online branching scenarios in which you practice responding appropriately during typical interactions in the Zeko workplace.

If you’re like most people, you want package 2, the PDF and scenarios. You can put the PDF of tips on your smartphone to review as often as you like, and the scenarios will help you practice applying the tips in a safe but realistic-enough setting. You’ll be able to make mistakes in private and learn from them, instead of making them in front of your new colleagues.

Separate the info from the activity: It’s the Zeko way

Your preference for package 2 will also reassure your Zeko colleagues that you share their views about design. They’ve moved away from presenting information in an “engaging” way and then testing recall.

Instead, they put the information in a simple format that people can easily refer to whenever they want. They focus their design time on creating challenging, realistic activities that help people practice the decisions they need to make on the job. As people try the activities, they can refer to the information.

Example: Greet your colleague

How do the packages compare? Let’s look at how each package “teaches” a greeting.

PACKAGE 1: A nice Zeko lady appears as a talking head on the screen. “People new to the Zeko workplace are often surprised by our way of greeting our colleagues,” she says in a pleasant voice. “Greetings are of course very important in every culture. In Zekostan, we use greetings to show our connection to others by highlighting what we have in common. So when we greet each other at work, we identify a role that we have and that the other person also has, and we salute them from that role. For example, if you are an engineer and you are greeting another engineer, you would say, ‘The engineer in me salutes the engineer in you.'”

The following appears as a bullet point on the screen: “Salute new colleagues using the job role that you have in common.”

Eventually, you get to a quiz. One of the questions is, “How should you greet a new colleague?” and one of the options is, “Salute them using the job role that you have in common.”

PACKAGE 2: The PDF has a section that looks like this:

GREETINGS
New colleagues
Goal: Highlight what you have in common
Technique:
     1. Identify a job role or responsibility that both of you have.
     2. Say, “The [job role] in me salutes the [same job role] in you.”
Example: “The engineer in me salutes the engineer in you.”

The practice activities in package 2 often begin with you meeting new colleagues. In one of the scenarios, you’re a project manager, and your new boss introduces you to a team mate who’s also a project manager. You have to decide what to say. You choose, “The project manager in me salutes the project manager in you,” and your new colleague welcomes you warmly.

In another scenario, you’re a quality assurance manager. Your boss introduces you to a colleague who’s an editor. What should you say?

  1. The quality assurance manager in me salutes the editor in you.
  2. The quality advocate in me salutes the quality advocate in you.
  3. The detail freak in me salutes the detail freak in you.
  4. The team member in me salutes the team member in you.

You take the safe route and choose 4. Your new colleague gives you a decidedly cool welcome. You click “Why did this happen?” and see the following:

You’ve suggested that the only thing you have in common is that you’re assigned to the same team. This can be interpreted a veiled insult. When you don’t have the same title as your colleague, choose the most flattering responsibility or trait that you have in common. In this case, “quality advocate” would be best.

Look at the information or not: It’s up to you

In package 2, you’re not required to read the PDF before you start the activities. For example, you could ignore the PDF, jump right into the activities, offend people, click the optional feedback to find out what you did wrong, go back and make better decisions, and finally look at the PDF, treating it as a summary of what you learned through experience.

“The adult in me salutes the adult in you.”

Your new Zeko colleagues think it’s disrespectful to require grownups to all be exposed to the same information presentation, regardless of their prior knowledge. They think we treat adults like children when we tell them what to think and test them 5 minutes later to see if they can still think it.

Instead, your new colleagues base their design decisions on the following facts:

  • The people using the material are adults who have been learning from experience for decades.
  • They might already know some of what we’re supposed to “teach” them.
  • Some of their most memorable lessons started out as mistakes.
  • Adults’ self-esteem will not be squashed by a mistake in a training scenario.
  • When people struggle a bit, they can learn more deeply.
  • If people don’t want to struggle, they can always look at the supporting information or optional help.
  • Well-designed scenarios help people prove that they know something while they also practice doing it.
  • We’re in business, not education. We want people to do stuff, not just know stuff.

Obviously, the examples were simplified, and both packages provide just a band-aid approach to cross-cultural skills. A more effective preparation would dig below the surface pleasantries to help newcomers see from the Zeko perspective. In that case, I’d argue that scenarios would become even more important, because they’d help people notice subtle cues and shift perspectives in complex social interactions.

Explore some more

Scenario design course starts on Feb. 10
For a lot more on helping people learn through scenarios, consider signing up for my scenario design course, which starts on Feb. 10. There’s still room in the European session, which meets in the morning in the Americas.

Learning Technologies in London
If you like the idea of taking information presentation out of activities, you might like my London Learning Technologies session, “Throw them in at the deep end.” You’ll overhaul some conventional activities to make them more immersive and challenging. I’ll also be talking with practitioners at Booth H21 as part of the LT eXchange, and I’ll be part of the BarCamp with Aaron Silvers, Shannon Tipton, and David Kelly. All of this happens on Feb. 3. I hope to see you there!

Photo by Colby Stopa

3 quick tips for strong scenarios

Tips and tricksIt can be hard to write subtle scenario questions. Here are some techniques that can help.

1. Put dialog in quotation marks.

This trick helps ban the bureaucratic from your writing. Instead of paraphrasing what people say, stick it in quotation marks and it will magically rewrite itself. Here’s an example.

Before: Nuria has been wrangling widgets for three weeks and is frustrated. It is difficult for her to determine the correct wrangling angle.

During: “I am frustrated,” Nuria says. “I have been wrangling widgets for three weeks and it is difficult for me to determine the correct wrangling angle.”

After: “This is driving me nuts,” Nuria says. “I’ve been wrangling widgets for three weeks and I still can’t get the angle right.”

The minute you put your dry prose in quotes, you realize how very dry it is. Then it becomes easy to make it sound more natural. This trick also moves you from boring “telling” to more vivid “showing.”

2. Ask, “Why aren’t they doing it?”

In action mapping, you set a business goal and list what people need to do on the job to reach that goal. And then for each important task, you ask, “Why aren’t they doing it now?”

Unfortunately, it’s common to skip that question and go straight from “Here’s what they need to do” to “Here’s an activity that will help them practice doing it.” This often results in a scenario question that’s generic and too easy.

Instead, take a little time to identify the main barriers to performance: “Why aren’t people wrangling widgets well?” You might talk to a few people who do the job and use this flowchart to guide the discussion. You’ll find out if training will really help and, crucially, you’ll learn the challenges that people face. You’ll have the understanding you need to design subtle scenarios that target what’s really causing the problem.

3. Branching? Start with the end in mind.

Before you write any part of a branching scenario, think of the endings that will make the points you want to make. You might aim for one best ending, a few “fair” endings, and some “poor” endings. Then write a high-level plot that provides several intersecting routes to those endings. You might first write the “best” path and then add the less-great paths. Test your plot on subject matter experts and some future learners to make sure it’s realistic and not too easy. Only then is it safe to start fleshing it out with dialog and details.

What techniques have you discovered that help you write strong scenarios? Let us know in the comments.

Scenario design course: New sessions available

Two new sessions of my four-week, hands-on scenario design course have been scheduled, starting on Oct. 28 and Feb. 10. Learn more about the class and sign up for future announcements here. The action mapping book used in the course will be published this year; I’ll be sure to announce it in the blog when it’s available.

Tips & tricks image © Aquir and iStock

Is it ever okay to be a control freak?

Here’s a short scenario that uses a particular type of structure. What do you think about it?


Photo by naosuke ii cc

Spoiler alert! Play the scenario above before you read on.

What type of branching is this?

Here’s how the scenario looks as a flowchart in Twine. No matter what we decide at decision point A, we all end up at decision point B. It’s like we have no free will!

Flowchart view in Twine

If you’re feeling cranky, you could call this the “control freak” approach to scenario design: No one may advance without first making the correct choice, and then all people must advance as one obedient mass to the same scene.

If you’re feeling more generous, you might call it a “teaching” scenario.

It might be helpful for raw beginners

The extreme control exercised by the designer could actually be useful in the following conditions:

  • The people playing the scenario are beginners in the subject matter AND
  • We haven’t preceded the scenario with a bunch of information telling people everything they might need to know.

In other words, people new to the topic learn about it through a guided experience first, not through an information presentation followed by a “practice” activity.

What could happen if we put the information first?

Let’s run an imaginary experiment. Let’s not start with the scenario. Instead, we’ll give our learners lots of do’s and don’ts about classroom management. We’ll follow that with a video of an expert talking about how honorifics like “Ms” supposedly squash students’ self-esteem, and then, finally, we’ll send them into the scenario to “practice what they’ve learned.”

Now that our learners are no longer absolute beginners, the relentless feedback and forced re-tries are likely to feel annoying and even patronizing.

“But we have to give them information!”

I agree, we do — after the scenario.

We can give people a chance to learn through the (very!) structured experience first, and then help them synthesize what they learned by giving them some reinforcing information. We can trot out the video expert after the scenario, for example, to reinforce the scenario’s message about honorifics.

Putting the scenario first does several things. It:

  • Helps people gauge their pre-existing knowledge, if any
  • Shows the learner through their mistakes that they need to learn this stuff, making them pay more attention to the information that follows
  • Gives them a concrete, memorable story with which to organize the more abstract information that follows, possibly helping with retention and transfer
  • Gives them beginner-level information in an engaging way, possibly motivating them to continue

For more on this activity-first approach, see my post “Throw them in the deep end!”

However, I still recommend true branching for most audiences

I focus on instructional design for adults in the working world. Most people in this world already have at least some previous experience or knowledge of the common topics covered in corporate training (how to treat people nicely, how to sell stuff, how to avoid breaking laws…).

As a result, I suspect that in most situations, a truly branching scenario would be more satisfying for the players. By letting people make mistakes, see the consequences of those mistakes, and draw conclusions, we’re saying, “I acknowledge that you’re an adult with a brain and life experience, and I trust you to be able to learn from more experience.”

Our careful handling of the branches, feedback at the ends of the paths, and optional help or resources along the way will help make sure that players are drawing the right conclusions without getting too frustrated. It’s all about choosing the appropriate amount of scaffolding for our audience.

For an example of a “real” branching scenario for people with some prior knowledge, try playing AutoLoon Ethics Training, which helps you practice your action mapping and consulting skills.

What do you think? And how do you manage stakeholders who want to be control freaks when it’s not appropriate? Let us know in the comments.

This post was updated 29 May 2016.

Makeover: How to write challenging scenario questions

We’ve all seen scenario questions that are too boring or easy. In fact, here’s one:

A member of your team is often an hour late to work on Monday mornings. What should you do?

A. Ask the team member why they’re late.
B. Refer the team member to the Employee Assistance Program for counseling.
C. Dock the team member’s pay for the missed hour of work.

How could we improve this question? Let’s look at some ideas. (We’ll look at a lot more ideas for strong scenarios in the scenario design workshops I’m giving soon in Los Angeles, Chicago, and Sydney.)

1. Focus on a specific, real performance problem

Our scenario question is weak because it isn’t based on an analysis of what’s really going wrong. Instead, it’s based on assumptions about what people are probably doing wrong.

So our first step in the makeover is to look more closely at the actual performance problem.

Girl walking on railroad trackLet’s say that our business goal is this: “Employee retention will improve 10% by 2016 as all managers use the Friendly Face at Work management model.”

We set this goal because employee turnover is high, and during exit interviews, people said managers were too harsh. We then paid a consultant $70,000 to tell us to use his patented Friendly Face at Work model.

In action mapping, every activity we write supports a specific, real-world behavior that people should perform but are messing up somehow.

In this case, the behaviors we want to see are the behaviors in the consultant’s model. The one we’re focusing on now is, “When a team member consistently fails to reach a standard, encourage them to share why they’re struggling.”

Our managers aren’t doing this. Why not?

2. Find out WHY people are messing up

In our analysis, we discover that managers already know they should ask a struggling employee what’s up. The real problem is that they don’t ask because they worry about sounding intrusive.

They’d be more comfortable if we helped them phrase the question appropriately. That’s the behavior they should be practicing: asking the question.

3. Find out in what CONTEXT people are messing up

The first draft of our question is boring because it’s so generic. Nothing in the real world is that simple. So with our subject matter expert (SME), we’ll add some realistic complexity. Here’s one possible rewrite,

Jake has worked on your team for two years. In the last two months, he’s arrived an hour late on most Mondays. He doesn’t seem as cheerful as he used to be, and a couple of times you’ve noticed that his eyes appear bloodshot. You’re pretty sure he’s married and you remember signing a congratulations card for his new baby about seven months ago, but you haven’t heard anything since then.

You ask Jake to come into your office after lunch. When he arrives, his eyes look bloodshot again, and he fidgets with his hands.

How do you start the conversation?

A. “You’ve been a great member of the team for two years, so I’m surprised that you’ve started coming in late. Is something going on?”

B. “I’ve noticed that you’re coming in late on Mondays, and I’d like to help you get back on track. What can we do to help you get here on time?”

C. “I want you to know that no matter what the situation might be, I’m here to help. Could you help me understand why you’ve been coming in late?”

This still isn’t the best question in the world, but it’s at least more subtle and realistic than the first draft. And, importantly, it focuses on what managers really need to practice: how to phrase the difficult question.

Tweaks for context

In addition to changing the focus of the challenge, we made the following tweaks:

  • We gave people names, which in a way also gives them a face as readers pull up a “Jake” from the database of people in their brain. My Jake probably doesn’t look like yours, but he has a face.
  • We provided cues that may or may not be relevant — the bloodshot eyes, the changed mood, the baby that we haven’t heard about lately. No management challenge takes place in a vacuum.
  • We put people’s words in quotation marks, adding voices to make it more real (and, in this case, to model specifically how the question should be asked).

Finally, another cue that we wrote a more challenging question is that it’s not obvious (to me, at least) which answer is correct. We have to understand the consultant’s Friendly Faces at Work model to know how we’re supposed to phrase the question.

If we can write scenario questions without the help of a SME, we’re probably writing questions that are too easy. The SME will help us write a subtle question and help us make clear through feedback which option is correct.

Scenarios require a lot of SME help, so you might want to prepare a steady supply of donuts or chocolate for your expert. In the scenario design workshop, we’ll also look at ways to quickly and efficiently get the expertise out of your SME’s brain and into a scenario.

What do you think? What has helped you write more challenging scenarios? Let us know in the comments.

All photos in this post (c) iStock


Design challenging scenarios that your learners love with my workshops this September and October in Los Angeles, Chicago, and Sydney. The first workshop is on Sept. 19 and spaces are limited, so please check out the details and make your plans!

Jettison the genies and let learners think

Elearning has genies, superheroes, and wizards. Live training has the all-knowing instructor. I say all of them should stop being so darned helpful. Here’s why.

Let’s say that you’ve dusted off your bike and have been riding it to work, but it’s no longer shifting smoothly and the chain keeps falling off. You tightened a nut that you thought might help, but the chain fell off again.

Now what? Which of the following will make you a smarter biker?

A. You download a troubleshooting guide from the internet. You spend two minutes going through its steps to check cable tension and the condition of the chain, and you discover that a loose Dunlowbrat was the problem. You tighten the Dunlowbrat and you’re ready to roll.

or

B. A hipster genie appears with a poof. “In cases like this,” he says smugly, “you need to tighten this thing here. It’s called a Dunlowbrat. Here’s a screwdriver. Now tighten the Dunlowbrat.”

Hipster genie promising to make you awesomeWhich is more efficient? Solution B, obviously. You didn’t waste two minutes checking other connections or puzzling things out. The hipster saved you time by telling you what to do.

Which will make you a smarter biker? Solution A. When you went through the troubleshooting process, you learned that cable tension and chain condition can also cause problems, which will make future problem-solving go faster and give you a better understanding of how a bike works.

You also might be more likely to remember a solution you discovered on your own rather than the one that someone with “superior knowledge” simply told you, although the trauma of having a hipster genie suddenly appear would certainly be memorable.

What does this have to do with instructional design?

Let’s turn your bike problem into an elearning activity with a clickable bike.

Challenge: Your bike no longer shifts smoothly, and the chain keeps falling off. Click the part of the bike that is probably causing the problem.

You click a likely-looking nut.

Feedback: A hipster genie pops onto the screen. “Nope! That won’t work. In cases like this, you need to tighten this thing.” He points at a screw on the bike. “It’s called a Dunlowbrat. Click the Dunlowbrat to tighten it.”

You obediently click the Dunlowbrat and an animation makes it look like it’s tightening.

Hipster genie: “Awesome! You rule!”

Your dignity and your brain wither simultaneously.

Genie-free rewrite

Let’s jettison the genie from our elearning version and see what happens.

Challenge: Your bike no longer shifts smoothly, and the chain keeps falling off. Click the part of the bike that is probably causing the problem. If you’re not sure, follow this troubleshooting guide.

You ignore the troubleshooting guide and click the wrong nut.

Feedback: The chain falls off again as you’re climbing a hill, and you get grease on your clothes right before your meeting with the directors of HugelyImportant, Inc. Try the steps in this troubleshooting guide.

You open the troubleshooting guide, which has you click on a bike part for each step and concisely explains why you’re checking each part. When you click the first part, you’re told that it feels tight already. The same happens for the second part. When you click the Dunlowbrat, you’re told it feels loose. You choose to tighten it, and you get the following feedback.

Feedback: The bike shifts smoothly and the chain stays in place. You roll into work relaxed and grease-free.

Face-to-face version

Obviously, in face-to-face training this would be a heck of a lot easier. Let’s say we have a bike-maintenance class in a parking lot. The instructor could bring out a bike that has a loose Dunlowbrat and have someone ride it around the parking lot while shifting. Everyone watches as the chain falls off. The rider also reports that shifting was rough.

The instructor says, “What should we do?” and a few members of the class propose tightening the wrong nut. “A lot of people do that,” the instructor says agreeably. “Let’s tighten that nut and see what happens.”

The chain falls off again, the class is puzzled, and the instructor doesn’t say, “It’s a loose Dunlowbrat.” Instead, he says, “There’s a process we use to diagnose this type of problem. Here’s a handout. Let’s go through it together.”

But genies are fun!

If you’re sure that your audience likes genies, superheroes, and wizards, you’ll probably want to keep using them. But I’d suggest that you encourage the genies to act more like the instructor in the face-to-face example above, helping people find the best solution, and don’t let them tell people what to do or how to think.

You might also want to tell your genies to keep their feedback (“Awesome!”) in line with the level of learners’ accomplishment, unless you’re intentionally using over-the-top humor. Our hipster genie could actually be a fun, over-the-top guide, but only if he uses the techniques of the real-life instructor and helps us figure things out for ourselves.

Genies are a symptom of a deeper problem

The main reason we add genies and their superpowered friends is because we’ve let the material be primarily a presentation, and we just want to make the presentation more “fun.” A deeper solution is to overhaul the design so there’s far less presentation and a lot more learning by doing.

What do you think? Do you think genies can use their magical powers to deepen learning, or are they just another way to add bling to boring presentation? Let us know in the comments.

All photos in this post (c) iStock

Branching scenarios: How many decision points?

You’ve decided a branching scenario will be part of your project. But how long should it be?

First, I’m assuming that we’re talking about an exploratory or “learning” scenario, meaning a story in which learners make decisions without a lot of hand-holding and learn from the consequences of their decisions. I’m also assuming that the skill you want learners to develop is relatively complex, such as managing a conversation to create the best results.

Aim for 7 decision points in most paths

As a general rule I recommend that each path include at least 7 decision points, meaning even if I make a not-great decision, I continue down a path that includes more decisions, including ones that could lead me to a better path, and when I reach the end of the story, I’ve made about 7 (challenging! relevant!) decisions at least.

Of course, the optimal depth for an exploratory scenario will depend on a lot of factors, including the complexity of the skill you want learners to master, their attention span and tastes, and the amount of development time you have.

What about bad decisions?

In some situations, you’ll want to have short paths that go quickly to failure if there are common but egregious mistakes being made by learners in the real world.

Scenario flowchartTo see an example, try the AutoLoon Ethics Training scenario, which simulates the discussion between an instructional designer and a client who wants an information dump.

I included some short, 3-decision paths that go quickly to failure. I wanted to make clear that some common decisions made by instructional designers can quickly doom a project. Longer paths in the scenario include 10-12 decision points.

Click the image in this post to see a larger view of the flowchart, or view the inner workings of the scenario on the BranchTrack site.

Let them go back

In an exploratory scenario, I think it’s best to let learners go back to the previous decision. This encourages them to explore, and it lets you include short, “bad” paths while still making the scenario interesting.

Have some learners review an early draft

The challenge for us as designers is that we’re so deep into the story and we’ve thought through so many possibilities that the scenarios we write can look more complex to us than they do to learners.

It could be a good idea to have a handful of typical learners complete an early draft of the scenario and talk about it with you, so you can get their perspective. It can be useful to do this in a small group, so learners talk with each other and possibly debate things, giving you a sense of how much the scenario is making them think.


London workshop on June 6

Please join me and Norman Lamont in London on June 6 for the one-day, hands-on workshop “Training design for business results.” It’s action mapping on steroids. You’ll get in-depth practice applying activity-centered design to one of your projects. Learn more about the workshop.

Scenario design online course

Learn more