Take a look at this little Save-a-Life Simulator. Play with it for a while and come back to this article when you’re done. I’ll wait…

Pretty cool, huh?

But let’s look a little deeper. What are we looking at? Okay, there is certainly a training (eLearning) component, but is that all it is? Is the training even the most important part?

To me, it is something more.

There’s no instruction in how to use the device

First there is no real instruction in how to use the defibrillator. You learn that through performance support. Designers took the complexity out of the training and built in real-time user directions within the product; the defibrillator itself determines if the patient needs to be shocked, and then literally tells the user how to use it at the moment of need. Can you imagine a person who has never done this before trying to make sense of a set of printed instructions when time is so critical? By having the defibrillator actually guide the user, errors and delays are minimized. Nice.

Motivation and confidence

So where does that leave training? Here, the training developers made several inspired design decisions. Since the manufacturer had already built user directions into the defibrillator, they didn’t need redundant step-by-step instruction. What they did need, however, was a simulation that would focus on getting someone to actually use the defibrillator in the first place. And, by incorporating a decision-making activity, they presented realistic situations and decisions that have life and death outcomes. This approach builds confidence on the part of users that they can do it, rather than having them freeze and run away.

Instant engagement

The training piece is brief and to-the-point. No objectives, no pretests and posttests, no lessons or PowerPoint slides, etc. Quickly get the learner involved in the critical decisions that he or she needs to make and let the consequences of those decisions do the teaching. Clearly, making wrong decisions brings the learning home pretty graphically and indelibly. And because the entire program is short, it can likely be accessed anywhere and on any device—a critical attribute of learning and performance in today’s mobile world.

Background information stays in the background

There is background information on heart rescue, with interviews, case studies, and other content. But since this is not essential to the major performance goal, it doesn’t dominate the training component. Instead, they provide it via an optional “learn more” feature that displays at appropriate points in the program. This separation of essential vs. non-essential information filters out any “nice to know” noise and is a key in focusing the user on the most important content.

Where was the design effort?

Another interesting aspect of this program is the relative value of training vs. performance support. Sure, the training is valuable, but it is likely a one-time occurrence for each person. It is hard to see anyone continually reviewing the training. Once they get it—that they need not worry about how to use a defibrillator, just that they need to take action and actually use it, and that the defibrillator is as foolproof as it could possibly be—the training can be jettisoned. As useful as the training is, I suspect much more time and effort went into getting the performance support component built into the defibrillator as right and user-oriented as possible.

I also suspect that when the designers of this product started taking about how to proceed, they didn’t start by saying, “we need to build training to teach people how to use a defibrillator.” The creators knew that the most critical goal of this program was not to provide detailed training in defibrillator use, but to reduce panic and increase willingness to “step forward.” The designers knew that if they could get people to actually use a defibrillator, the rest would be relatively easy. This represents a true understanding of the critical performance requirements.

What if…

Imagine a world where the tools we use remove complexity rather than add to it, and are so intuitively easy to use that we can operate them—correctly—the first time, precisely when we need to use them, with minimal risk. Imagine a computer that would be this easy to use. Or a smartphone. Or a home entertainment system. You get the idea … the fact that this little simulation focuses on a life and death issue is further testament to the power of performance support and user-centered design.

How much of our training is compensation for tools that don’t work right? How much of it is an attempt to re-explain bad documentation? How much of it is nothing more than “work-arounds,” often too little and too late, to a bad system or process? Why do we tolerate unneeded complexity, and then ask training to straighten it all out, sometimes at the last minute? If we can create a tool that saves lives and teaches people how to use it at the moment of need, how many other everyday applications could benefit from this same approach?

The possibilities are endless.