Rapid Prototyping

An interesting article on Rapid Prototyping. Not totally convinced about the fully iterative approach for us, but completely agree with the need to place more emphasis on Prototypes and in getting them out sooner.

-------------------------------------------------------------------

Michael promoted the ADDIE development approach (analyse, design, develop, implement, evaluate). ADDIE was adopted wholesale by much of the e-learning industry. If you have ever received a proposal from a custom E-learning developer it probably had a project path which went along the lines of:

Analysis > sign off > design document > sign off > storyboard > sign off > script > sign off > in blood > now you can see what it actually feels like in the alpha > too late for changes, remember you signed off > etc.

It’s a very linear model that has its roots in traditional software development. Nice, safe, reassuring – and totally unsuitable for e-learning at today’s pace. ADDIE, you're a baddie...

It’s been around for a long time now, and we’ve spoken in the past about the need for an overhaul. We’re not alone. Jay Cross has been vocal in his criticism of this approach and “the fiction that design takes place in discrete steps.”

In his book “Creating Successful E-learning” Michael recognises the limitations of the linear ADDIE model. He points out that its application has led to lots of problems in e-learning:

“Boring e-learning results from using outdated processes that focus on content presentation, accuracy and comprehensiveness, processes that rely too much on up-front analysis, not providing stakeholders with an effective way of being involved.”

The key criticism comes back to the focus on a linear sign off process which limits design and creativity, and it just not reflective of real life:

“Specification documents and storyboards are ineffective ways of creating, communicating and evaluating design alternatives”

“Poor designs get pushed through the process and are not recognised until too late”

“The need to redesign as better ideas are discovered is considered a fault (and one the client should pay for), rather than part of the process”

There’s too much of a focus on one part of the issue, another part of the issue, all in micro-steps, and it’s not until very late in the design process that you can pull back to see if you’ve guessed what it is yet. By then it’s often too late to make changes, or at least not without costs. The first sense of how the design actually works and will feel to users and stakeholders should be much, much earlier in the process.

In Michael’s view, Rapid E-learning gives you a chance to accelerate the first version. He recommends an approach which involves rapid prototyping from the beginning of the process, to get to a first working version quickly, that you then iterate until it’s ready for release. He calls it successive approximation, neatly aligned to the Wikipedia model in that there’s no ‘final version’; things just get incrementally better with each update.

Unlike design specifications that are rooted in documentation, rapid prototypes:

• Are fun!
• Shorten the process
• Improve information sharing
• Help people talk more constructively - everyone has a view on a prototype
• Lead to more creative designs