Ask anyone who has run an eLearning project what went wrong, and you will rarely hear that the development was bad. You will hear that the content kept changing, that reviewers disagreed with each other, or that something obvious was spotted far too late. Almost all of that traces back to one document.
A storyboard is the full blueprint of a course – every screen, its text, its narration, its media, and its interactions – written and approved before any development begins. It is the last point in a project where changing your mind is nearly free.
Why does the storyboard matter so much?
Changing a line of text in a storyboard takes a minute. Changing the same line after the course is built means editing the slide, re-recording the narration, re-syncing the animation, re-testing the screen, and doing all of it again in every language the course has been translated into.
The cost of a change rises sharply at every stage. The storyboard is the cheapest place to argue about wording, to discover that Legal wants a disclaimer, or to realise the scenario does not reflect how the job is actually done. That is why serious projects do not start building until it is signed. It is not bureaucracy; it is the one control that keeps the budget where it was agreed.
What should a storyboard contain?
A storyboard that only lists on-screen text is not a storyboard, it is a script. A usable one covers, screen by screen:
- Screen number and title, so everybody can refer to the same thing in review
- On-screen text, exactly as the learner will read it, not as a summary
- Narration script, written to be spoken rather than read
- Visual direction: what the image, diagram, or animation shows and why
- Interaction type: what the learner does, and what happens when they do it
- Feedback for correct and incorrect answers, written out in full
- Branching logic, where a choice changes what comes next
- Source reference, so a reviewer can check a claim against the original document
The last one matters more than it looks. When a subject-matter expert disputes a sentence, the fastest way to settle it is to point at the policy it came from.
How do you review a storyboard properly?
Most storyboard reviews fail the same way: reviewers read it as a document instead of imagining it as a course. They correct commas and miss that the sequence does not teach anything. A good review asks:
- At the end of this, can the learner actually do the thing we need them to do?
- Is anything here that the learner does not need?
- Is the order the order a learner would want, or the order our department is organised in?
- Are the examples real, and would our people recognise them?
- Does the assessment test the behaviour, or just the vocabulary?
- Is there anything here Legal or Compliance has to see?
Get those answered before the build, and the rest of the project is largely mechanical.
What does signing off commit you to?
Sign-off means the content is agreed and development can start against it. It does not mean you can never change anything. It means that changes from this point are handled as change requests, with a cost and a schedule impact, rather than absorbed silently.
That distinction protects both sides, and the sign-off should come from one named person who can speak for the business. A storyboard approved by a committee is a storyboard that will be reopened.
Common reasons storyboards get reopened
- The wrong people reviewed it. The subject-matter expert signed, but nobody asked the team who will actually take the course.
- Source material was out of date. The SOP was superseded during the project and nobody flagged it.
- Legal arrived late. Regulated content needs its reviewers in the storyboard round, not the alpha round.
- The objectives were never agreed. Without them there is no test for whether a screen belongs, so every opinion is equally valid.
Every one of those is avoidable, and cheaper to avoid than to fix.
Frequently asked questions
How long does a storyboard take?
It depends on the length of the course and the state of the source material. Clean, current source and clear objectives make it quick. A pile of conflicting documents and no agreed objectives makes it the longest stage of the project, which is a useful signal in itself.
Do we have to write it ourselves?
No. We write it from the material you provide. You review it. If your team would rather draft the content, we will work from that instead and shape it into a course structure.
Can we skip it for a short course?
You can, and for a very short, very simple module it occasionally makes sense. For anything with branching, assessment, narration, or more than one language, skipping it reliably costs more than it saves.
Our process page sets out where the storyboard sits in the full route from brief to deployed course, and our post on how course review rounds really work covers what happens after sign-off.
Ready to talk about your course?
Send us what you have, however messy. The storyboard stage is where we turn it into something a learner can actually follow.
