“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!”
In 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.
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:
- Is it ever okay to be a control freak?
- Jettison the genies and let learners think
- Let me tell you everything you need to know! Or not.
- Why you want to focus on actions, not learning objectives
- Technical training: What do they need to DO?
- What to do if they just want “awareness”
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
With 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.