What is an eLearning storyboard?

Who this answer is for

This answer is for people handed the word “storyboard” without a definition attached: an L&D coordinator asked to review one by Friday, an SME wondering why anyone needs a document before the course exists, or a manager deciding whether to buy storyboarding as a separate phase. It assumes no prior vocabulary from the wider instructional design discipline, and it is not a tool tutorial: storyboards get written in Word, spreadsheets, Figma, and review platforms, and the tool matters far less than what the document settles and who agrees to it.

Why the answer changes by context

A storyboard is a build contract, and what a contract must contain depends on who signs it and what happens when signatories disagree later. Four variables move the answer.

• Who builds it. If the author also develops the course, shorthand is safe: writer and interpreter are the same person. Hand the document to a separate developer or vendor and every implicit decision becomes a defect waiting to surface.
• How reversible the build is. Text in a Rise block is cheap to change. Recorded narration, custom illustration, and complex Storyline interactions are not. The more expensive the rework, the more must lock before production.
• How many approvers exist. One SME and one manager is a conversation. Add legal, compliance, brand, and three operations leads and it becomes a governance problem; the storyboard keeps the disagreement in writing.
• What the course has to prove. A light onboarding module and a course that must show defensible coverage of a regulated procedure need different documents; the second needs a traceable line from every screen to a source of record.

That variability is why the deliverable is scoped deliberately in a curriculum consulting engagement, and why storyboard effort is, in our judgment, among the least predictable line items when estimating how long an eLearning course takes to build.

The Twelve-Field Accountable Row: an annotated storyboard screen

Below is one storyboard screen in the shape it would take. Hypothetical scenario: a 20-minute module for warehouse shift supervisors at a fictional distribution company, teaching them to complete a near-miss report. This is the screen where the learner practises deciding whether an event is reportable.

What each field controls, who signs it, and how it fails

The fields themselves are conventional; the annotation is the part worth arguing about. Each entry names the single role that should sign the field and the specific failure that follows when it is left vague. Both are professional judgment — a governance convention IETERNUS proposes, not an industry rule or a measured finding.

• Screen ID — controls every downstream reference: review comments, asset filenames, bug reports, translation files. Owned by the designer. Renumber mid-project and comments detach from what they described.
• Objective link — controls whether the screen earns its place. Signed by whoever owns the training outcome. When vague, courses accumulate screens that are interesting but unteachable.
• Screen purpose — controls tone, difficulty, and whether feedback teaches or merely confirms. Signed by the designer. Left blank, practice screens turn into content screens.
• On-screen text — controls the learner’s experience and, in regulated content, the organisation’s exposure. Signed by the SME, and compliance where applicable. Written as intent rather than verbatim copy, the text gets invented twice: by the developer, then by the reviewer who disagrees.
• Narration — controls recording cost and runtime. Signed by the SME for accuracy, the sponsor for length. Approximate narration gets re-recorded, and re-recording costs more than re-writing.
• Visual / media spec — controls the asset pipeline and the critical path. Signed by whoever holds the media budget. When vague, production stalls waiting for something nobody was asked to make.
• Interaction spec — controls development effort and testability. Signed by the developer, confirming it is buildable in the tool. Absent it, this is a script, not a specification.
• Feedback logic — controls whether the interaction teaches. Signed by the SME. Reduced to “correct / incorrect”, the module’s best teaching moment is discarded.
• Assessment link — controls alignment between practice and evidence. Signed by the outcome owner. Missing, learners get assessed on material they never practised.
• Accessibility notes — controls conformance work that is far cheaper before build than after. Signed by whoever can state which standard, version, and level the project is held to; see what actually makes eLearning accessible.
• Source of truth — controls defensibility and maintenance. Signed by the SME. Without document, version, and section, nobody can tell two years later whether the screen is still true.
• Status / owner — controls whether the storyboard is honest. Signed by the project owner. Blank fields read as agreement; OPEN markers read as risk.

The ten-minute storyboard audit: four tests and their failure conditions

These are tests you can run on a document in front of you, including one somebody else wrote. The thresholds are planning heuristics offered as a working standard, not validated measures.

1. The random-three test — decidability. Pick three fields at random from three different screens and ask of each: could a reviewer approve or reject this without asking anyone a question? “Make this engaging” fails; “single-select, one attempt” passes. Failure condition: more than one of the three needs a clarifying question. The document is a plan, not a specification, and review will produce opinions rather than decisions.
2. The single-name test — ownership. Take one screen and write a person’s name beside every field. Failure condition: any field carries two names, or none. Two names is the more dangerous result, because each approver can reasonably assume the other checked it; a field with no name is at least visibly unowned.
3. The rework-cost test — visible consequence. Ask whether a reviewer reading only the storyboard can tell which comments would trigger re-recording, re-illustration, or re-programming rather than a text edit. Failure condition: the document gives no signal of cost, so every comment arrives with equal weight. Marking recorded, commissioned, and custom-built elements in the row itself changes how reviewers spend their objections.
4. The OPEN-count test — loud failure. Count the items marked OPEN before the freeze. Failure condition: zero, on a multi-approver project. In our judgment a storyboard with no unresolved items at sign-off has usually not resolved them; it has written unknowns as though they were settled, which is the state the worked example below describes.

