ACM Logo  An ACM Publication  |  CONTRIBUTE  |  FOLLOW    

How to design recyclable learning objects

By Michael Feldstein / July 2002

Print Email
Comments Instapaper

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.

Object Lesson #2: Content is Harder to Recycle than Design

A financial services company brought me on as part of a large team to put together e-learning for their first-year brokers. This project was huge; they eventually created roughly a hundred courses on topics ranging from retirement planning to options trading to selling skills. Since we were creating a lot of interrelated courses in parallel, it seemed sensible to try to coordinate and reuse content across the curriculum. In the early days, we had frequent meetings trying to map out the various courses, divide them up into buckets of related topics, and generally work together to share ideas and content.

Within a few months, though, we were meeting much less frequently and we hardly ever talked about reusing content. The reality was that we were all working too hard to produce too many courses too quickly for us to take the time required to write shareable content. Maybe in a year or two, after all the content was up, somebody would be able to go back through it, tighten up the connections, and eliminate the redundancies. (Programmers might call this "refactoring.") But it certainly wasn't going to happen at that time if we had any hopes of meeting our deadlines.

Interestingly, though, while learning content didn't get re-used very often, instructional techniques did. The trend started mainly because the programming department was trying to reduce their own work to a manageable level. The way the process worked was that the designers would be assigned a liaison from the programming side (who they called a "producer"). Once a first script was worked up, the designer and the producer would meet. The designer would say, "Here's what I'd like to do." More often than not, the producer would reply, "Well, doing that will probably impact your schedule, but here's something similar that we've done before and that would take us less time to do. Will that work for you?" Under normal circumstances it's a bad idea to let what's easy and convenient for the programmers dictate instructional design. In this case, however, there was a good balance of power between the designers and the producers. If the pre-made parts didn't fit, then the designers could often insist on getting something new created. The designers, in turn, were obliged to look at what techniques had already been used before going out and reinventing the wheel.

Since we had many minds working to solve design problems in parallel, we quickly built up a shared vocabulary of instructional techniques. Designers and producers increasingly had very substantial design discussions earlier in the process. Brainstorming sessions became more common. As a designer, I found myself starting to conceive of new courses in terms of the building blocks that I already had at my disposal. When I had a hole that couldn't be filled with an existing building block, I began to think about creating a design technique that could fill that hole and could also be used as a building block in other courses.

By the end of the year that I spent on the project, we were reusing "learning objects" quite a bit even though we hardly ever reused the content. I began to see that there is something that can be called learning object type, which you can think of as an instructional template (like a quiz, a tutorial, an FAQ, or a simulation). This object type is distinct from a learning object instance, which is the instructional template filled with particular content. Learning object types (or templates) turn out to be much easier to reuse than learning object instances (or content nuggets).

Object Lesson #3: Recycling Design Can Give Bigger Gains Than Recycling Content

A pharmaceutical company wanted me to write twenty-one hours of lab training to teach relatively menial but highly regulated physical tasks to learners with a high school level of education. The twenty-one-hour total broke down into seven three-hour classes teaching lab techs in different facilities the specific procedures for those particular facilities.

To be honest, I really didn't want to write all that training. Some jobs are fun because the content is engaging. These particular courses did not fall into that category. Furthermore, because the regulations surrounding these tasks constantly changed, the courses would have to be updated regularly—a job that I did not want to perform and that they probably didn't want to pay me to do over and over again.

Fortunately for all involved, it dawned on me that, while the content from course to course was almost completely different, the instructional tasks for each course were almost completely the same:

  • In each case, we could start out by showing the learners the steps in the procedure they had to perform. (We had a first page with a video that showed them the entire procedure and then a second page which broke the procedure down into discrete tasks and attached a shorter video clip to each task.)
  • Next, we had to call the learner's attention "do's and don'ts." (We had a "Do's and Don'ts" page with photographs of the "do's" and cartoons of the "don'ts" to create contrasting visual memories."
  • Finally, we followed with a series of reinforcement exercises in which the learners had to put the tasks in proper order, figure out what steps (if any) were missing, and so on.

I wrote the first course as a template and helped the company create a simple, homegrown Learning Content Management System (LCMS) to make it easier for non-technical people to put content directly into that template. From there, the client's content experts could create a new course simply by starting with the old one, replacing the content from the old course with similarly structured content covering the new procedures, and doing the equivalent of "Save As…" in the LCMS. Since their internal people knew the "what" of the course far better than I did, and since my templates showed them the "how" of teaching it effectively, they were able to save roughly seventy-five percent of the time and cost that it would have taken me to create the other courses for them the old-fashioned way. And they were able to do so even though the content from course to course was almost completely different.

Object Lesson #4: Some Old Tricks Still Work

A medical center asked the company that I work for to create several courses on Federal medical billing regulations and the various procedures that employees have to follow in order to be in compliance. The clients wanted to start with courses that covered all the relevant topics, but they were concerned that substantial groups of employees really only needed to know the particular subset of those topics that directly touched their jobs. In other words, they wanted to be able to reuse the content from the current courses in future courses that were tailored for different constituencies (mainly by cutting out pieces of the content).

