Does an eLearning storyboard always have to be in Word or PowerPoint?

No. The format depends on your team and project. Word and Google Docs are most common for written storyboards. PowerPoint or Keynote work well when you want to sketch the visual layout. Some teams use Figma for storyboards with detailed visual components. What matters is not the tool — it's that the document is clear, complete, and easy for everyone to review .

How many screens does a typical storyboard have?

It depends on the course. A 10–15 minute module typically has between 15 and 35 screens depending on content density and the number of interactions. A one-hour course can have between 80 and 150 slides. The number matters less than ensuring each screen has a clear instructional purpose .

Who writes the storyboard — the instructional designer or the SME?

The instructional designer writes the storyboard, using content provided by the SME. The SME is the subject matter expert — they know what is accurate. The instructional designer's job is to convert that knowledge into an effective learning experience : deciding the sequence, the level of depth, and the format of each screen.

Does the storyboard include detailed visual design?

It depends on the team's workflow. In most projects, the storyboard describes layout in words ('image left, text right, no visible title') and the developer makes visual decisions within the approved template. In better-resourced projects, a visual designer works alongside the instructional designer and wireframes or mockups are included. Either approach works — what matters is that the developer has enough information to produce without guessing .

How do you document branching in a storyboard?

A flowchart is clearest: each decision screen with its options and where each one leads. You can also use a table with columns for screen, condition, and destination. For complex projects, both together — a diagram for the big picture and a table for the detail — is the most practical combination.

Does the storyboard need to be fully approved before development starts?

In waterfall models (classic ADDIE), yes. In agile instructional design (SAM), you work in cycles: approve the first module's storyboard, develop it, show the client, then adjust before continuing. Full upfront approval reduces rework risk but delays the first visible deliverable.

Is there a difference between a storyboard and an instructional script?

The terms are used interchangeably in the industry. Some teams use 'script' for a document that primarily covers text and narration (more oriented to video or audio production), and 'storyboard' for a document that also includes visual layout, interactions, and development notes. What matters is that your document includes whatever the production team needs to build without assumptions.

Is it worth writing a storyboard for short courses?

For a 3-minute microlearning with a single objective, a full storyboard may be overkill — a one-page document with the text and narration for each screen is enough. For any course longer than 10 minutes, or with real interactivity, a storyboard always saves net time : what you spend writing it, you recover in avoided rework during development.

How to write an eLearning storyboard from scratch | LXD Learning Experience Design

The storyboard is where instructional design becomes producible. It sits between analysis and development — a screen-by-screen description of everything that will happen in the course: what the learner will see, what they will hear, what they can do, and how the system responds. Without a good storyboard, eLearning development is a chain of assumptions. The developer assumes. The client assumes. The reviewer assumes. And the final product looks like nothing anyone had in mind.

I have seen this pattern many times. Teams skip the storyboard to save time and end up spending three times as long on revision cycles — because it is vastly more expensive to move objects in Storyline than to edit a sentence in a document. The storyboard is the cheap stage. Never rush through it.

This guide covers how to structure a storyboard from scratch, what to include in each screen, how to avoid the most common mistakes, and how to adapt the format based on the type of project.

What an eLearning storyboard actually is

An eLearning storyboard is the design document that describes — screen by screen — everything that will happen in the course before development begins. It defines the visible text, the audio narration, the visual elements, the interactions, the navigation logic, and the production notes for the developer.

The word comes from film, where directors sketch scenes before shooting them. The analogy is exact: the storyboard is the script and visual map of the course before it exists in an authoring tool.

What it does in practice:

Gives the client or SME something concrete to review before any development time is invested
Gives the developer clear instructions that require no interpretation
Acts as a scope contract: what is in the approved storyboard is what gets built
Makes revisions manageable: it is far faster to edit text in a document than to reposition elements in Storyline

A well-written storyboard cuts rework in half. A poor one — or no storyboard at all — is the leading cause of overrunning projects, dissatisfied clients, and frustrated developers.

One thing worth saying explicitly: with AI tools now able to generate first-draft scripts and module outlines quickly, the storyboard step is not disappearing — it is becoming more important. AI output needs structure, judgment, and specificity to become a real course. The storyboard is where that thinking happens, and it is not something AI can do for you without your direction.

