Design problems are typically complex, “ill-structured” and can only be well understood through exploration. As a result, there are many subtle, but critical questions about these problems that only learners themselves can answer. The trick lies in finding how to find what the questions are, and how to ask them.

Discussion

Most learning problems that are worth solving well are typical of design problems in general. They cannot be solved by any one area of expertise (learning design, interface design, technology etc.), there are many possible good solutions and the process of getting to these solutions is often unclear.

The people who, at some level, know the problem best are, of course, learners. The phrase “at some level” is important: learners are unlikely to be able to articulate some of the more subtle aspects of the problems they face, or their views of the solutions. Exactly what tone of voice, the learning strategy and methods that may be effective, how they might use a learning resource, how long for, when and where, and many other issues may be known only unconsciously and be difficult to express. Asking direct questions – even if they are the right ones to ask – can often result in responses that do not reflect the reality of what learners need, how they act and particularly how they feel about particular issues.

What learners often need in order to make effective contributions to the design debate is some form of representation of a solution (or its parts) that they can comment on, play with and explore. Text documents are usually too abstract: describing what may be a complex and unfamiliar experience in words – even with a wireframes and diagrams included – is unlikely to engage with learners or elicit their views. Representations such as flow charts, pace [state?] charts and mood boards are all useful, but the most effective technique is to use a series of prototypes.

The application of prototyping in some design environments – particularly in the e-learning industry – does not make best use of prototyping. Prototypes are generally used as a client-approval device or technical testing environment, rather than as a means to contribute to the ongoing design debate. In other words, they are used as a convergent device, to close off the debate, when they should be used as a divergent device, to open it up, and generate ideas.

Recommendations

Various writers and commentators, notably David Kelley, of design consultancy IDEO, have argued that innovative design organisations need to move from being specification driven cultures to prototype driven cultures. The IT industry as a whole has a poor record in terms of its ability to produce effective, comprehensible specifications that lead to useful completed products. Part of the explanation, according to Michael Schrage, a writer and expert on prototyping, is that it is far easier for people to articulate what they want by playing with prototypes than by enumerating requirements in a documented form.

But using prototypes in this way challenges a number practices common in the e-learning industry. Using prototypes to drive the design process, and get learners involved in resolving design problems means:

Expanding on some of the key points here:

• The use of prototypes in e-learning tends to be not only too late but too shallow. That is, the issues dealt with through prototype testing tend to cover interface and aesthetic issues, but leave the fundamental learning strategy untouched – unless the learner reaction is extremely negative. But used earlier in the process, a prototype may elicit from learner behaviour or comments a different, better learning strategy than the design team had in mind.
• Regarding prototypes as means of driving design discussions has considerable benefits in terms of generating shared mental models of the problem and the solution amongst the whole design team – which includes the client. It is also likely to facilitate the development of a common vocabulary and terminology amongst the team, reducing misunderstandings and errors later in the process.
• The “prototyping medium” – the tools used to produce prototypes – need to be carefully selected to support the process. Early in the process, simple paper sketches of screens, characters, interactions and tools are likely to suffice – as long as they are not too professionally finished. Later, as design solutions mature, the designer (or builder) should use technical tools that allow them to build working systems that respond to learners’ ideas and suggestions in close to real time. If these connect with the development team’s existing template sets, all the better. The key point here is that in order to be learner-driven, (not production-driven), it may be necessary to both discard early prototypes, and delay significant technology decisions until relatively late in the process.
• Basing a design process around prototypes rather than specifications requires a greater degree of trust, and an acceptance of constructive, professional mess; what Schrage calls “playing seriously with uncertainty”. This trust must be based on the assumption that the quality and effectiveness of the final product will be significantly better, (and incidentally, according to Flow Interactive the product will probably be completed closer to time and budget as well).