How to Storyboard an eLearning Module, Screen by Screen

An eLearning storyboard is a screen-by-screen plan of a module. For every screen it records what learners see, what they hear, what they do, and what happens next. Write it after your objectives and assessment are settled and before anything is recorded or built, so a subject-matter expert, a client or a developer can approve the module while changes are still a matter of editing a table.

Most storyboard guides stop at the template: which columns to include and which software to use. That’s the easy part. The storyboard is also where most of a module’s learning design is decided, one screen at a time: how much goes on each screen, whether words are spoken or printed, where learners practise and what feedback they get. This guide walks through seven steps, with the research that should shape each screen and a cheap way to test the result.

What a storyboard is, and what it isn’t

A storyboard sits between two other documents. Upstream is the course map from the design phase of the ADDIE model: modules, objectives, assessments and their order. Downstream is the build: the module in your authoring tool or course platform. The storyboard translates one into the other.

It isn’t a script, which holds only the words. It isn’t an outline, which holds only the topics. And it isn’t a set of finished slides: if a reviewer is commenting on fonts, the storyboard has gone too far, too soon.

To keep things concrete, we’ll follow one example throughout: a ten-minute module that teaches new customer-service staff at an online homewares shop to handle a refund request. It’s an invented example, but typical of the short workplace modules many course builders storyboard.

Step 1: Start from the objective and the assessment

Before you write a single screen, have two things on the page: the objective for the module, and the task that will show learners can meet it. If you haven’t written them yet, our guide to writing learning objectives covers how.

For the refund module, the objective might be: “Given a customer’s refund request, decide whether it meets the returns policy and reply with the right next step.” The assessment is three short customer emails, each needing a decision and a reply.

Now every screen in the storyboard has to earn its place by moving learners towards that assessment. This is the single best filter against the most common storyboard failure: a module planned from the content outwards, which ends up as slides of information with a quiz attached.

Step 2: Decide who the storyboard is for, then pick the format

A storyboard usually has three readers: you, the subject-matter expert who checks accuracy, and whoever builds the module. Sometimes there’s a client who signs it off. Each needs something slightly different, so decide early.

There are three common formats:

Format	Best for	Watch out for
A table in Word or Google Docs	Text-heavy modules, quick reviews, comments in the margin	Hard to judge layout and how crowded a screen is
One slide per screen in PowerPoint or Google Slides	Modules with diagrams, scenarios or a lot on screen	Tempts you to design the finished look too early
Straight into the authoring tool	Solo builders who’ll build what they storyboard	Polish arrives before the design is approved

For the refund module, a table is enough: it’s mostly scenario text, short narration and questions. If you’re unsure, use whatever your reviewers will actually open and comment on.

Step 3: Set up the columns

There’s no official template, but most storyboards share the same core columns. This is the set we’d use:

Column	What goes in it
Screen	A number and a short title, so reviewers can refer to “screen 4: the late return”
Objective	Which objective, or which part of it, this screen serves
Visual	A description or rough sketch of what’s on screen
Narration	The exact words the narrator will say
On-screen text	Only what must be read: labels, instructions, short key terms
Interaction	What learners can click, drag, type or answer
Feedback	What learners see after each choice, right or wrong
Navigation	Where they go next, including branches and retries
Accessibility	Alt text, caption and transcript notes, anything that relies on colour
Reviewer notes	Comments and decisions, dated, so feedback lives in one place

Two of these columns do most of the learning work and are the ones people skip: Objective, which keeps every screen tied to the assessment, and Feedback, which is where practice turns into learning.

Step 4: Map the screens before you write them

Resist the urge to start writing screen 1. First, list the screens as one-line titles, a page at most, so you can see the module’s shape. For the refund module:

1. The situation: a refund request arrives
2. The three questions to ask of every request
3. Worked example: a straightforward return
4. Practice: is this request within policy?
5. The awkward cases: late returns, used items, missing receipts
6. Practice: two awkward requests, with feedback
7. Writing the reply: what it must include
8. Final task: three emails to decide and answer

Look for two things. Is there practice before the final task, and does it come early? And does any screen exist only because the content was available? If you can’t name the objective a screen serves, cut it or merge it.

Keep the screens short and let learners move on when they’re ready. A meta-analysis of 56 investigations found that presenting multimedia instruction in learner-paced segments, rather than as one continuous unit, had small to medium benefits for both retention and transfer (Rey et al., 2019). It came with a trade-off worth knowing:

In practice, a module of short screens with a Continue button takes learners a little longer than one long video, and they learn more from it.

Step 5: Write each screen against the research

This is where the storyboard does its real work. Richard Mayer’s research group has spent decades testing how words and pictures should be combined on screen, and he summarises fifteen design principles, with the effect size for each (a standard measure of how much better the group taught the better way did on later tests) and the number of experiments behind it (Mayer, 2024). Six of them are decisions you make, screen by screen, in the storyboard.

