“Never design anything without first writing the learning objectives.”

We all know this. It’s a useful rule, but only when the objectives are useful.

And there’s the problem — conventional learning objectives can work against us. They’re our friends, but not always.

What do I mean by “conventional learning objectives?” This sort of thing:

• List the three steps of widget certification.
• Explain the difference between widget certification and widget approval.
• Describe the widget supply chain.

Here are three questions that will help you set boundaries with our frenemy.

1. Do people actually need to “learn” something?

Conventional learning objectives might be your friends if both of the following are true.

1. A knowledge or skill gap clearly exists.
2. Closing that gap will help solve the problem.

Is there really a knowledge or skill gap? Maybe the problem is mostly caused by bad tools, an inefficient process, lack of incentives, or some other environmental issue. With your client and SME, first identify what people need to do on the job, and then walk through this flowchart before agreeing to develop training.

Will closing the gap solve the problem? Maybe it’s true that people don’t know the intricacies of the supply chain, but installing that information in their brains won’t make them better widget polishers. Don’t deliver content just because someone told you to.

(In the Asia-Pacific region? This workshop on Jan. 23 will help you stand up to content-obsessed clients.)

2. Are we writing useful objectives for the formal training bits?

If our analysis shows that we really do need to design a learning experience, then, yes, we need objectives. Are the actions we wrote earlier good enough, or should we let learning objectives elbow their way into our project?

Here’s an example from my book.

Let’s say that we want firefighters to educate the public about preventing forest fires and quickly put these fires out when they occur. Our official goal is, “Fire-related losses in our region will decrease 10% by next year as firefighters prevent and extinguish brush and forest fires.”

Which of the following do you think I’d accept as actions to reach this goal?

a) Identify the techniques used to extinguish a brush fire
b) List the principal sources of combustion in a deciduous forest
c) Describe common public misconceptions about campfires
d) Quickly extinguish a brush fire in a dry mixed forest
e) Define “incendiary device”

If you said that only d, “Quickly extinguish a brush fire,” was an action by my standards, you’ve gotten my point.

An action is something you see someone do as a normal part of their job. It doesn’t take place in their head or in that abstract world I call Testland. The action should be the focus of our analysis and design, and it should be the statement we use to “sell” the material to the stakeholders and learners.

“But the other statements are good objectives!”

In the world of conventional instructional design, the other statements are also observable objectives.

For example, we can watch a firefighter write a list of the techniques used to extinguish a brush fire, and we can point at that list and say, “See? They know it.” And that’s the problem — we’re just measuring whether they know it. There’s no guarantee that the firefighter will actually apply this knowledge, which is what we really want and what we should be helping them do.

“Identify the techniques” is an enabling objective. It describes information necessary to perform the action. It goes in the information part of the map — I’d list “techniques to extinguish a brush fire” as required knowledge that’s subordinate to the action about putting out fires.

Our goal is to create realistic, contextual practice activities. We can do that only if we focus on what people need to do. If instead we let knowledge-based objectives distract us, we’ll create the usual information dump followed by a quiz, which is the approach that helps make us irrelevant.

3. Who needs to see the objectives?

The client

If you’re using action mapping, your client helped create the list of actions, so they’re already familiar with them. If you need to submit a formal document, I recommend an outline rather than a big design-everything-at-once document. (See this big interactive graphic of the action mapping workflow.)

In that outline, you can include your action map, which shows the actions and the information required by each. The actions are your main objectives, and the bits of information represent the knowledge that supports those objectives.

If your client wants to see conventional learning objectives, consider listing your actions as “performance objectives.” Then, indented and subordinate to each performance objective, list its enabling objectives.

I resist writing the enabling objectives using test language (“describe, explain, define…”) because that sets the expectation that there will be a knowledge test. Maybe some of the knowledge doesn’t need to be memorized and could instead be included in a job reference. It won’t be tested, so there’s no reason to write a test-style objective about it.

Or maybe people do need to memorize some stuff, but a separate knowledge test would be artificial. Instead, you could assess with the same type of activities you provided for practice, which would test not only whether people know the information but whether they can apply it.

The learners

Briefly tell people what they’ll be able to do as a result of the activity, and focus on what they care about. Put those over-eager learning objectives on mute because they don’t know how to sound appealing.

• Not this: “When interacting with a dissatisfied customer, appropriately apply the five steps of the Abrams-Martinson Dissatisfied-to-Satisfied Customer Transformation Model” that no one has heard of but a consultant convinced us to use
• This instead: “Turn an unhappy customer into a happy one in 5 quick steps”

Again, I’m not talking just about courses. This applies to activities, which could (and maybe should) be provided individually, on demand. Each activity that stands alone should quickly make clear what people will practice doing and how they’ll benefit.

For more on the distinction between an action and an enabling objective, see Why you want to focus on actions, not learning objectives.

---

Online workshop Jan. 23

In the Asia-Pacific region? Learn to control your clients’ minds (sort of!) on January 23. In this 90-minute interactive workshop, you’ll change how you talk to stakeholders and manage the initial project meetings. You’ll stop being an order taker and instead steer clients toward solutions that solve problems and improve lives.

Learning Technologies UK

I’ll present a shorter version of the Jedi Mind Tricks workshop in my Feb. 23 session at Learning Technologies UK.