This is the first in a series of thoughts on some broken areas of ID that I will be posting for Mondays. The intention is to provide insight into many ways much of instructional design fails, and some pointers to avoid the problems. The point is not to say â€˜bad designer‘, but instead to point out how to do better design.
The way I‘ve seen many learning solutions go awry is right at the beginning, focusing on the wrong objective. Too often the objective is focused on rote knowledge, whether it‘s facts, procedures, or canned statements. What we see is knowledge dump, or as I‘ve heard it called: show up and throw up. Then, the associated assessment is similarly regurgitation of what you‘ve just heard. The reasons this happens, and why it doesn‘t work, are both firmly rooted in the way our brains work.
First, our brains are really bad at rote remembering. We‘re really good at pattern-matching, and extracting underlying meaning. That‘s why we use external aids like calendars. Heck, if it‘s rote knowledge, don‘t make them memorize it, let them look it up, or automate it. OK, in the rare case where they do have to know it, we can address that, but we overuse this approach. And that‘s due to the second reason.
Experts don‘t know how they do what they do, by and large. Our brains â€˜compile‘ information; expertise implies becoming so practiced that the process is inaccessible to conscious thought (ask an expert concert pianist to describe what they‘re doing while playing and their performance falls apart). We found this out in the 80‘s, when we built so-called â€˜expert systems‘ to do what experts said they did, When the systems didn‘t work, we went back and looked at what the experts were really doing, and there was essentially zero correlation between what they said they did, and what they actually did.
What happens, then, is that our Subject Matter Experts (SMEs) do recall what they studied, and toss that out. They‘ll dump a bunch of relevant knowledge on the designer, and the good little designer will develop a course around what the SME tells them. So, we see objectives like:
Be able to cite common objections to our product.
What‘s needed is to focus on more meaningful outcomes. Dave Ferguson has written a nice post defending Bloom‘s skill taxonomies, and he‘s largely right when saying that focusing on what people actually do with the knowledge is critical. However, I find it simpler to distinguish, ala Van Merrienboer, between the knowledge the learner needs, and the complex decisions they apply that knowledge to, with the emphasis on the latter. So, I’d like to see objectives more like:
Be able to counter customer objections to our product.
The nuances may seem subtle, but the difference is important.
How does a designer do that? SMEs are not the easiest folks to work with in this regard. I‘ve found it useful to turn the conversation to focus on the things that the learner needs to be able to do after the learning experience. That is, ask them what decisions learners need to be able to make that they can’t make know. Not what they need to know, but what do they need to be able to do.
And, I argue, what will likely be making the difference going forward will be skills: things that learners can do differently, not just what they know. I recall a case where an organization was not just looking for the learners to understand the organizational values, but to act in accordance with them (and that that meant). That‘s what I‘m talking about!
When it comes to capturing objectives, I‘m perfectly happy with Mager‘s format of specifying who the audience is, what they need to be able to do, and a way to determine that they‘re successfully performing. From there, you can work backwards to the assessment, to the concept, examples, and practice that will develop the skills to pass the assessment.
There‘s another step, really, before this, and that‘s determining what decision learners need to make differently or better to impact the bottom line, e.g. choosing objectives that will affect the organization in important ways, but that‘s another topic for another day.
Doing good objectives is both a skill that can be learned, and a process that can be supported. You should be doing both. Starting from the right objective makes everything else flow well; if you start on the wrong foot, everything else you do is wasted. Get your objectives right, and get your learning going!