Online learning experiences are becoming less like publications and more like applications; (there’s an interesting representation of this here, developed by user experience expert, J. Garrett). And learning solutions that use technology are becoming more closely integrated with those that don’t. Given both these trends, it can be difficult for a learning designer to get a feel for the structure and flow of the learning resources they’re designing. They need to have a clear mental image of the experience so that they and their team can explore the structure and flow, and make iterative improvements. (See Debate with your design).
When an interior designer is developing a concept for a retail space, they spend considerable time understanding the “customer journey” through the space. They map out where the customer will enter the shop, the possible routes through it and the various experiences and interactions that will occur. They do this because they understand that the cumulative experience of being in the shop, the total journey, is what will affect the customer, not the individual components.
In many cases, learning designers need to do the same. They need to represent the learning experience as a journey, so that they can design the experience to maximise the probability that appropriate parts of that journey will support learning. This representation needs to take into account not only the learning resource currently being designed, but its environment: the portal or learning management system through which it was entered; even the office, home or other environment in which the learning is taking place. It should include the initial stimulus that got them started on the journey in the first place.
There’s also a problem with more complex learning experiences that the various members of the design and development team (and clients are included in this) need to share a common mental model of what is being designed, even though their professional backgrounds may militate against this. Graphic designers, technical developers, clients, project managers and learning designers often approach a problem from different starting points and have different priorities. The aim is not to get the team to share the same opinion – they rarely will. It’s about ensuring that there is a level of common understanding so that different perspectives drive innovation rather than cause frustration and re-work. Text descriptions are generally less effective for this purpose.
Clearly, the best form of representation of a learner journey is some kind of flow chart. However, it’s what goes in the flow chart that counts.
Technical developers are trained to produce highly detailed functional flow charts, often using methods such as UML (Unified Modelling Language). These can be an important component of the development process, and it is often thought that these can provide a good representation of what will be designed. But such functional flowcharts cannot represent the learner journey or the learner perspective. An effective learner experience flow chart:
- represents the main events that the learner is involved in: deciding they need to learn something, logging on, starting the course, making key decisions, undertaking some off-screen activity and so on; learner experience flow charts do not get bogged down in detail;
- indicates what the learner will see, hear, feel and do at each key point, such as “sort the required customers into the correct order”;
- gives a taste of what the learner might be thinking, saying or feeling at each point, such as “I wonder which order these customers go in...”;
- conveys some sense of the overall flow of the narrative or drama – if there is one, for example “...the learner sees the disaster that ensues if they choose the wrong customers”;
- gives a taste of key interface elements or interaction types, often in an iconised form; they can be quite visual, resembling the kinds of storyboards used by advertising creatives.
The level of detail to which the learner journey should be represented varies according to the needs of the designer, the design team and the project itself. For example:
- If familiar templates exist for particular sub-components of the learning resource it may not be necessary to produce a representation of what goes on in them
- In producing a complex, multiple-path simulation it is likely that flow-charting will be needed down to a low level of detail
1. Rough post-it version
Open discussion, playing with ideas as to the rough sequence of events
2. Key parts of the post-it version are worked up
Examination of key parts to assess their validity
3. Single high-level flow chart is produced
A first high-level view of the whole journey
4. Detailed, sectional flow chart
A lower-level, learner perspective view of the whole journey.