Courseware Design & Development

Courses designed by WildPackets utilize what we believe is an optimal design strategy. It is our hope that this information will be useful in the design of materials at your company. Please remember that this information is Copyright 1999 by WildPackets and may not be duplicated without permission.

Welcome to the world of courseware development! You are about to take an exciting step from the front of the classroom to the behind-the-scenes action that creates the course materials you and your students rely upon every day. Many instructors have experienced, shall we say, "less than wonderful" course materials. They may find themselves saying things like:

• "What were they thinking when they put this slide in?"
• "Well, I'll have to make up a transition for that slide."
• "Oh boy. Here comes that slide that the students never understand again!"

This manual will give you the basic tools necessary to avoid the common organizational and planning mistakes that even experienced courseware developers make.

The key to this document's power is that it defines a courseware development process--a series of well-defined steps that will guide you along as you work. This paper will teach you to produce effective courseware materials--materials that benefit both instructors and students by being pleasing to read, easy to understand, and complete and accurate in the information that they present.

This paper makes several assumptions about the reader:

• That he is an instructor of moderate to expert experience levels (perhaps, anyone with at least six months to a year of teaching).
• That he is developing courseware on a contract basis.
• That he is an expert in the subject matter for which he is developing and subsequently has a great deal of knowledge in most areas of the subject matter and at least some knowledge in every area of the subject matter.
• That he is developing courseware for a corporate, technical audience.
• That he is developing support materials for a primarily instructor-led, slide-based (or Powerpoint-based), class, as opposed to stand-alone workbooks or computer-based training.
• That he is developing in an environment with established procedures for producing well-laid-out and highly accurate courseware. This paper will not address the issues of layout design or accuracy.

If any of these assumptions are not true of you, this paper will still be useful, but you should consider how your situational differences affect your interpretation of the information herein.

As I stated in the previous section, this paper is intended primarily for a corporate audience. Academic readers may find that many of the assumptions made in the paper do not apply to them. The differences and similarities that I expect are:

• The instructor may be developing workbook or otherwise independent class materials, instead of slide-based, instructor-led class materials. In this case, information flow, as discussed in this paper, is doubly important, since the students will not have the benefit of an instructor to lead them through the material.
• The focus of the class will be weighted slightly more towards academic information as opposed to task-oriented information. While the ultimate goal of academia is the practical application of the knowledge taught, this seems to be of more concern in corporate settings. As such, the academic instructor may have slightly more leeway in adding interesting, but not directly relevant, information to the class. Fundamentally, the academic and the corporate instructor's job is the same: to facilitate learning.
• The Goal Task of the class should remain the same. While practical application of knowledge may be less important in academic settings than in corporate ones, it is still important that the developer have some specific task in mind. The difference, I think, is that the academic developer has more leeway in choosing the tasks, as they do not have to produce revenue.
• The academic instructor will probably not have to consider the "customer's" financial resources in the same sense that the corporate instructor will. The academic instructor's audience (students) does not set the budget for the class.
• Audience characterization is just as important, if not more so, in academic environments as in corporate ones. The academic instructor will probably be more able to determine the scope of the student's prior knowledge, due to standardized curricula.
• While academic instructors are not directly responsible to their students (especially in the case of tenured professors), I believe that a class can only be improved by considering the students as customers, regardless of the environment.
• The academic instructor will probably have little leeway in determining the class's Subject Domain.

Finally, I must qualify this information by saying that I have never taught in an academic environment (although I have been a student in one for five years). These are my expectations, but they are, at best, conjecture; please temper them with your own experience.

Although this document is about courseware development, the principles upon which it is based are those of planning and organization. In four years as a technical instructor, this is the place where I have most often seen courseware fall apart. Sometimes, slides (or even whole sections of the class) seem to have been dropped in almost at random, as if the developer said "Well, I've got to fit this information in somewhere, and it's vaguely related to that information, so I'll just put them in together!" Other times, the class's focus seems off (for example, completely irrelevant information may get ten slides, while really important stuff gets two). The end result is that the instructor is left with the responsibility of figuring out what's important and what's not. As a result, the instructor must rework his timing for each class because some scarce sections must be stretched out and other more verbose ones skimmed over; the instructor must figure out what the developer was thinking when a certain slide was put in in order to make a graceful transition at that point; and so on and so on. While this certainly gives the instructor a fine mental workout, the simple fact is that none of this is the instructor's job!

A corporate instructor's job is to facilitate learning so that students gain the ability to perform a certain task or tasks.

In other words, the instructor's job is to teach. Course materials should support this teaching effortlessly and transparently (no pun intended).

I believe that one touchstone of a set of class slides is whether or not an experienced instructor who has never seen the slides before can come in and teach the class to an empty classroom without stumbling or halting. Notice that I never said the instructor had to know anything about the subject he was teaching! That's how easily understandable good course materials should be an experienced instructor should be able to get all of the information needed to teach the class directly from the slides, present that information to the class, and have it make sense. This is the touchstone of information flow, or content organization. When course materials are this well designed, the instructor can spend all of his energy teaching/ helping the students learn. Any energy spent working around the slides is energy stolen from the learning process. Of course, information flow is not the only criteria by which courseware should be judged. A well-flowing course that presents completely inaccurate information is no better at teaching students to perform a task than a poorly designed, accurate one. As I said in the "assumptions" section, in this paper, I assume that accuracy is not an issue.

