Storyboards are a common deliverable for elearning projects - but don’t get caught up obsessing over the means rather than the end.
What is a storyboard?
Storyboards are a series of static illustrations used as a proxy for demonstrating a more complex medium such as film, or in our case, an elearning piece. Simple pictures stand in for what happens on screen. A good storyboard will help you to figure out the flow of your piece, and whether anything is missing.
What are storyboards for?
Storyboards are a planning tool. They help you determine if your story makes sense. Are you introducting topics and ideas in a logical order? Does your arrangement of topics flow naturally from one idea to the next, or are there awkward gaps forcing the learner into impossible leaps of logic? Visualising your ideas in such a tangible way leads to rapid improvement. Design problems can be solved by adding, removing, or rearranging the screens. Because it’s all on paper, it’s fast and cheap.
Learning designers need to be able to share their ideas to get feedback. Storyboards provide an easy format to demonstrate an idea, and just as importantly, are unintimidating for others to suggest changes or additions.
Low Resolution
Initial storyboards should be low resolution. Only include enough detail to get the bones of the idea across.
Adding lots of detail too early in the process makes storyboards worse, not better. The first problem is the additional time it takes to produce the storyboards. Additional polish and refinement certainly makes your storyboards look nicer, but are they getting your idea across any better than a simple line drawing? Probably not - so don’t waste the time. Storyboards exist only to help you along the way to a finished product, they’re not the actual product. Don’t overinvest in them with unnecessary detail.
The second problem is that all of that additional flourish and detail can distract the people who need to help you. Rather than being able to focus on the ideas you are presenting, the details become a distraction. You get sucked into debates about colour, typography, and specifics of images. All of that is important, but it’s not important right now. It’s not the job of the storyboard to help make decisions on anything other than the flow of your story. Only include enough detail to present your ideas, and that’s all you will get feedback on. Don’t give your well-meaning review team the opportunity to get distracted.
High Resolution
I’ve seen plenty of examples of elearning storyboards, and plenty of them are what I would describe as “high resolution”. They often include full colour graphics, artwork that would be very close to the finished product (if approved), and line by line breakdowns of scripts. They are trying to be a non-functional version of the finished product, and you can tell a huge amount of work has gone into producing them.
I get that both clients and learning designers want to be confident about what the finished product will be, and we’d love to get that confidence as soon as possible. No one wants to be build or be given a finished product that’s not quite right and have to either do over, or live with something subpar. Review and feedback is an important process, and I’m a huge advocate for lots of both as early and often as possible. Here’s the the thing though - those great looking documents are giving you false confidence. You’re no closer to seeing an actual finished product. The learning piece still has to be built from scratch.
I’m hardly the first person to riff on this. Jason Fried of Basecamp (formally 37Signals) has written on these exact ideas in relation to UI design for web applications. As elearning designers, UI for web applications is a huge part of our work whether we think of it in those terms or not. In 2006, Jason published “Getting Real”, and later released the book for free on the web. The included essay “Ignore Details Early On” is a consise reminder to focus on what matters, when it matters.
In a post to Signal vs. Noise in 2008, Jason describes their UI design process, specially “Why we skip Photoshop”. He lists a number of reasons why building static mockups of an interface isn’t useful, compared to building a working prototype. It’s a quick read, and worth taking a look at. My summary though is that it’s a waste of time to do what is essentially the same work twice - once for the mockup/storyboard and once to make the actual product.
A final reminder - I am definitely not suggesting that clients and/or stakeholders should have no input between seeing the rough storyboards and your delivery of the finished piece. Your stakeholders need to provide input and signoff in the design phase - but if you’re showing visuals, show an in-progress version of what will be the finished product.
Storyboards are a tool to road test your ideas and story. Don’t get bogged down in the details - that’s a job for a different tool and time.
