A storyboard for an animated explainer video is a locked scene list: one row per scene, each with 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. You don't need drawings — you need a document precise enough that anyone can look at the finished scene and say "that is, or is not, what we agreed."
That last property is the whole point. Across sixty-odd produced explainers, the storyboards that worked were never the prettiest. They were the ones that functioned as contracts.
The scene list is a contract, not a mood board
Most storyboard advice treats the board as inspiration: sketch some frames, get a feel, stay flexible. That flexibility is where budgets die. The working rule in our shop: once the scene list is blessed, production builds exactly those scenes. No drive-by additions, no "while I was in there." A change is a new version of the document, never a silent edit.
Why so strict? Because everything expensive in video — animation, voiceover, rendering, the reviewer's watch time — sits downstream of the scene list. In our production records, roughly half of all work is response to review notes. A vague storyboard doesn't reduce that number. It guarantees it, because the first review becomes the first time anyone finds out what the video actually is.
A contract-grade storyboard moves that discovery upstream, to the cheapest possible artifact: a text document you can argue about in an afternoon.
What a storyboard row must contain
Five fields per scene. If a row is missing one, the scene isn't planned yet.
- A name. Short, specific, stateable:
the-fast-branch-waits, notscene 4. If you can't name what the scene does, you don't know what it does. - A duration estimate. Scenes in good explainers run about 8–12 seconds; whole videos, 60–90. The estimate forces a scope decision per scene before anything is built.
- The visual, described concretely enough to build from. The test: could someone who wasn't in the room build the scene from the words alone? "We show the workflow running" fails. "Both branches fire from the router on the same frame; the email branch finishes in 2 seconds and turns green; the merge step sits visibly dimmed even though one input has arrived" passes.
- The beat intent. One sentence stating what the viewer must take from the scene. This is the brief for whoever writes the narration — it is not text to put on screen.
- The boundary state. What the frame looks like when the scene ends, which must equal what the next scene opens on. Continuity is planned here, in writing, and then checked against the actual frames — never eyeballed in the edit.
Here's a real row shape, generalized:
4. the-fast-branch-waits (~9s) — Both branches fire from the router on the same frame. The email branch finishes in 2s (green); the enrichment branch is still working; the merge step sits visibly dimmed even though one input has arrived. Merge lights up only when the slow branch lands. Beat intent: the join waits for ALL inputs — the viewer should feel the wait, not be told about it.
Notice what the format forces. The claim ("joins wait for all inputs") is made by frame timing the viewer can see. The intent line hands the narration writer their brief. And the scene is checkable — a reviewer can compare the built scene against the row, word by word.
One rule that should govern every row: each scene teaches exactly one thing. A row whose intent line contains "and" is two scenes. That rule has its own guide: one idea per scene.
What the document around the rows carries
The rows are the middle of the storyboard, not the whole of it. A contract-grade document also states:
- The one idea. One declarative sentence the entire video argues. Any scene that doesn't push that sentence toward "obvious" gets cut, however good it looks.
- The arc, named. Outside-in zoom, capability-first, problem-first — whichever, say which and why. Naming the arc forces a real decision instead of default chronology.
- Run economy. Count the end-to-end demonstrations and justify each one. Viewers pay full attention to a machine's first run and almost none to its fifth; one of our builds went from 7 runs to 3 and got stronger. The accepted pattern is one run shown three ways, never three conjured runs.
- A grounding table. Every on-screen string, number, and label maps to a real product source. The rule is absolute: no row, no value. A value you can't source stays off screen — you ship around it, you don't fake it. Invented demo content is the most common tell of a cheap explainer, and a viewer who knows the product spots it instantly.
Stills before motion: the review that costs 5%
Split production hard into two phases. Phase A: build only the static scenery and render still frames — the money shot, the final settled frame, and one still for every camera framing the storyboard uses. Then stop. Phase B — motion, narration, final render — happens only after someone approves the stills.
The economics: one look at one frame catches the worst failure classes — wrong layout, invented interface, cropped content, brochure-instead-of-product — at about 5% of a finished video's cost. Everything a still can expose is a decision that motion only makes more expensive to reverse. A bad frame costs minutes to catch as a still and hours to catch as a finished render, plus the reviewer's trust either way.
One production batch of ours went to full render without the gate: nine of ten videos were rejected. After the gate was installed, the next cold batch passed first review five out of five.
Two refinements, both paid for:
- Review every camera framing, not just the hero frames. Two of our builds shipped with the scenery cropped at both edges because only the money and final framings had been checked. Each distinct framing is its own chance to be wrong.
- Never accept "looks good" as a substitute for a frame. Reviews come back as images. A written claim that framing was verified is worth nothing — we have the false ones on record.
If you're commissioning a video rather than making one, this is the clause to ask for: still frames for approval before any animation begins. A vendor who resists is asking you to buy the expensive phase blind.
Where the storyboard sits in the order of work
The storyboard comes after the concept and before the narration — and that order is load-bearing. Write the beats, describe the visuals, lock the scene list, build the statics, pass the still gate, and only then write words to the finished picture. Narration written to a picture can land its key word on the key visual moment; visuals bolted onto a finished script never sync. The full argument lives in the scriptwriting guide, and the end-to-end process in how to make an animated explainer video.
FAQ
Do I need to be able to draw? No. The storyboards behind our produced videos are text: named scenes, durations, visuals described in build-ready words, beat intents. The first pictures anyone sees are rendered stills of the actual scenery — which are better than sketches, because they're the real thing at 5% of the cost.
How many scenes does a 60–90 second video need? Usually six to eight. The count falls out of the ideas: cut the video's causal chain into beats, one idea per beat, one scene per beat. If you have fourteen scenes for 75 seconds, some scenes are carrying half an idea; if you have four, some are carrying two.
What happens when something has to change after the list is locked? It changes as a new version, with the old one kept. Versioning is what makes honest review cheap — rejecting v2 costs nothing when v1 still exists. What you never do is edit the contract silently mid-build.
Can I skip the storyboard for a short video? The storyboard is where the thinking happens, and short videos need the thinking most — a 60-second video has no room to recover from a wasted scene. Skipping the document doesn't skip the decisions; it just moves them into the render, where they cost the most.
If you'd rather judge finished frames than write rows, send us your product's URL and pick from twenty rendered directions instead.