What every screen of the storyboard must include

Each screen (or slide) of the storyboard is a row or section of the document. These components must always be present:

Screen ID — A unique number or code that identifies the slide. For example: M1-S03 (Module 1, Slide 03). This is essential for referencing in reviews: “check the feedback on M2-S07” is infinitely clearer than “the slide with the questions in that module.”

Title or description — A single line describing what happens on that screen. Not the visible course title — this is for the production team only.

On-screen text — The exact text the learner will read. No abbreviations, no “add SME text here.” If the text is not written, the screen is not ready.

Narration / audio — The complete script for what the voiceover or avatar will say. Word for word. Thirty seconds of narration is approximately 75–80 words at a conversational pace.

Visual / developer instruction — A description of what will be shown: image, animation, diagram, character, avatar state, icon. It does not have to be a drawing — a clear description is enough. “Image of a team meeting, neutral background, no overlaid text” is sufficient.

Interaction — What the learner can do: click a button, drag an element, answer a question, choose between options. If there is no interaction, specify that it is a linear advance screen.

Navigation logic — What happens next: does it advance to the next screen? Is there a conditional? If the learner answers incorrectly, do they go to a retry screen? Branching paths are documented here.

Production notes — Technical instructions for the developer: “this screen has a sequential entrance animation,” “the next button does not appear until the audio finishes,” “use hover state 3 for the character.”

Warning

The most dangerous storyboard is the one that looks complete but has placeholders. "Add narration here" or "insert relevant image" are not storyboard entries — they are deferred decisions that will cost you later. If a screen is not fully written, mark it clearly as draft and do not submit it for review.

Overall structure of a storyboard

A storyboard is not just a list of slides — it has a structure that reflects the instructional design of the course. A typical structure looks like this:

Document cover page

Project name, client, version, date, author
Status: draft / under review / approved
Change log (invaluable on projects with multiple revision rounds)

A diagram or table showing the complete course structure: modules, sections, screens, and how they connect. Particularly important in courses with branching.

Content slides by module

Grouped by module or section. Each slide contains all the components described above.

Appendix (if applicable)

Asset list: images, video, icons, characters needed
Accessibility specifications
Notes on localisation versions

Storyboard templates by screen type

Not all screens are the same. These are the most common types, with what each requires:

Module title / module entry screen

ID: M1-S01
Type: Module cover
Visible text: "Module 1: Effective client communication"
Narration: "In this module, you will explore three real situations where communication can determine whether a client renews or cancels."
Visual: Dark background image with centred text, title entrance animation.
Interaction: "Begin" button that advances to M1-S02.
Notes: No audio until the learner clicks Begin.

Content screen with narration

ID: M1-S04
Type: Content + narration
Visible text: "Active listening is not waiting for your turn to speak."
Narration: "When a client presents a problem, the first instinct is often defensive or corrective. Active listening requires containing that instinct and asking questions that confirm you understood before responding."
Visual: Listening icon left, text right. Two-part entrance animation.
Interaction: Auto-advance when audio ends, or manual button if audio is off.
Notes: Text does not appear until 1 second into the audio.

Multiple choice question

ID: M1-S08
Type: Quiz — multiple choice
Question text: "A client says the product 'didn't work as expected.' What is the most effective first response?"
Options:
  A) "Let me explain how it works correctly."
  B) "What specifically were you expecting it to do?"
  C) "Our other clients haven't reported that issue."
  D) "I'll send you the user manual."
Correct answer: B
Correct feedback: "Exactly. Before explaining or defending, you need to understand what the client expected. The question opens the conversation."
Incorrect feedback (A): "This assumes the problem is one of understanding, not expectation. It can feel condescending."
Incorrect feedback (C): "Comparing with other clients dismisses this client's experience."
Incorrect feedback (D): "Sending documentation without understanding the problem rarely resolves anything."
Navigation: If B, advance to M1-S09. If A, C, or D, show feedback and allow retry.
Attempts: 2 maximum.

Branching scenario screen

