14 Nov e-Learning Storyboard: Art or Science?
Christmas is fast approaching and I’ve been asked again this year to write a guest blog article for the E-Learning Network’s advent calendar of e-learning insights, advice and stories. I’m not sure what to write about this year but I thought I’d share my contribution from last year on ‘Storyboarding’. There’s a free storyboard template in it for you if you manage to get to the end!
The storyboard is the vehicle by which conventional e-learning gets done, but the storyboard is a much misunderstood thing both by those in the e-learning business and by customers. The problem is that everyone does storyboarding in a different way. Some even abandon the storyboard altogether in favour of the rapid prototype (more on this disruptive approach later).
One of the problems with the storyboard is that it has to perform so many functions throughout an e-learning development project. Here are some of its possible tasks:
- It acts as the scoping vehicle (have we included everything?)
- It may provide initial visuals for client review
- It determines the level of interactivity though the programme (and therefore determines the amount of effort required to build the end product)
- It provides the main review document for the client and the subject matter expert (SME)
- It contains all the final on-screen text or voice-over script for client review
- In may contain low resolution versions of all the photographs and images that will appear in the final programme.
- It is used as the key briefing document for the development team.
Clearly this is a big ask for one document. And to make matters worse the audiences are so completely different – the client who is paying, the SME who is looking for accuracy, the project management team who are assessing effort and the development team who are looking for a clear brief on how it should be built. Of course in many cases the storyboard is supported by additional documents but these are often left by the wayside as the client focuses on the tangible visual feel of the storyboard.
So we recognise that the storyboard has to achieve a lot so how should it look to achieve this massive task?
The Visual Storyboard
I’ve worked on a vast number of e-learning projects over the years and either though experiment or dictate (my client has forced me to use their in-house approach) I have tried a broad range of approaches. As a visual person (aren’t most instructional designers visual) I favour the visually rich storyboard built in PowerPoint (or any other graphics and layout friendly software).
Now, just because I use PowerPoint does not mean that the storyboard should look like a PowerPoint presentation. PowerPoint provides us with a blank canvas – what we put onto that blank canvas is limited only by our imagination (and the imagination of those who we work with).
Having opted for the visually rich approach there are two possible avenues open to us. We can adopt a realist approach or we can adopt a sketchy approach. The realists use actual photographs , proper fonts and smart layouts. Sometimes these storyboards looks almost like the finished thing. If you are developing with a rapid tool such as Articulate or Adobe e-Learning Studio they probably will be the finished thing. The sketchers on the other hand use rough layouts, basic outlines, silhouettes and often placeholders for images and graphics.
Which would you prefer to review as a client? It’s a tough call – some clients get the sketchy approach – they recognise that it is the first step and can see how it can be developed towards the final product.
For me it isn’t a simple choice between one or the other. It depends on your natural way of working as an instructional designer, and on the preference of the client (and indeed the rest of the development team). I prefer to start with the sketchy approach since this lets me work quickly and focus on the learning and the learning interactions rather than the look and feel. One of the strengths of this approach is that it also provides more scope for the designers to add their magic. However in some cases this approach can come unstuck – some e-learning companies operate a production line and the last thing they want is too much autonomy on the part of the designer.
Sometimes I will build an early sketchy draft – review this with the development team and the client – then translate it to a more realistic version before it is signed off for build.
The Script Storyboard
But what if you (or your client) doesn’t do the visual approach at all? Well the most popular alternative is the straightforward written script. This is a much more word focussed approach – think Tolstoy or Dickens rather than Picasso or Monet. This approach is favoured by some clients because it keeps more obviously to the message – which is often more simply conveyed in words than images. Images are interpretations and these can be subjective.
These script storyboards are usually developed in a word processor and they therefore get the benefit of all that fancy review and mark-up functionality that exists in a product like Word. As they are purposely light on imagery and layout these scripts will often contain lots of ‘described interactions’ (the instructional designer describing a learning interaction rather than actually visualising it).
Some clients do seem to feel more comfortable with this script based approach but transforming the script into an engaging visual e-learning experience can be a real challenge – there simply isn’t enough visualisation done to make the job of the designer and developer straightforward. Usually they need considerably more input at the briefing stage.
No-Storyboard at All
Finally we have the ‘no storyboard’ approach. How does this work? Well it’s hard to describe but it requires a degree of collaboration and insight that aren’t quite so important using the conventional approaches. The concept behind the no-storyboard or rapid prototype approach is that all clients really want to see is the final thing – and if we can show them what that looks like really early on then we can dispense with storyboards altogether.
This is a good concept but it has some problems. We still need some way to capture all the content, and the designers and developers still need input from the instructional designer so in practice there is often still a rudimentary storyboard – it’s just that it’s not seen or reviewed by the client but becomes an internal design document only.
This approach actually works for me – I’m a big fan of building something quickly and showing the client quickly (warts and all) but it can be tough to implement in a conventional production environment – things are continually oscillating between the instructional designer and the build team and this can seriously mess-up the project schedule. However time lost at this prototyping stage is usually regained again at client review. Usually the client is much more satisfied with the end product earlier in the development cycle and there are therefore less costly changes towards the end of the build.
Which Approach is Best?
So which approach works best? Well there are of course strengths and weaknesses for all three but here is a guide to help:
Use a visual storyboard when:
- The client gets visuals
- You are using a rapid development tool
- You need to work quickly
- You are planning lots of learning interactions
- You are developing a new course template
Use a script storyboard when:
- The client is precious about the words the SME has provided
- When proofing the message and the text is critical (e.g. for regulatory purposes)
- When you are working with a law firm (seriously)
- You are simply working to a pre-defined course template
Use no storyboard when:
- The client is completely naive when it comes to e-learning
- When you are attempting something unconventional such as a game or complex scenario
- You are experimenting with your design and development team (trying new learning interactions or a new player for example).
Clearly as instructional designers we all have our favoured way of working but it’s also critical that we work in a way that is transparent for both the customer, the SME and the development team.
It’s important to recognise that the storyboard is only a representation of the final product. Early on it may look a bit rubbish but as the team works towards the final goal it will crystallise the thinking and the design. Imagine the storyboard as the rough underpainting of that final masterpiece. One day our storyboards may even become valuable in their own right!
What works best for you? Are you a no-storyboard fan or would life be hell without it?
In the spirit of Christmas, I’ve attached a Visual Storyboard Template for you to use/modify as appropriate.