Cutting extras from a screen had an effect size of 0.86 across 19 tests

Effect sizes Mayer reports for six principles a storyboard settles screen by screen, from his research group's experiments · effect size

Here’s how each one turns into a question to ask of every row.

Does everything on this screen serve the objective? (Coherence.) This is the one most worth checking, because it’s the easiest to break with good intentions: the interesting statistic, the background music, the decorative stock photo.

On the refund module, the history of the shop’s returns policy goes. The three questions to ask of every request stay.

Are the words spoken or printed? (Modality and redundancy.) When a screen has a graphic, put the explanation in the narration rather than in a paragraph beside it, so learners can look and listen at once. And don’t print the narration on screen as well: in Mayer’s summary, adding printed text to graphics and narration showed almost no benefit, an effect size of 0.10 across 12 tests, and he notes the principle applies when the lesson is fast-paced. Keep on-screen text to instructions, labels and short key terms. Captions that learners can switch on are a different thing and a requirement, which we’ll come to in Step 6.

Does the screen point at what matters? (Signalling.) Headings, a highlight on the clause of the policy that decides the case, or narration that says “the key word here is unused” all help learners find the essential material.

Do learners know the key terms before they need them? (Pre-training.) If the module relies on two or three terms (“store credit”, “change-of-mind return”), introduce them on an early screen rather than in the middle of a scenario, where learners are already busy.

These principles have limits. Mayer is explicit that each is subject to boundary conditions: for whom it applies, for which kind of lesson, and under what circumstances. Treat them as strong defaults to check every screen against, not as rules that override what you see when learners try the module in Step 7. Our library entries on cognitive load and dual coding go further into why these principles work.

Step 6: Write the interactions, feedback and accessibility notes

For every interaction, write out what happens after each possible answer, not just the right one. Feedback for a wrong answer should say why it’s wrong and what to look at again, not just “Try again”. On the refund module, a learner who approves a refund for a used item should see the line of the policy that rules it out, and then another chance.

Then write the navigation: where learners go after a correct answer, after a wrong one, and after a second wrong one. Developers can’t guess this, and it’s the column most often left blank.

Finally, fill in the accessibility column while the design is still on paper. The W3C’s Web Content Accessibility Guidelines set out what accessible web content needs, and several Level A requirements in WCAG 2.2 are storyboard decisions:

• Text alternatives (1.1.1): every image that carries meaning needs a text alternative that serves the same purpose. Write the alt text in the storyboard, next to the visual it describes.
• Captions (1.2.2): prerecorded audio in synchronised media needs captions. Your narration column is already the caption script.
• Audio description or a media alternative (1.2.3): if a video shows something the narration doesn’t say, plan how a learner who can’t see it will get that information.
• Use of colour (1.4.1): colour can’t be the only way information is shown. If correct answers turn green, add a tick and the word “Correct”.

Requirements vary by country and sector, so check which version and level your organisation or client works to. Planning these in the storyboard costs a column; retrofitting them after the build means reopening every screen.

Step 7: Review it, then test it with learners

A storyboard usually gets two reviews: the subject-matter expert checks it’s accurate, and the client or manager checks it’s what they asked for. Both matter, and neither tells you whether learners can use it.

So add a third review. Put the storyboard, or a rough click-through of the first few screens, in front of three or four people like your learners, and watch them work through it. Can they answer the practice questions? Where do they hesitate? Does the feedback help them get the next one right? This is the logic of rapid prototyping, which instructional designers borrowed from software engineering: build something rough early, put it in front of users, and revise before committing to the full build (Tripp & Bichelmeyer, 1990).

For the refund module, that might mean printing the eight screens, handing a new staff member the three practice emails, and noting which ones they get wrong and why. If two testers approve the same late return, the policy screen needs work, and you’ve found out before recording a word of narration.

Record every decision in the reviewer notes column, with a date, and get a clear sign-off before the build starts. Changes after that point should go back through the storyboard first, so it stays the one true record of the module.

Five common mistakes

1. Storyboarding the content, not the task. If the screens follow the order of the source material rather than the path to the assessment, go back to Step 1.
2. Narration and on-screen text that say the same thing. Pick one. Usually the narration.
3. Only writing feedback for the right answer. Wrong-answer feedback is where most of the learning happens.
4. Leaving accessibility to the developer. Alt text, captions and colour are design decisions.
5. Treating sign-off as testing. An expert approving the storyboard isn’t the same as a learner getting through it. Test with both.

Our online course design checklist covers the checks that come before and after this stage.

What to do next

Take the next module you’re planning and write only the screen list from Step 4: one line per screen, with the objective each one serves. If any line has no objective, cut it before you write anything else.