It turned out that paying attention to old-fashioned learning objectives was the key to our ultimate success. We spent a lot of time refining the test questions, which we tied to learning objectives in a one-to-one relationship. We clustered those test questions into groups of three to six that seemed to be closely related. I then asked the client to essentially write one informational brochure for each cluster of questions. The content of each brochure became the beginnings of each new lesson (or "learning object"). Because the questions in each cluster were closely related (and usually focused around the performance of one task), the chances that part but not all of the contents of a lesson would be relevant to a particular audience were minimal. And because (by the end of the process, at least) we were imagining each lesson as it's own separate brochure, the tutorials came out as learning objects that were fairly independent of each other. We did not take similar care to separate out the contents of the review exercises because that would have been significantly harder than writing self-contained tutorials. We didn't know whether the extra effort would pay off in the end, so we chose not to take the risk. As a result, the course content was recyclable but not completely reusable. Nevertheless, a good 80% (or more) of the work will already be done should they eventually go ahead with the other versions.

The client got a bonus out of this design exercise, too. With a little effort on the part of the programmers, we were able to implement adaptive testing. In other words, for every question that the learner got wrong on the pretest, we were able to flag the lesson and page in the course where the answer to that question could be found. We chose to highlight the pages that the learner needed to see in the course menu, but we could have just as easily removed the pages that the learner didn't need to see. This kind of customization was possible because we had made the effort to see the course as a collection of distinct and separable units, each of which is governed by a short list of concrete learning objectives.

Object Lesson #5: Separate Out the Things That are Likely to Change

A financial services company hired the company I work for to develop project management training for the software development teams in their various business units worldwide. The core project management methods were to be standardized company-wide, but each business unit had it's own process document templates (or "artifacts") and other procedural wrinkles that they added. This created a problem for us. Nobody wanted generic training; each business unit wanted the ability to link the general content with their specific procedures. Nevertheless, we were charged with developing training for everyone worldwide in one shot.

The way we dealt with this was we created a sidebar on every page of each course. Every sidebar has standard headers for things like tools, tips, and artifacts. This particular company has the funds and the technological capabilities to dynamically fill in the content under those headings. In other words, the course will know who the learner is and therefore which tailored information she needs to see. Each page can be customized by the business units without having to rewrite the content in the main area of the page. Even without this technological wizardry, though, the strategy still works. We could have simply created a separate version of the course for each business unit. Since the main content remains the same, we would only have had to customize the information in the sidebar (which is mostly links to templates and other content that the business units have already created).

Making this strategy work took some care, though. On the one hand, we wanted to make references from the content in the main frame of the course page to the supplemental content on the sidebar so that the learners wouldn't miss that extra (but vital) content. On the other hand, since we didn't know exactly what that content would be, we had to make our references relatively generic. Still, we had a pretty good idea of what content each business unit was required to have in each sidebar; for example, they could make their own project plan template but, whatever it looked like, they had to have one. We couldn't write something like "Take a look at the 'Risk Assessment Matrix' document in the sidebar," but we could get away with something like "Take a look at the risk assessment templates linked in the sidebar." We also knew that we didn't need to have references to every single item in every single sidebar. What we mainly wanted to do was get the learner in the habit of checking the sidebar on every page. Once we established that habit, then pointing to specific items became less critical.

Object Lesson #6: It Isn't Always That Hard

If you read back over the previous object lessons in this article, you'll notice that none of them makes any explicit references to contents of any of the others. Each one could stand entirely on it's own as a separate column or be integrated into some other article without the need to delete anything. You could fairly call each one a reusable object (although I wouldn't call them learning objects). At the same time, the stories do build on each other. For example, both the title and the content of Object Lesson #3 responds directly to the contents of Object Lesson #2. As a result, there is something of a narrative arc even without the help of some of the usual as-I-said-earliers and similar linguistic connectors. This is a trick I learned not from a course design project but from a science fiction novel. Kirinyaga, by Mike Resnick, is a fascinating read—and not just because it's based on the real history of one of the more interesting parts of Africa. The book was written over several years as a series of independent short stories, separately published in different magazines. Most or all of those stories won awards for short fiction. They are all about the same cast of characters and take place in the same locale, but each story stands on it's own. Yet when Resnick strung them together in a particular way, he magically created a cohesive novel. It's possible to do. It's just not easy.

While I don't pretend to have achieved anything like Resnick's level of artistry, I do believe that we mere mortals can aspire to create some magic of our own, in which the whole of our work can be greater than the sum of the reusable learning objects. This article, for example, weaves together some of the techniques described in the previous object lessons to create a unified piece constructed of largely recyclable parts:

  • Like Object Lesson #1, it uses the same cast of characters but varies the story line. (In this case, the main character in all the stories is me.)
  • Like Object Lesson #4, it achieves its goals partly by separating each point (or learning objective) into a discrete content chunk.
  • Also like Object Lesson #4, I didn't try to make every part infinitely reusable. The object lesson you are reading now, for example, explicitly refers to the previous ones and would therefore be difficult to use in other contexts.
  • Like Object Lessons #2 and #3, the article reuses an instructional strategy. The fact that each chunk started with a story and ended with lessons learned made it possible for me to write this article relatively quickly while, at the same time, establishing a kind of rhythm for the readers.
  • One could imagine creating sidebars for each story, similar to those used in Object Lesson #5, to customize the stories for particular audiences.

None of these strategies will work all the time. (I'm not even 100% sure that they worked in this article.) When they do work, they may not work as effectively as a course designed without the constraints caused by the need to recycle. And all of these strategies require effort and skill (and therefore cost) to implement. That means the return-on-investment for creating recyclable learning objects has to be evaluated on a case-by-case basis. Nevertheless, when it's done carefully and appropriately, recyclable learning objects can be the key to sustainable (i.e., affordable) e-learning development.


  • There are no comments at this time.