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

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

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

Why you want to put the activity first

Let’s say we’re designing a course that will help widget sales people overcome buyers’ objections. The objection we’re focusing on right now is this one: “I’ve read that your widget creates a lot of heat.” We have a specific way we’d like our sales people to respond to that objection.

Some people in our audience are familiar with the concerns about heat, while new people might not know as much.

How do you think most training designers would approach this? I think they’d do it like this.

Presentation followed by activity

The designers would think, “First, we’ll tell them the common concerns about heat, to make sure everyone knows them. Then we’ll tell them what our own research shows about the heat and why it’s not a big deal. Then we’ll tell them how to respond to heat objections, and finally we’ll let them practice with a scenario.”

Why did I label this “boring and inefficient?”

  • The learners have to trudge through many screens before they finally get to use their brains.
  • Some people already know the stuff presented on the many screens.
  • The how-to info is presented immediately before the scenario, making the scenario a simple check of short-term memory.

Here’s a more efficient approach that has the added advantage of helping people learn by doing.

Series of activities followed by a recap

We immediately plunge learners into a realistic scenario — followed by another and another. Then we concisely recap what they’ve figured out through the scenarios.

The material feels like a stream of activities, not pages of information followed by one lonely memory check. The recap will be memorable and concise because it refers back to concrete examples, such as, “As you saw with Ravi’s objection, it’s best to …”

But what about the information?

We can include the information about heat issues as optional links in the scenario.

Screen from scenario with links to optional information

Now our material is more efficient and a heck of a lot more interesting. People who already know all about the heat issues (or, importantly, think they know) will forge ahead without reading the optional documents. Newer or more careful people will check the documents to make sure they know what’s going on. Both groups will figure out if they chose correctly when they see the results of their choices.

In addition, the optional documents are low-tech PDFs or pages on the intranet, the same documents that people use on the job. This makes the information much easier to update and puts the scenario in a more realistic context.

But they might just guess and miss important information!

The usual argument for the boring and inefficient approach is, “We have to make sure everyone is exposed to the information.” But who cares whether they’ve been exposed to it? What we care about is whether they know it and can apply it.

So we’ll design scenarios that make them prove they know it, and we’ll design enough challenging scenarios about the same important information to make sure no one is slipping through the cracks. And if we’re really worried about information being missed, we can include it in the feedback, as shown in this post.

But you didn’t show them how to overcome objections!

We haven’t led them by the nose through the Heat Objection Handling Process because we want them to figure it out through experience. Our feedback will help. For example, if someone chooses option C above, they’ll see the following result:

“I’m not surprised that your studies don’t show any problems,” Ravi says, sounding a little annoyed. “But Widget World does rigorous, independent testing, and they found heat issues. What can you tell me about the heat?”

From this, learners realize that shoving research at the customer backfires. It sounds like option A was the better option, and for their next step, they’ll want to calmly discuss the concerns. (This post goes into more detail on why we’re just showing the result rather than telling the learner what they did right or wrong.)

More design time, less development

This approach usually requires more in-depth discussions with the subject matter experts and more careful script writing. However, it often results in quicker and easier development. We’re building fewer screens and, happily, we feel less compelled to add bling in a desperate attempt to make a boring presentation more interesting.

Have you had any success designing material that puts the activities first? Let us know in the comments!

Example of a realistic activity: Set up the laptop

I preach a lot about making activities realistic and showing the results of the learner’s choice. Here’s a good example of those principles from the folks at SmartBuilder.

In the activity, you’ll learn the ports of a laptop and apply your knowledge in a realistic situation. Go try it, and then come back here for some discussion.

A “traditional” course wouldn’t have let us explore the laptop. Instead, we’d have to sit through several slides of presentation that explained each port whether we already knew it or not.

explore-the-laptop

After we’ve explored as much or as little as we want, we’re faced with a realistic situation — and a person who speaks directly to us. It’s not “Help Bob set up his laptop,” it’s the higher-pressure “Help me.” The time limit adds some more pressure and a bit of a game element.

A person asks us to help him set up his laptop quickly for an important presentation

