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:
Six hours after you eat the sushi, you begin vomiting. Three days later, you finally stop. Your doctor explains that the sushi was probably poorly refrigerated and contained zygodread. “You should have bought something hot that was cooked right in front of you,” he says as he hands you the prescription for an expensive antibiotic. “Was there any pork skin? I always buy that if it comes right out of the fryer.”
We’ve described the result in a memorable way. We’ve even snuck in some telling feedback, but it’s coming from a person who actually has a role in the story that gives them the right to lecture us, not a preachy disembodied voice.
With this small change, we’re letting people learn from somewhat realistic experience, and the more realistic and vivid we can make the experience, the more likely they are to remember it.
What about correct choices?
Let’s say that instead of choosing the sushi, you go directly to the pork skins. How will you learn that you made the right choice if the Omniscient One doesn’t tell you? Let’s compare approaches.
Telling feedback: Correct. The pork skins are less likely to give you food poisoning because they’re hot and are cooked in front of you. The sushi might not be properly refrigerated and could harbor zygodread.
Showing feedback: While you enjoy your hot, crispy pork skins, you hear a young woman tell her friend, “There’s no way I’m buying that sushi again! Last year there wasn’t ice in the cooler, and the sushi was full of zygodread! I’ve never been so sick in my life!”
Here’s another example. The learner has just tried to stop a (fictional) speeding forklift by pressing the red button on its steering wheel.
Telling feedback: Incorrect. The red button on the steering wheel sounds the horn.
Showing feedback: The forklift sounds a cheery “toot!” as it continues to speed toward the plate-glass window.
Which are you more likely to remember?
For more on this, see this post about eager-beaver feedback and How to rewrite a quiz question as scenario-based training.
But what if a stakeholder doesn’t trust our learners?
If you try to use “showing” feedback, a stakeholder is likely to worry that people won’t be able to draw conclusions. They’ll insist on telling learners exactly what is right and what is wrong and why. You could try proving to this person that learners can think for themselves by giving some prototyped activities to actual learners and then having them explain to the stakeholder what they’ve concluded from the activities.
Or, you could give up and include the telling feedback, but only for the correct answers. It could work like this:
1. The learner makes a sub-optimal choice and sees the unfortunate result, with no explanation from the Omniscient One. They’re required to try again until they make the correct choice.
2. On their second try, the learner makes the best choice. They see the happy result, and then the Omniscient One chimes in to explain why it was the best choice and what was wrong with all the other choices.
If you use this approach, everyone will first see realistic results and draw their own conclusions, and then they’ll have these conclusions confirmed (or maybe corrected) by the telling feedback. I resist this approach because it makes you a control freak, but it can be useful because it reassures stakeholders and the legal department.
In Leaving Addie for SAM: An Agile Model for Developing the Best Learning Experiences, Michael Allen and Richard Sites refer to the two types of feedback as consequences and judgments. They suggest that if you use judgments, you should delay them. “Judgments offered too quickly cheat learners of the opportunity to determine for themselves if they are making good choices,” they write. I’m also concerned that instant judgments can be seen by learners as an insult to their intelligence and could turn them into resentful “just-click-it-to-get-it-done” foes of elearning.
Let them think for themselves, if only for a few seconds!