Content design is the key to achieving ideal information flow. Content design refers to the organization of the information in the presentation, independent of the way that the information is presented. It asks the questions "does this information fit in well here, or should it go somewhere else" and "in what order should I present these facts". It will be the focus of this paper.

In Situational Analysis, you gain a "feel" for the courseware you're about to develop and the classroom situation for which you'll be developing. A wonderful side-benefit of this step is that it gets your brain thinking about the problem before you actually begin producing the courseware. Your brain will start thinking about what information is involved in the class; you will start to mentally organize the information "in the background" as you go through these steps. You will find that this step sparks many ideas and associations that then seem to come out of nowhere during the actual writing. Situational Analysis should be the first step to any courseware development process.

Formulate a Goal

Before you do anything, you must first decide what you want the students to take away from the course. This is a critical step! Every decision you make from this point on will ultimately come down to "does it help me achieve my goal?" Therefore, before you continue, you must make absolutely sure that your goal for the class is well-defined and that it fulfills the expectations of the company or person for whom you are developing.

One mistake that courseware developers make during this step is deciding what they want the students to learn. Unfortunately, in the corporate environment, learning is just a side effect of the training process. Managers want employees to gain skills from a class, not knowledge. They want their employees to be able to do something that they weren't able to do, not know something that they didn't know. A manager doesn't care if her employee knows about Ethernet, she only cares if her employee is able to install Ethernet or troubleshoot Ethernet. The transmission of all the knowledge in the world is useless unless the employee gains the ability to perform his or her job more effectively. Therefore, your job as an instructor is not "to pass on knowledge," but "to facilitate the learning of skills."

With this in mind, it is critically important that you, as developer, have a crystal clear understanding of the class’s objective. To test your understanding, try to answer this question:

What do I want the students to be able to do?

The answer to this question is the class's Goal Task. A good answer should be correct, accurate, simple, concise, and (and this is often forgotten) realistic. If your answer is not all of these, if you find yourself stretching it out with qualifiers, or you simply can’t come up with a good answer, stop and get more feedback from the customer or your manager before you go on. If you can’t answer this question, or you aren’t sure your answer is right, you don’t understand the problem well enough to continue.

As a final note, when working collaboratively on a courseware design, it's critically important that all of the group members understand the Goal Task thoroughly. Miscommunications or misinterpretations of the Goal Task will produce an unfocused, unclear presentation.

Characterize the Problem

Characterize the problem of creating this courseware. In this step, you identify the constraints, both rigid (those which are fixed, and over which you have no control) and elastic (those which are flexible, and over which you may have some influence), on your development. You also identify pre-existing conditions in the class environment that can help you to teach more effectively. Answer questions such as:

• What technology exists in the class environment?
  Existing technology will affect the information you chose to include in the class. Students may already be familiar with a technology, for example, allowing you to exclude it or cover it less thoroughly. If the students have access to a particular tool that will aid them in accomplishing the course's goals, you may be able to include it in the class.
• What pre-existing procedures exist in the class environment?
  Often, we teach not only skills, but also potential new procedures. For example baselining is a skill, but a suggestion to students of regular baselining would entail a new corporate procedure. Knowledge of existing procedures allows you to tailor your class to them. On the other hand, if you know that they've already got a well-established, management-sponsored baselining procedure, you may decide to suggest improvements especially tactfully.
• What are the customer's financial resources?
  It won’t do you any good to put in a slide on the newest technology if you know they can’t possibly afford it. Instead, spend your time teaching them how to best utilize the tools they've got.
• What is my development time?
  Put simply, how soon do you need it? This will affect the urgency with which you approach the rest of the development process.

The answers to some questions, such as "what are my resources," will probably remain pretty much the same over different courseware development cycles. Although these questions are worth answering in the beginning of your development career, and should always be in the back of your mind, they deserve less attention as you gain experience with your development environment.

Characterize the Audience

Identify and characterize the audience to whom you will be teaching. Of course, you would teach differently to middle-level managers than you would to engineers, and your supporting courseware should tailored to your audience as well. Answer questions such as:

• What do I expect the students to know already?
  It's important to precisely identify the information that you expect the students to bring with them into the classroom. Anything they already know is one more thing you don't have to teach! However, be aware of the danger of optimistic assumptions. Although you shouldn't be expected to "teach down" to the dumbest class members, you should definitely err on the safe side when deciding whether to include or exclude information in the class/ assume they don’t know unless you’re sure they do. Remember, an instructor can always skim over a section if he's got an unusually bright class, but it’s awfully hard to improvise an excluded section convincingly. Not every instructor is as experienced as you are, remember the first time you had to explain something that had been omitted from the slides and how nerve-wracking that was? Even if the instructor does pull off the improvisation, he looks unprepared in the process. As a rule of thumb, if at least half the class doesn’t know something, you should include it in the course materials.
