Buzzword Decoder: Iterative Design and Development

“No eLearning application is perfect.” This bold statementforms one of the three “fundamental thoughts” underlying Michael Allen’sSuccessive Approximation Model of eLearning design and development, SAM,presented in the second edition of MichaelAllen’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 stepwe take will get us significantly closer,” Allen writes.

The iterative design process

Iterative design—successive approximation, rapidprototyping, agile software development, whatever jargon-ey name you giveit—puts a version of an actual eLearning product in front of actual learners.Multiple versions, in fact, as eLearning development progresses. Thisillustrates the other two “fundamental thoughts”: 1) A functional prototype isbetter 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 producttest each prototype and provide feedback, thus preventing the costly error ofcarefully 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 toincremental development, where a team builds a product in small increments.Each incremental release is tested by users; their feedback guides the nextdesign and development cycle. But each incremental piece—user interface, searchfunction, learners’ selection and design of game avatars—is regarded ascomplete when it is given to users for testing. The pieces will ultimately beassembled into a working whole.

While an incremental development process releases pieces ofa complete product, in an iterative model, each incremental release is an iterationor “complete” working prototype. That is, rather than asking users to test theuser 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 becomplete 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 toplay the game. Enough of the final functionality will be present that learnerscan critique it and provide meaningful feedback that allows significantchanges, 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 agilesoftware development, which is often used in eLearning design and which can beboth iterative and incremental. Agile developers expect that requirements willchange as users are exposed to working prototypes, and they are prepared tomake changes in the design during development.

The challenge of dealing with perfection

A drawback to iterative design is that it can be hard fordevelopers to know when they are done. Remember Allen’s fundamental: TheeLearning will never be perfect. Therefore, a development team can alwayscreate “just one more”—better—iteration. Each iteration is a complete product.Complete but imperfect. In contrast, an incremental product is done when all ofthe 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 iterationsthey will create. Allen suggests three: an alpha, a beta, and a “gold” or finalrelease. Teams may choose another number, but the trick is to limit the numberof iterations and plan for staged development. An alternative is to fix atimeline with a firm release date. The number of iterations in the timeavailable can vary or be undefined, so long as the team progresses steadilytoward a complete product that will be ready on the release date.