A storyboard for an animated explainer video is a locked scene list: one row per scene, each carrying a name, a duration, a visual described in words concrete enough to build from, and a one-line statement of what the viewer must take away. Drawings are optional. The document has to be precise enough that anyone can look at the finished scene and say "that is, or is not, what we agreed."
The examples below come from a 90-second explainer for a scheduling API, a product with no interface of its own: booking requests arrive, a calendar fills, a conflict resolves, and a webhook fires to confirm. A product like this leans on its storyboard more than most, because there is no existing UI to point a camera at, so every frame gets designed from the API's behavior.
The scene list is a contract
Most storyboard advice treats the board as inspiration: sketch some frames, get a feel, stay flexible. Flexibility sounds harmless, and it is where budgets go. Animation, voiceover, rendering, and the reviewer's watch time all get spent on whatever the scenes turn out to be, and a large share of total production effort is response to review notes (the revision numbers). With a vague storyboard, the first review is the first time anyone finds out what the video actually is.
So the working rule in our shop is strict: once the scene list is blessed, production builds exactly those scenes. A change is a new version of the document, never a silent edit. The contract moves the discovery of what the video is upstream, to a text document you can argue about in an afternoon.
What a storyboard row must contain
A row carries five fields, and a row missing one is a scene that isn't planned yet.
| Field | What it holds | From the scheduling video |
|---|---|---|
| Name | The scene's idea as a slug. If you can't name what the scene does, you don't yet know what it does. | two-requests-one-slot, never scene 4 |
| Duration | 8–12 seconds per scene, 60–90 for the video. The estimate forces a scope decision before anything is built. | ~9s |
| Visual | Concrete enough that someone who wasn't in the room could build the scene from the words alone. | "Two requests target the same 3 pm slot; the first lands and its block turns solid; the second holds in a visible pending state while the conflict rule evaluates, then settles into 4 pm, and the confirmation webhook fires as it lands" |
| Beat intent | One sentence saying what the viewer must take away. It briefs the narration writer and never appears on screen. | "The API resolves conflicts itself — the viewer watches the collision resolve without a human touching anything" |
| Boundary state | What the final frame shows, which must equal the next scene's opening frame. | Calendar with 3 pm and 4 pm booked, confirmation webhook fired |
One row does three jobs. The claim, that the API resolves conflicts on its own, gets made by frame timing the viewer can watch rather than by a caption asserting it. The intent line hands the narration writer their brief. And a reviewer can compare the built scene against the row, word by word.
Each scene teaches exactly one thing, and a row whose intent line contains "and" is two scenes (one idea per scene).
What the document around the rows carries
Four more things get stated once, at the top:
- The one idea. One declarative sentence the entire video argues. For the scheduling video: "your calendar logic becomes one API call." Any scene that doesn't push that sentence toward obvious gets cut.
- The arc, named. Problem-first, capability-first, outside-in zoom: the document says which and why, which forces a real decision instead of default chronology.
- The run economy. Viewers give a machine's first full run their whole attention and later runs almost none, so one booking gets traced end to end and then revisited, never five bookings in a row.
- A grounding table. Every on-screen string, number, and label maps to a real product source: real endpoint paths, real response fields, calendar data with a stated origin. A value you can't source stays off screen, because a viewer who knows the product spots an invented one instantly.
Prove the rows with stills before motion
The row descriptions are promises, and the cheap way to keep them honest is to render still frames of the actual scenery before any motion, narration, or final rendering begins. A still already shows the layout, the surfaces, the framing, and whether the calendar reads as a product or a brochure, so a wrong layout or an invented surface gets caught in minutes instead of in a finished render. We adopted the gate after one batch went straight to full render and mostly died in review (the numbers are in the production guide).
- Review a still for every camera framing, not just the hero frames. A framing nobody looked at is a framing that ships wrong.
- Accept only images, never assurances. A written claim that framing was verified is worth nothing; we have the false ones on record.
If you are commissioning a video rather than making one, ask for this clause: still frames for approval before any animation begins. A vendor who resists is asking you to buy the expensive phase blind.
The storyboard sits after the concept and before the narration, because words written to a locked picture can land the key word on the key visual moment, while visuals bolted onto a finished script never sync (the scriptwriting guide).
FAQ
Do I need to be able to draw? No. The storyboards behind our produced videos are text: named scenes, durations, visuals in build-ready words, and beat intents. The first pictures anyone sees are rendered stills of the real scenery.
How many scenes does a 60–90 second video need? Usually six to eight, one per idea. Fourteen scenes for 75 seconds means some scenes carry half an idea, and four means some carry two.
What happens when something changes after the list is locked? It changes as a new version, with the old one kept, so rejecting v2 costs nothing while v1 still exists. The contract never gets edited silently mid-build.
Can I skip the storyboard for a short video? A 60-second video has no room to recover from a wasted scene, so short is the worst place to skip it. Skipping the document moves the decisions into the render, where they cost the most.
To see the method on your own product, send the URL: twenty short videos come back, and you pick the one to finish.