Finally, when we make a choice, we see the realistic result of that choice, not a patronizing “correct!” or “incorrect.”

After choosing the wrong cable, the person we're helping expresses impatience.

You can see more examples on this page of the SmartBuilder site. I use this activity and many others as examples in my instructional design workshops.

Do you get resistance to this type of activity from your stakeholders? If so, what arguments have you used to convince them that learners should be free to skip things they already know and draw conclusions from their experiences? Please share any tips you have in the comments.

Hey, Australia! I’m coming your way

I’ll be giving a one-day version of Instructional design for business results in Sydney on Nov. 13 as part of the Learning@Work conference (details to come). I’ll also be available to give workshops at your site in Australia or New Zealand between Nov. 14 and 30, so if you’d like to set something up, please let me know.

Feedback in scenarios: Let them think!

You’re at the county fair. Your kids are off watching the pig race, and you’re starving. There are only two food carts nearby. One sells deep-fried pork skins from a pot of bubbling grease, and the other sells sushi from a styrofoam cooler. You decide to buy the sushi.

As you hand over your money, a disembodied voice suddenly booms from the clouds above. “Incorrect!” it intones. “Unrefrigerated sushi can harbor zygodread, which can cause severe vomiting. You should never assume that a cooler at a county fair contains ice. It’s always safer to buy hot food that’s cooked in your presence, such as the pork skins. Try again.”

You’ve just met The Omniscient One. It’s the personality-free know-it-all that drones through most elearning. When it intrudes into decision-making scenarios, it sucks the life out of our stories and the brains out of our learners.

“I know everything, and you have no brain”

The Omniscient One (the OO to its friends) is a big fan of telling feedback, because it knows everything. It not only tells us whether it approves of our choice, it also explains exactly how we have sinned and what we must do to atone. Like the folks in your legal department, it believes that no adult can be trusted to draw even the simplest conclusion on his or her own.

An alternative: show the result

In the real world, we’d remember the sushi lesson best if we ate the sushi and then spent three very unpleasant days. In elearning, you could call this showing feedback because, well, the elearning shows (or at least describes) the results. The feedback isn’t a pronouncement from on high but is instead something like this: [Read more…]

Scenarios: What are they good for?

“Why do you want to use scenarios?” your client asks. “Why can’t we use the quizzes that we’ve always used?”

Sometimes the best way to convince a client is to show them through examples. Present one of their quiz questions three ways, so the client can see for themselves the deeper thought required by a scenario-style question.

Here’s an example. What kind of thinking is required by each type of question?

1. Quiz question

Which of the following is the most secure way to carry sensitive data?

    A. On a laptop

    B. On a USB drive chained to your wrist

    C. On a CD titled “The Chipmunks Sing Disco Duck”

Feedback for incorrect answer: Incorrect. Try again.

2. Mini-scenario with correct/incorrect feedback

Bob wants to work on the salary data at home. He has a long commute on a train. How should he carry the data with him?

    A. On his laptop

    B. On a USB drive chained to his wrist

    C. On a CD titled “The Chipmunks Sing Disco Duck”

Feedback for incorrect answer: Incorrect. Try again.

3. Mini-scenario with “showing” feedback

Bob wants to work on the salary data at home. He has a long commute on a train. How should he carry the data with him?

    A. On his laptop

    B. On a USB drive chained to his wrist

    C. On a CD titled “The Chipmunks Sing Disco Duck”

Feedback for A: Bob falls asleep during the commute, and a thief steals his laptop and sells the data. Try again.

Feedback for B: Bob falls asleep during the commute. A thief sits next to him, plugs his USB drive into his laptop while Bob is unconscious, and later sells the data. Try again.

Feedback for C: Bob falls asleep during the commute, and a thief steals all his belongings. The thief breaks the CD into pieces in disgust and no one ever sees the data. This is the best choice.

Version 1, the quiz question, asks learners to regurgitate a fact with no context.

Version 2 puts the facts into a realistic context but directly tells the learner when they’ve made an incorrect choice. [Read more…]

Scenario design online course

Learn more