“No eLearning application is perfect.” This bold statement forms one of the three “fundamental thoughts” underlying Michael Allen’s Successive Approximation Model of eLearning design and development, SAM, presented in the second edition of Michael Allen’s Guide to e-Learning. A strength of iterative processes like SAM is: “We will never get to perfection, but this process will ensure that each step we take will get us significantly closer,” Allen writes.
The iterative design process
Iterative design—successive approximation, rapid prototyping, agile software development, whatever jargon-ey name you give it—puts a version of an actual eLearning product in front of actual learners. Multiple versions, in fact, as eLearning development progresses. This illustrates the other two “fundamental thoughts”: 1) A functional prototype is better than a specification document or a storyboard for user testing, and 2) “disposable, quick, and dirty prototypes are beautiful,” Allen writes.
Actual learners who will use the finished eLearning product test each prototype and provide feedback, thus preventing the costly error of carefully designing and developing and polishing a single “perfect” release—only to have it fail spectacularly when it is handed over to the learners.
Iterative design vs. incremental development
Iterative design and development is closely related to incremental development, where a team builds a product in small increments. Each incremental release is tested by users; their feedback guides the next design and development cycle. But each incremental piece—user interface, search function, learners’ selection and design of game avatars—is regarded as complete when it is given to users for testing. The pieces will ultimately be assembled into a working whole.
While an incremental development process releases pieces of a complete product, in an iterative model, each incremental release is an iteration or “complete” working prototype. That is, rather than asking users to test the user interface before giving them the first level of an eLearning game to try, an initial prototype will actually be a working game. The graphics might not be complete or polished, search or leveling-up abilities might be very limited, and only a small part of the content will be there, but testers will be able to play the game. Enough of the final functionality will be present that learners can critique it and provide meaningful feedback that allows significant changes, if needed, in the design—before the final product is developed.
The agile approach: Feedback early and often
Early and continuous feedback is a hallmark of agile software development, which is often used in eLearning design and which can be both iterative and incremental. Agile developers expect that requirements will change as users are exposed to working prototypes, and they are prepared to make changes in the design during development.
The challenge of dealing with perfection
A drawback to iterative design is that it can be hard for developers to know when they are done. Remember Allen’s fundamental: The eLearning will never be perfect. Therefore, a development team can always create “just one more”—better—iteration. Each iteration is a complete product. Complete but imperfect. In contrast, an incremental product is done when all of the pieces, created separately, are hammered together into a unified product.
What’s the solution? When using an iterative process, developers and designers should stipulate at the outset how many iterations they will create. Allen suggests three: an alpha, a beta, and a “gold” or final release. Teams may choose another number, but the trick is to limit the number of iterations and plan for staged development. An alternative is to fix a timeline with a firm release date. The number of iterations in the time available can vary or be undefined, so long as the team progresses steadily toward a complete product that will be ready on the release date.