CHAPTER 14

Creating the Design Proof

When the objectives x treatments matrix is completed, the development team can begin its work to build the final product. Of note is that the process doesn't change radically from earlier phases and tasks. Quite the contrary, it continues almost unchanged.

Iterations continue, but now the work builds on accepted and approved designs. Instead of designing learning events, the iterative cycles create and implement content in the framework provided by the designs. Instead of disposable prototypes, iterations produce a series of approximations to the final product: design proof, alpha release, beta release, and finally the final or “gold” release. Iteration One produces the design proof. It is a final check on the design direction before undertaking development of all content in subsequent iterations. Iteration Two produces the alpha release candidate, and Iteration Three produces the beta release candidate. If the beta release has no unacceptable flaws, it becomes the final product. If it has problems, another beta release is produced. The process continues until a beta release is accepted for rollout—the gold release.

AVOIDING THE BEST IDEA

It would make everything so much easier if all the best ideas surfaced at the start of a project. Unfortunately, great ideas are unruly and disobedient. They fail to arrive when beckoned, vanish just when you need them most, and speak up when you wish they'd be silent. Everybody likes a good idea, but there are times when they're just short of painful. A lot of work has been done and you're almost finished, and then…and then, the idea pounces. Here's what we really should have done! Oh, no.

There's a reason good ideas arrive late: They're predicated on and born of all the foundational thinking that's been done to define the questions. What really needs to be done? What do learners really need to do? How can we best motivate learning? Reviewing candidate solutions would seem to focus one on detailed attributes of the solutions, and it does, but it also focuses attention on the problem and ultimately reveals a better understanding of it. As solutions become more complete, they reveal the more hidden nuances of the problem and additional needs. And that's when the best solution occurs. Right?

No.

It seems there's always a better solution lying in wait. Implement that best solution and just as it's about nailed, You know what? Here's what we really should do!

It's important not only for sanity, but also for delivering on time and budget, to avoid thinking there's a perfect solution in reach. One of those unruly, disobedient great ideas is always lying in wait. Always. The best advice: Follow the successive approximation process, iterate a controlled number of times, and produce a successful product. After some time in the field, it may be appropriate to iterate a bit more. That can be done with the benefit of performance data and feedback. But trying for perfection is always a doomed agenda.

Better ideas fail to arrive when beckoned, vanish just when you need them most, and speak up when you wish they'd be silent.

THE DESIGN PROOF

The design proof is the output of the first development cycle. It's something of a bridge between design and development. Remember that SAM2, the process we're detailing here, is for larger projects where there's a need to more formally separate design and development. In SAM1 we continue to keep design and development interleaved until a final product emerges.

The design proof begins the iterative development cycle and offers a critical opportunity to view all the designed components of the instructional product integrated with each other. This is the time to confirm design decisions. Most specifically, this is the time to check whether expectations are being met, that the approach will work as a whole, and if there are any problems with the design.

Important: Confirmation is accomplished with an intentionally incomplete version that brings all pieces of the design together for the first time. Content and media development are limited so that minimal effort will be required for a change of direction, if necessary, but representative media are finally in place and very much open for assessment.

The design proof contains the following:

• All structural components are present and functional, including at least one instructional event of every type designed for the product.
• Sample graphics and other media are included in final resolution, but placeholders remain for the majority of instances.
• Sample content is included for each major content area and is complete for at least one instance of each different instructional treatment. Otherwise, placeholders will be used.
• Navigation and interactivity structures collect sample performance data sufficient to test data collection and interconnectivity to external data files and LMS as appropriate.
• Instructor's Guide and notes, as appropriate, allow an instructor not part of the design and development team to actually conduct a class, section, or instructional event.

Less Is Faster

While it's very important to confirm the effectiveness of the design, spending too much time on the design proof can be counterproductive. Sample interactions should effectively demonstrate a complete learning activity, but many components can be mockups, simulated, or duplicated to reduce development time needed for proofing the design. Developers need to make a judgment call on what items are critical to effectively demonstrate each design feature or activity. But at least one finished component of every type intended to be used should be included.

For example, in e-learning, the code to create the logic behind an elaborate branching learning event requires considerable development time. However, sufficient effect of this activity can easily be revealed with some of the learner's choices inactive. It is more important for evaluators to see the flow of the activity, rather than every path that will be available in the final product.

The design proof is the time to pause and look at the course as a whole. This is a major transitional step between the initial design and the alpha release. It's likely that when everything comes together as it does in the design proof, it will invite some redesign. This is expected and should not be considered a fault of the design. Until all components are present and integrated, the learner's experience could only be imagined. When it becomes real, some problems and some opportunities are very likely to emerge. Perhaps a small change here or there will make a powerful learning experience come to life that was otherwise just under the surface.

Iteration in SAM, including even the development phase, makes discovering problems and opportunities happen as early as possible. Such discovery is invaluable, but it also carries the risk of being in revision mode perpetually.

Changes should definitely be made where problems exist and affordable opportunities are discovered, but the temptation to make radical revisions usually must be resisted. This is not just because of time and budget limitations—although those constraints may well be enough to prohibit major changes—but realizing that if major rework is allowed this time, it will be just as attractive again in the next round. It's almost always better to get a product in use, gain feedback, and then consider further refinements.

WRITING COURSE CONTENT

Design prototypes create a broad foundation on which to begin writing the course content. Even though we hope some exciting learning events have been designed, the course content—more than the number or type of events—will prove to be the most challenging work. Except for small courses, content development requires a structured and systematic approach.

At the start of the development cycles, the expected content is typically conveyed in a variety of ways, including elements of the prototypes, outlines, bulleted lists, references to documents, videos, and so on. The development team must now begin assembling or creating text, graphics, audio, video, and whatever other content is required.

The process of creating course content begins with the development of content grids—documents used to structure the context, challenges, activities, and feedback. The grids provide a method for writing, reviewing, and revising content. There will be a content grid for each learning event or each interaction. Figure 14-1 provides a content grid template.

Figure 14-1. Content Grid Template

To populate the grids for each topic and learning event, the team writes questions for the subject matter experts so they can provide the specific information needed. For example, if a learning event targets effective conversations between salespeople and customers, some content-gathering questions might be:

• What are the methods you want your salespeople to use when communicating with customers?
• What are some exemplary conversations salespeople might have with customers?
• What are the most common complaints of customers?
• What are the appropriate responses for each customer complaint?
• What mistakes do salespeople make in responding to each customer complaint?
• What are the likely outcomes of each mistake?
• Can mistakes be corrected? If so, how?
• What options do salespeople have to address customer issues?
• How do salespeople currently address customer complaints?
• What information or resources can salespeople access?

Identifying what salespeople and customers discuss, how they communicate, appropriate communication strategies, and resources available to salespeople, provides a realistic launch point for writing course content. Figure 14-2 shows an example content grid.

Figure 14-2. Example Content Grid: Identifying Road Construction Safety Hazards

Figure 14-3. e-Learning Produced From Content Grid in Figure 14-2

The content grid example shown in Figure 14-2 resulted in an interactive screen shown here in Figure 14-3. You can play much of the interactivity in your head by looking at this screen capture and reading through the content grid.