ID: M2-S03
Type: Decision — branching point
Visible context: "Your client has just mentioned they are evaluating a competitor's solution."
Decision: "What do you do?"
Option 1: "I ask what led them to explore other options." → Goes to M2-S04A (effective response)
Option 2: "I immediately present our competitive advantages." → Goes to M2-S04B (consequence: client closes off)
Option 3: "I offer a discount." → Goes to M2-S04C (consequence: transactional conversation)
Visual: Client avatar on screen with neutral expression.
Notes: No visibly "correct" answer — the learner discovers consequences by navigating.

Tip

For branching scenarios, write the consequence screens before you write the decision screen. You need to know where each path actually leads — what the learner experiences, what they learn from each choice — before you can write the decision prompt clearly. Working backwards from consequences produces better branching design than working forwards from options.

Process: from analysis to storyboard

The storyboard does not get written from nothing. It gets built on top of your analysis work.

1. Be clear on the performance objective

Before writing a single screen, you need to know what the learner will be able to do differently after the course. “Will understand the returns policy” is not a performance objective. “Will process a returns request following the procedure without consulting a supervisor” is. If you cannot state the performance objective in measurable terms, your storyboard will lack focus and your client will keep asking for more content.

2. Have the source content

The storyboard does not invent content — it organises it, simplifies it, and converts it into a learning experience. You need the SME’s material, the process documents, the real examples, the cases that go wrong. Without this, you only have empty structure. Never start storyboarding from a vague brief and an AI tool — you will produce plausible content that may be inaccurate, and you will not know where it is wrong.

3. Map the screens before writing them

Before drafting, build a sketch: how many sections, roughly how many screens per section, where the practice points are, how each module closes. This map is the architecture of the building before you start laying bricks. It prevents you from reaching screen 40 and realising the structure does not work.

4. Write in the order of learning, not the order of content

The storyboard is not the source document’s table of contents transferred to slides. It is the sequence that optimises learning: first the context and relevance, then the minimum necessary content, then practice, then feedback, then consolidation. Your SME will often push for “let’s cover everything first” — your job is to hold the learning sequence, not the content inventory.

5. Review with the SME before developing

The storyboard review with the SME is where you catch content errors, wrong terminology, and information gaps. It is enormously cheaper to fix text in a Word document than to move elements in Storyline after a developer has spent three days building the screen. This review step is non-negotiable. It is also the moment where SMEs often try to add more content — be ready to defend the learning design decisions you made in step 4.

Tip

If your project includes live or synchronous components — a debrief session, a cohort discussion, a live workshop — document those touchpoints in the storyboard too, even if briefly. Tools like Questiory are increasingly used as the social layer alongside asynchronous eLearning: learners complete the modules, then come together (live or asynchronously) to process, share experience, and build on what they learned. The storyboard is the right place to plan where those connections happen in the overall sequence.

Common mistakes and how to avoid them

Storyboard without complete narration. Writing “add narration here” or “complete with audio” is not a storyboard — it is a debt. Without the full script, the developer cannot produce, and the voice actor cannot record. A storyboard without narration is not a storyboard.

Too much on-screen text. If the on-screen text repeats everything the narration says, the learner does one of two things: reads and does not listen, or listens and does not read. The on-screen text should be the key concept, not the complete script. One is an anchor; the other is noise.

Ambiguous visual instructions. “Put a relevant image” tells the developer nothing. “Image of a person looking at a computer screen in an open-plan office, no overlaid text, landscape orientation” is an actionable instruction. The difference between those two descriptions is the difference between a production process that flows and one that generates back-and-forth messages for every screen.

Undocumented branching logic. In courses with scenarios, the storyboard must include the route map. Without it, the developer has to guess how to connect the screens. Branching scenarios are where the most rework happens — and almost all of it is avoidable with a proper flowchart in the storyboard.

Reviewing the storyboard in the authoring tool. The storyboard exists precisely to avoid this. Once development begins, changes are far more expensive. The storyboard stage is the low-cost revision window. Any client or SME who asks to “just make a few changes in the course” after approving the storyboard needs to understand what that costs.

Writing for readers, not learners. The storyboard must be written in second person, with a conversational tone and action verbs. “Instructional design is the systematic practice of…” sounds like a manual. “You are designing to solve a performance problem, not to cover content” activates something different. Write the narration the way a good facilitator would speak — not the way a textbook is written.

