A storyboard is a contract, not a sketch
An eLearning storyboard has one job: to let a developer, a reviewer, and a subject-matter expert object to the course before anyone builds it. Every decision the storyboard defers lands in the build, where changing it costs the most. That is the test for what belongs in the document, and it is the whole discipline of storyboarding for eLearning. Not “would this help someone imagine the course” but “could someone block a mistake here.”
Most free storyboard templates fail that test quietly. They are empty grids with columns for text, narration, and a thumbnail, which captures what the course says and leaves out everything reviewers need to catch: which objective a screen serves, what exactly happens when a learner answers wrong, where the branch goes, what the alt text will be, and whether anyone has actually signed off. A storyboard missing those columns does not prevent the rework; it schedules it.
The format question matters less than people think. A script-format storyboard lives in a document or spreadsheet and describes visuals in words; a visual-format storyboard mocks up each screen in slides, which is why most Word storyboard templates you will find are script-format tables and most PowerPoint storyboard templates are visual mockup grids. An instructional design storyboard can be either; the columns below matter in both. Visual formats earn their cost on media-heavy projects with a separate graphic designer who needs layout intent. For most workplace projects, and for anyone building portfolio evidence, script format is the right default: faster to revise, reviewable in comments, and diffable when the SME changes the policy for the third time.
The 14 columns and the failure each one prevents
| Column | The failure it prevents |
|---|---|
| Screen ID | “The feedback on the refund screen” means three different screens in review; a stable ID like NS-01-030 means one |
| Screen title | Skimming reviewers navigate by titles; a storyboard without them gets reviewed one random screen at a time |
| Objective served | Screens that serve no objective accumulate silently; this column makes each one justify its place |
| On-screen text | Written here, verbatim, so the SME reviews the actual words and not a paraphrase of them |
| Narration script | Word-for-word, because “explain the policy briefly” produces a different course in every recording session |
| Media description | What the learner sees, specific enough to source or build; “relevant image” is a decision deferred to the busiest week |
| Interaction type | Names the mechanic so effort can be estimated before the build, not discovered during it |
| Interaction behavior and feedback | The exact consequence of each learner action, including what wrong answers see; the single most common gap in rejected storyboards |
| Branching and navigation | Where every path leads, including retries and failure routes; unwritten branches become dead ends |
| Alt text | Drafted at design time by the person who knows what the image means, not improvised at build time by whoever is closest |
| Accessibility notes | Focus order, captions, contrast, keyboard behavior for this screen; the checks that are expensive to retrofit and cheap to specify |
| Assessment link | Ties questions to the objectives they measure, exposing objectives that are never assessed |
| Review status | Who approved this screen and when; a storyboard where approval lives in email threads has no approval |
| Open questions | The honest column: what is still unresolved, visible to everyone instead of remembered by no one |
The alt text and accessibility columns deserve their own defense, because they are the first ones deleted to make a template “cleaner.” Accessibility requirements like text alternatives, captions, and keyboard operability are testable success criteria under WCAG 2.2, and for anyone building toward U.S. workplace or government contexts they are procurement requirements under Section 508. The storyboard is the last cheap place to meet them. An alt-text decision costs one cell at design time and a remediation ticket after launch.
What a filled storyboard example looks like
The download doubles as an instructional design storyboard example set: three complete screens from a fictional practice scenario, Northstar Systems, a made-up software company whose tier-1 support agents misquote refund policy. Here is the shape of one, compressed:
Worked example
Screen NS-01-030, a decision screen, from the fictional Northstar case
Objective served: O1. On-screen text: “A customer on the Starter tier bought 41 days ago and asks for a refund. What is the correct first response?” Interaction: multiple choice, three options. Behavior and feedback: the correct answer confirms the two-step order and quotes the policy line; each wrong answer receives feedback naming the specific step it skipped, then offers a retry. Branching: correct routes forward; two wrong attempts route back to the teaching screen. Alt text: “Support ticket from a Starter tier customer 41 days after purchase.” Accessibility notes: options are buttons in a list, feedback renders as adjacent text rather than a vanishing toast, retry does not trap keyboard focus. Assessment link: assesses Q1. Review status: in review. Open question: second wrong-answer feedback wording still pending SME.
Notice what the level of detail buys. The developer can build this screen without a meeting. The SME can veto the policy line before it is recorded. The reviewer can see that a wrong answer produces teaching, not just “Incorrect.” And the open-questions cell admits what is unfinished instead of hiding it in someone’s inbox.
eLearning storyboard templateAll 14 columns with three fully written example screens from the clearly labeled fictional Northstar case, plus blank rows. Open it in Google Sheets or Excel, keep the examples beside your first real rows as a detail benchmark, then delete them.
CSV, 14 columnsRunning the review the columns make possible
A storyboard only earns its columns if the review actually uses them. The working sequence, for a small team or a solo builder recruiting help:
- Objective pass. Read only the objective-served and assessment-link columns. Every objective gets taught and assessed somewhere; every screen serves something. Orphans on either side get cut or fixed before anyone reads prose.
- SME pass. The SME reads on-screen text, narration, and feedback verbatim and initials the review-status column per screen. Factual review of a paraphrase is not review.
- Build pass. Whoever will develop it reads media, interaction, and branching columns hunting for anything they cannot build from the words alone. Each find becomes an open-questions entry, not a conversation that evaporates.
- Access pass. Alt text and accessibility notes checked for every screen, including the boring ones. This pass takes minutes at storyboard stage and days after launch.
Then freeze it. A storyboard that keeps changing after sign-off is not a living document; it is an unsigned one. Changes after freeze go through the open-questions column with a new review-status entry, so the record of what was agreed survives the project.
A template cannot make content accurate, and this one does not try: the SME pass exists because no column layout can verify a policy quote or a compliance claim. What the columns can do is make every deferred decision visible while it is still cheap, which is the whole difference between a storyboard and a wish. The same discipline should already be present one step earlier, in the needs analysis that decided this course was worth building; a storyboard, however clean, cannot rescue a course that training should never have been asked to deliver.