The elearning Storyboard

storyboard

The elearning Storyboard

The storyboard is the vehicle by which conventional elearning gets done, but the storyboard is a much-misunderstood thing both by those in the elearning 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 elearning 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 through the programme.
  • It provides the main review document for the client and the subject matter expert (SME).
  • It contains the final on-screen text or voice-over script for client review.
  • In may contain low-resolution versions of the photographs and images.
  • 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 the storyboard is usually supported by additional project 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 critical task?

The visual storyboard

I’ve worked on a vast number of elearning projects over the years and either through 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 or layout friendly software).

However, 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.

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 look almost like the finished thing. If you are developing with a tool such as Articulate Storyline or Adobe Captivate 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 provides more scope for the designers to add their magic. However, in some cases this approach can come unstuck – some elearning 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 (I call it a rough storyboard) – and review this with the development team and the client before starting on the full version. This suits an agile approach and can avoid mismatched expectations further down the line.

example of a visual storyboard

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-focused 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 succinctly (if tediously) conveyed in words than images. Images are interpretations and these can be subjective.

These script storyboards are usually developed in word processing apps and therefore get the benefit of all that cool review and mark-up functionality that exists in a product like Microsoft 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 elearning 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.

script storyboard

No-storyboard at all

Finally, we have the ‘no storyboard’ approach. How does this work? The idea behind the no-storyboard or rapid prototype approach is that clients, especially those new to learning, are poor at visualising how a storyboard is brought to life in the selected authoring tool. What clients really want to see is the final thing as soon as possible – and if we can show them what that looks like 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.

Building something quickly and showing the client quickly (warts and all) can work really well and reduce risk of mismatched expectations 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.

The no-storyboard approach can also be very efficient when developing microlearning courses, for example in a tool like Articulate Rise. I can build an entire draft course in Rise for the same time it would be to storyboard in PowerPoint. That’s a really efficient way of working but it does need a flexible client who is onboard with the lean approach.

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
  • You are developing short microlearning modules (less that 10 mins)
  • 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 course 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 basic 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. Or the blueprint for that Grand Design.

What works best for you? Are you a no-storyboard fan or would life be hell without the storyboard?

I’ve attached a Visual Storyboard Template for you to use/modify as appropriate.

Example storyboard template (in PowerPoint)

Share on Social Media
No Comments

Sorry, the comment form is closed at this time.