Warning

One increasingly common mistake is using AI to generate storyboard content without adequately verifying it. AI tools produce fluent, confident-sounding content that may contain inaccurate information — particularly for compliance content, technical procedures, or regulated domains. If you use AI to draft screens, build a verification step into your process. Every claim must be confirmed against authoritative sources before the storyboard goes to the SME or the developer.

Storyboard vs. prototype: when to use each

The storyboard and the prototype serve different functions and are not interchangeable.

The storyboard is the written document that specifies the content, interactions, and production logic. It lives in Word, Google Docs, PowerPoint, or a custom template. It is the standard for complex projects, external clients, and teams where the instructional designer and developer are different people.

The prototype is a preliminary version built directly in the authoring tool (Storyline, Rise, Canva) — typically the first two or three screens of a module. It shows the real visual design, navigation, and experience before the full course is built. It is useful for aligning visual expectations with clients who cannot “read” a storyboard.

In practice, many teams use both: the storyboard for content and logic, and a one- or two-screen prototype to validate the visual design before producing the rest. The storyboard comes first. The prototype confirms you have interpreted it correctly.

Neither replaces the other. A prototype without a storyboard means your developer is making instructional design decisions. A storyboard without a prototype means your client may approve content they cannot visualise — and then reject the look when they see it built.

A note on storyboarding in an AI-augmented workflow

AI tools have changed how long the first draft takes. You can now use ChatGPT or Claude to generate a module outline, draft narration scripts, or produce a first version of a knowledge check in minutes. That is genuinely useful.

What has not changed is the thinking that makes a storyboard good: knowing what the learner needs to be able to do, understanding the performance gap, choosing the right interaction for the right learning moment, writing feedback that actually teaches rather than just confirms. AI cannot do that thinking without your direction — and when it tries, the result is storyboards that look complete but do not actually drive learning.

Use AI to accelerate the production work within the storyboard. Keep the instructional design decisions in your hands.

Key Questions Answered

The most commonly asked questions about this topic, concisely answered.

: No. The format depends on your team and project. Word and Google Docs are most common for written storyboards. PowerPoint or Keynote work well when you want to sketch the visual layout. Some teams use Figma for storyboards with detailed visual components. What matters is not the tool — it's that the document is clear, complete, and easy for everyone to review.
: It depends on the course. A 10–15 minute module typically has between 15 and 35 screens depending on content density and the number of interactions. A one-hour course can have between 80 and 150 slides. The number matters less than ensuring each screen has a clear instructional purpose.
: The instructional designer writes the storyboard, using content provided by the SME. The SME is the subject matter expert — they know what is accurate. The instructional designer's job is to convert that knowledge into an effective learning experience: deciding the sequence, the level of depth, and the format of each screen.
: It depends on the team's workflow. In most projects, the storyboard describes layout in words ('image left, text right, no visible title') and the developer makes visual decisions within the approved template. In better-resourced projects, a visual designer works alongside the instructional designer and wireframes or mockups are included. Either approach works — what matters is that the developer has enough information to produce without guessing.
: A flowchart is clearest: each decision screen with its options and where each one leads. You can also use a table with columns for screen, condition, and destination. For complex projects, both together — a diagram for the big picture and a table for the detail — is the most practical combination.
: In waterfall models (classic ADDIE), yes. In agile instructional design (SAM), you work in cycles: approve the first module's storyboard, develop it, show the client, then adjust before continuing. Full upfront approval reduces rework risk but delays the first visible deliverable.
: The terms are used interchangeably in the industry. Some teams use 'script' for a document that primarily covers text and narration (more oriented to video or audio production), and 'storyboard' for a document that also includes visual layout, interactions, and development notes. What matters is that your document includes whatever the production team needs to build without assumptions.
: For a 3-minute microlearning with a single objective, a full storyboard may be overkill — a one-page document with the text and narration for each screen is enough. For any course longer than 10 minutes, or with real interactivity, a storyboard always saves net time: what you spend writing it, you recover in avoided rework during development.

How to write an eLearning storyboard from scratch