• What do the students actually know already?
  Now, go make sure that your answers to the previous question are consistent with reality. This is a hard question to answer completely. You'll probably rarely, if ever, have the luxury of interviewing potential class members before you begin development, but anything other than a face-to-face interview is probably sub-ideal. A manager's understanding of her employees' knowledge, even if completely accurate, is probably phrased in a very different language than the language you need as a developer. She understands the information as a manger, but you need to teach it as a techie, or a sales rep, or a customer support operator. In the end, you usually have to rely on your experience as an instructor. As you teach, you'll gain a feel for what information students usually do or do not have. This is one reason that I think that teaching experience is crucial to successful courseware development. If you’re not sure about a particular piece of information, other instructors and developers are probably your most valuable resource.
• What do my customers want from the class?
  In an ideal world, an instructor's job would be solely as stated above ("to facilitate the learning of a task"). In reality, an instructor can be everything from a technician to a customer relations specialist to (depending on the class) a kindergarten teacher! There are many objectives that must be met for an instructor to have completed his job successfully, and one of these is "make the students happy." Forget, for a moment, the psychological studies that show that students learn more when they're happy and entertained than when they're bored and frustrated. There is a much more basic issue here: if your students aren't happy, they won't give the class good reviews; if the class doesn't get good reviews, your company won't get hired again; if your company doesn't get hired again, it won't make money, and, well, you can see where this is going. But the students aren't the only ones you have to satisfy?remember, they're not the ones signing the checks! You also have to make management happy, and it's a safe bet that the manager who hired you wants different things from the class than the students who will take it. With all this in mind, how do you make the students and the manager happy? The same way you make anybody happy: give them what they want. But first, you have to figure out what they want.

Once you have decided what you want your students to be able to do and identified the constraints on how you will teach them, you must consider the knowledge required to support the task. This set of knowledge is known as the subject domain. In general, a class should contain a minimum of information outside of its subject domain. While a certain amount of trivia can keep a class interesting, it should probably be kept out of the main slides themselves and placed in student notes or somewhere else. It is important that the students be able to differentiate between required information, that is, information that directly supports the goal task, and ancillary information, that is, information that, while useful, is not directly related to the goal task.

Classify the Subject Domain

Determine what areas of knowledge are necessary to support the Goal Task stated earlier. As you do this, be as specific as possible; e.g. don't just say "Ethernet," say "The Ethernet Data Link, the OSI model, and the basics of multiport repeaters, bridges, and routers." Be aware that each individual knowledge area that makes up your subject domain is, itself, a subject domain, with other areas of knowledge underneath it. As you teach, you will pass on knowledge of these subject domains to your students.

It is also very likely that you won't think of everything that you need right now and will end up adding to the Subject Domain later on in the development process. This is normal, but keep in mind that adding new, necessary information is not the same as adding lots of extraneous information. As you arrange the information, resist the temptation to add information that is not part of the Subject Domain.

Arrangement Of Materials

Arrangement is the process of organizing the information that you gathered during Discovery and determining the best order in which to present it. Arrangement is critical to the students' understanding of "the big picture" of your Subject Domain. While students may learn rote repetition and facts without understanding "the big picture", they will never gain the deep insights necessary to make them excellent.

Arrangement's goal is to realize optimal information flow in the course materials. A document with optimal information flow presents ideas that flow naturally and logically, each one leading cleanly into the next. Here are some tips for achieving optimal information flow:

• Classify the information in the Subject Domain hierarchically. Separate the information by sub-subject domain into three or four levels of depth. Information in the same sub-subject domain should probably be presented together.
• Classify the information in the Subject Domain chronologically. Determine which information is foundation information (information that is primarily used as a basis for understanding other information) and which information depends upon the foundation information. Foundation information should always be presented before the information that depends upon it.
• As a corollary to the previous point, a document with optimal information flow minimizes forward references. Ideally, any term or concept that is presented to the audience is built upon concepts they have already seen. The instructor should never have to say "but I'll explain that to you in the next section" when defining a term or idea.
• Finally, there are many standard methods of arranging information, such as chronologically (the order in which things happen), most specific to least specific, etc..., which are beyond the scope of this document, but can be found in any textbook on Technical Communications.

Optimal information flow will allow your students to more easily understand the class's information and enhance their learning experience.

Conclusions

According to information theory, information cannot be conveyed if it cannot be understood. It follows from this that the more understandable something is, the more useful it is as a conveyor of its information content. A class's degree of understandability is largely a result of its information flow; if information flows logically, it will be better understood. Therefore, it behooves a conscientious courseware developer to ensure that the information in the class is as well thought-out and laid-out as possible.

By beginning with a thorough assessment of the class's criteria, the designer ensures understanding of the audience's needs and the factors that affect the class's implementation. By precisely determining the goal and subject domain of the class, the designer prevents extraneous information from obscuring its message. By properly arranging the layout of the class, the designer allows the students to receive its message as clearly as possible. All of this adds up to a more effective class and a more productive learning experience for the students.