How to Design Recyclable Learning Objects
It's hard not to fall in love with the notion of reusable learning objects. The idea of a world filled with little self-contained lessons that you can assemble into any course you can think of seems so…well…cool. How could you not want something like that? Unfortunately, after five years of struggling with the challenge of finding that world, I have come to the conclusion that I am simply not smart enough to lead the way to the Promised Land of e-learning, where milk and honey flow from the earth and learning objects can be plucked like ripe fruit from fig trees. I continue to search far and wide for somebody who is smart enough to lead the way, but so far I'm still pretty much wandering in the desert.
I have therefore set my sights somewhat lower. Rather than aiming to create seamlessly and instantly reusable learning objects, I try to think about which pieces of my e-learning courses are likely to be useful in other courses and whether I can invest a little extra time in the design now in exchange for saving a little more time later. I'm not thinking about reusing my unaltered work so much as I am thinking about recycling it. In this article, I'm going to share what I've learned so far.
(You may have noticed already that I referred to recycling "work" and not "content." My experience has been that the content, i.e., the specific words, pictures, and other representations of particular ideas, is cheaper to create and more expensive to recycle than the instructional design and programming which presents the content in a learnable way. More on this later.)
Since this sort of discussion can very quickly become too abstract to be helpful, I'm going to stick to the time-honored method of story-telling, providing vignettes of actual client problems I had to solve and what I learned while struggling to solve them.
Object Lesson #1: Reusability Breaks Some Instructional Designs
Back in early 1998, a professional association for managers came to the company I worked for with the idea of converting all of their self-study workbooks into online courses. After looking over their curriculum, it became clear to me that a lot of their courses were highly interrelated. For example, somebody who was learning about the process of conducting performance reviews might have also found a couple of the chapters in the workplace coaching course to be useful. Having just read a rather academic article speculating on the notion of "object-oriented instructional design," I suggested the idea that the courses could be created in chunks, or "learning objects," that could be custom-assembled into new courses. Learners could either string the chunks together in the recommended ways or they could map their own new paths through the content, essentially creating personalized curricula. To my immediate delight and later dismay, the client agreed to try this approach.
I quickly discovered that some of my most basic techniques and habits as an educator no longer worked in the new world of reusable learning objects. In the old world, I could make explicit connections between the ideas in various lessons. I could (and often did) start sentences with phrases like, "As you learned in the previous lesson…." Any decent instructional designer (in fact, any decent writer) knows that using these sorts of connective phrases can be critical to helping your audience understand the bigger picture. But in the new world of learning objects, I couldn't assume anything about what content the learner had seen previously. Therefore, I couldn't know what connections I had to make.
Likewise, I was used to telling stories that carried over from one lesson to the next. Because there's nothing quite like a good concrete example to make a lesson stick, a repeating storyline across the entire arc of a course tends to tie all the lessons together very effectively. In the new world, though, I didn't know what the arc of the course would be. We thought about picking a story that would work across all courses, but since we didn't have a clear idea of what all courses (both planned by the client and created by the learner) would be, we couldn't be sure that our storyline would always work. To the contrary, we worried that if some of the stories were different then most or all of them might have to be different, even within a single course. It would seem odd if most of the stories in a (learner-assembled) course were the same but a few were different. The only way to avoid that potential problem (we thought) was to make them all different.
Review exercises were also challenging. I was used to being able to create simulations or games late in a course that would string together a number of ideas that the learners had covered in various lessons. This was particularly useful when lessons were short, since it's difficult to come up with an interesting scenario to test people's knowledge on just a couple of short facts that they had learned.
In the end, we came up with the following design compromises:
- Each lesson would focus on one self-contained but relatively rich task, such as having an initial performance appraisal meeting with an employee. That way we could write example stories and exercises that could be structured around the real-world events that had natural story-lines. (This approach seemed to work for their particular content, which was largely focused on tasks that seemed to be neither too big nor too small to work as topics for separate lessons. I was pretty sure that it wouldn't work for all content, though.)
- A "lesson" contained three parts: a tutorial that covered the basic concepts, a simulation that let the learners practice the task covered in the lesson, and a job aid that walked them through the same task in their real-world environment.
- Rather than creating either a unified storyline or completely separate stories, we created characters and an imaginary workplace that enabled us to tell stories which had common elements in them without having to worry about always connecting the actual plot lines across lessons.
This design strategy seemed to work well for our pilot course, but I wasn't sure that it would hold up with a dozen courses. Would the content always be chunkable into lessons of the right size? Would the universe of characters we created work for all courses? Would the three-part design of the objects (tutorial/simulation/job aid) always fit? When strung together, would these units feel like a course, or would they be too disjointed and too abstract for the learners? Unfortunately, I never found out the answers to these questions. The project was killed after the pilot for unrelated business reasons.
