Experiences so far with ‘not storyboarding’
eLearning storyboards are not an agile way of working
One of the principles of agile project management is the aim to reduce the amount of documentation and to focus on building a working product. Storyboards are not an agile way of working. They require a whole lot of documentation and planning before you can build a working version of your digital learning project. The reason to focus on a working product instead of documentation is that so often just planning doesn't lead to a product that meets the actual learners' needs and business outcomes.
The Successive Approximation Model (SAM) process from Allen Interactions is based on applying agile project management to learning projects. One of the main focuses of SAM is ‘not storyboarding’, and instructional designers instead working directly with development software. Recently we have been trialling not storyboarding at Sprout Labs.
Because of the scale of the projects we do (our average project size is 20 modules) we have a ‘traditional’ approach to development. Instructional designers focus on storyboards, and graphic designers and developers do the build process after the storyboards have been approved by the client. Often the designer's work is specialised as well; some of them are focused on the interface, some on the illustrations. The challenges of storyboarding are different if you're a lone instructional designer doing the educational design, visual design and also the development.
The great debate: Who is the audience for a storyboard?
This approach of splitting work into different specialisations leads to one of the great debates at Sprout Labs: who is the audience for a storyboard? Is it the subject matter experts or the reviewer, or the visual designers and developers? My personal opinion is that the storyboard is for everyone. But storyboards are often confusing for reviewers and subject matter experts alike. At this stage, when we began experimenting with not storyboarding, I did the podcast with Anna Sabramowicz on ‘What needs to be done before you start a storyboard'. She talked about the approach they used, where the storyboard for the reviewer is different to the one for the developers. The former is more content focused, and they add developer notes after the review process.
The experiment with not storyboarding
Recently when I've been doing instructional design work on smaller projects I've started to work directly in Glasshouse, our cloud-based authoring system.
Some of the advantages we have seen from directly in Glasshouse are:
- The instructional designer can quickly see if an activity is going to work or not.
- The subject matter experts and reviewers can actually explore the interactive activities, instead of just reading descriptions of them in the storyboard.
- I have to write fewer instructions to the designers.
- The designers don't have to spend time copying and pasting content from a storyboard into Glasshouse. They can focus more on just doing the design work.
Glasshouse has a built-in commenting feature which in many ways makes the process of reviewing easier.
- The only real disadvantage is that it's a slower process for the instructional designer. I know Glasshouse extremely well, but I still found it more complex than just working in a Word document.
Overall, the advantage outweigh the disadvantages, especially on smaller projects. We haven't tried the process yet with a larger project.
What I learned – visual planning tools
During these experiments, what I’m reminded about is that storyboarding is the outcome of a process of analysis and planning. It's not actually a tool for planning a learning experience. The actual planning of the learning sequence and the learning activities is best done with tools like mind maps, sticky notes and paper that can be rapidly changed, and is visual and collaborative. Digital learning projects often don't go well because of a lack of planning, but doing a storyboard doesn't guarantee that the planning is focused on the process of learning. With the first project in which I didn't write a storyboard we ran a collaborative design workshop with the clients, where we mapped out the module on paper. This is when the instructional design work was really being done.