Step by step: how a storyboard is actually produced

1. Fix the objectives first. Screens are written against enabling objectives, not source material. If objectives are still moving, storyboarding is premature.
2. Inventory and version the source. Every procedure, deck, and manual gets a version number first. Undated source material invites one specific dispute: two reviewers arguing from different revisions of the same procedure, each correct about the copy in front of them.
3. Extract SME knowledge deliberately. The gaps a storyboard exposes are often gaps in what the SME was asked; see the questions worth asking SMEs before building training.
4. Draft structure before screens. Module flow, then screen count per section, then content. Writing screen one first tends to produce a front-loaded, back-thin course.
5. Write one representative screen of each type — content, practice, assessment, summary — and get those approved before writing eighty more in an unagreed format. Recommended practice rather than evidenced standard, but the cost of being wrong about format scales with how many screens carry the mistake.
6. Run a structured review, then freeze. Separate passes for accuracy (SME), instructional soundness (designer), and buildability (developer); merged reviews produce contradictions. After sign-off, changes are recorded, costed, and re-approved rather than forbidden.

A worked example: the same screen before and after it becomes decidable

Still the hypothetical warehouse module. An early draft of M2-S07 read in full:

“Knowledge check on near-miss criteria. Ask a scenario question. Give feedback. Illustration of warehouse.”

Four people approved it, because there was nothing in it to disagree with. Three problems then surfaced in development, each traceable to a missing field. Because no on-screen text was written, the developer invented the scenario and the SME first saw the wording in the built module: a review that should have cost minutes cost a rebuild. Because no feedback logic was written, “give feedback” became correct/incorrect, discarding the misconception the screen existed to correct. Because no media spec was written, “illustration of warehouse” became a stock photo with recognisable faces, and QA raised a privacy objection.

The twelve-field version settles all three before anyone opens the authoring tool, and does something more useful: it makes the one genuine unknown visible, marking the third answer option OPEN pending an SME ruling with a named owner and a date. The first version hid that uncertainty inside a sentence that read like a plan.

Common mistakes

Failure patterns worth guarding against, stated as mechanisms; we make no claim about how often each occurs.

• Writing intent instead of content. “Explain the policy” is a note to yourself. If the words are not in the storyboard, someone else invents them.
• Storyboarding the source rather than the objectives. This produces a faithful retelling learners could have read themselves — the failure mode most worth guarding against in conversions of existing PowerPoint training.
• Treating accessibility as a build-phase concern. Focus order, alt text intent, caption needs, and colour independence are storyboard decisions, and so is naming the conformance target the project is actually held to.
• Sending 120 screens for review at once. Reviewer attention is finite and, in our judgment, front-loaded; later screens tend to get less of it.
• Over-specifying visual design. Pixel-level direction invites arguments about aesthetics in a review meant to settle instruction.

Decision table: how much storyboard do you need?

Sources and review note

Editorial owner: IETERNUS Learning Systems. Last updated: 8 August 2026.

Established fact. No public standard defines the format of an eLearning storyboard; it is a working practice, not a specification. Standards apply to what it produces. The Web Content Accessibility Guidelines (WCAG) are a W3C Recommendation, and version 2.2 is current; they define the accessibility success criteria that procurement and regulatory frameworks cite. Those frameworks adopt WCAG at specific, differing versions rather than automatically tracking the newest one: the Section 508 standards issued under the US Rehabilitation Act incorporate WCAG 2.0 Level A and AA by reference, and EN 301 549 references WCAG at the version fixed in the edition being cited. Confirm which version and level your project is contractually held to before writing accessibility notes into a storyboard. Separately, SCORM 2004 4th Edition (ADL) defines how a packaged course reports completion, success, and score to a conforming LMS through a fixed run-time data model, which is why completion and scoring rules belong in the storyboard rather than in the build. xAPI (ADL) instead sends statements to a Learning Record Store, which need not be the LMS, and leaves the meaning of completion to the design — so with xAPI the storyboard has to say what counts as done, because no data model decides it for you.

Professional judgment. The twelve-field row, the sign-off ownership assigned to each field, the four audit tests and their failure conditions, and the fidelity decision table are IETERNUS’s own working framework — a defensible way to structure and check the deliverable, not a measured or externally validated one.

Assumption. The worked example is hypothetical. It describes no real client, project, or organisation, and claims no outcomes.

Learning topic: Instructional Design