Make an animated explainer video in this order: decide the one sentence the viewer should believe when it ends, cut that sentence into scenes with one idea each, build the visuals, review still frames before you pay for any motion, and write the narration last, to the finished picture. The order is the method. Across sixty-odd produced videos, nearly every bad one was made backwards — script first, pictures bolted on — and that reverse order is where narrated slideshows come from.
This guide is the full method, with the real numbers. It's the same method if you build the video yourself or hand the brief to someone else.
Start from the change in the viewer's head
Don't start with "what should the video show." Start with what the viewer must be able to think after watching, and derive everything from that. The planning chain, in strict order:
- Learning outcome — what can they think afterwards?
- The one idea — a single thesis sentence.
- The causal chain — orient from what they know, then macro, then micro, then one worked example.
- Beats — the chain cut into scenes, one idea each.
- Visuals per beat — described in words before anything is built.
- Narration — written last, to the finished picture.
A worked example. Say your product has an audit log. The outcome: "after watching, the viewer thinks: every run leaves a complete record, and when something breaks I read the record backwards from the symptom." The one idea: the record is always there. The chain: runs happen (they know this) → every run writes a record → the record has per-step entries → walk one failed run backwards to the broken step. Four beats. Only now do you ask what each scene looks like. Only after that, what the voice says.
One rule pays for the whole exercise: if a beat has no visual, the beat isn't understood yet. A scene you can't picture is a scene you haven't actually thought through, and noticing that on paper is free. Noticing it in a finished render is not.
Write the one idea as a sentence
Every script we produce opens with a mandatory field: the one idea, in one sentence — everything in the video exists to make it feel obvious. Not the topic. A claim.
Two tests for your sentence:
- Is it falsifiable? "Our integrations are powerful" fails. "You connect a source once and your agent's knowledge stays current on its own" passes — a viewer could check it.
- Does everything on screen serve it? The one idea is a deletion criterion. Any scene that doesn't push the sentence toward obvious gets cut, no matter how good it looks.
The same discipline applies one level down: each scene gets its own thesis
line before any prose exists. If you can't name a scene with its idea
(waits-for-all, read-it-backwards), the scene has more than one idea. More
on that in one idea per scene.
Show the real product, or don't show a product
In our review history, the accepted videos were built from the product's real shipped surfaces — real tables, real values, real run logs — with motion as the only invented layer. The rejected ones invented their content. Real artifacts are what separate "looks plausible" from "is true."
The cheap version of the protocol: before scripting, have someone with a live account build the exact demo the video will show, run it once, and send you the configuration, the full output, and the run log. Every value on screen should trace to that record. Our rule is absolute: no source, no value — a number you can't ground stays off screen until you can ground it.
Why bother? A user who knows the product spots a fake value instantly, and a prospect who buys finds the real product doesn't match the video. Both cost more than one demo run.
Lock the scene list — it's a contract
The scene list is the central planning artifact, and its defining property is that it's binding: once approved, production builds exactly those scenes. No drive-by additions. Changes are new versions, never silent edits.
Each scene entry carries four things:
- a name that states its idea,
- a duration estimate (design targets from real scripts: 6–8 scenes, 8–12 seconds each, 60–90 seconds total),
- the visual, described concretely enough to build from, and
- a beat intent — what the viewer must take from the scene. That line is the brief for whoever writes narration later. It never goes on screen.
Add a continuity note per boundary: each scene's exit state must equal the next scene's enter state. Viewers can't name a continuity break — they just report the video feels "jarring." Plan it; don't eyeball it in the edit.
If you want the visual side of this stage in depth, see the storyboard guide.
Review stills before you pay for motion
This is the highest-leverage habit in our whole pipeline, and anyone can adopt it: split production hard into two phases. Phase one builds only the static set piece and renders still frames — the money shot, the final settled frame, and one still per camera framing the script uses. Then stop. Motion, narration, and final render happen only after someone approves the stills.
The economics are blunt. One look at one frame catches the invented-UI failure class at roughly 5% of a finished video's cost. Everything expensive — animation, voiceover, rendering, the reviewer's watch time — sits downstream of decisions fully visible in a static image: is the layout right, is the content real, is anything cropped.
We learned this the hard way. One production batch went to full render without the gate and nine of ten videos were rejected. After the gate went in, the next cold batch passed first review five out of five.
Two refinements from the field:
- Review every camera framing, not just the hero frames. Two builds shipped croppings that cut the set piece at both edges because only the money and final framings were reviewed.
- Never accept a written claim as a substitute for a frame. "Looks good on my end" is not a still. Reviews come back as images.
The general principle: put an approval gate at the cheapest artifact that exposes the most expensive failure class. For explainer video, that artifact is the still frame.
Write the narration last
The intuitive pipeline — write the voiceover, then illustrate it — is where text-walls-with-pictures come from. Narration comes dead last, written to the locked visuals, for three reasons:
- Sync only works in one direction. Words written to a finished picture can land the key word on the key visual moment. Visuals bolted onto fixed narration never sync — they float.
- Division of labor. The narration says what the picture can't show: the why, the name, the caveat. If the words lead, the picture ends up merely illustrating them. Corollary: never put a sentence on screen that the voice already says.
- Cheap edits stay cheap. In our system a scene's final length is the larger of its visual minimum and the audio plus a 0.7-second breath. The voice may extend a scene; it can never compress the picture. So a wording fix re-times itself, and the cheapest revision class (words) never touches the expensive class (picture).
Pacing math you can use today: a narration voice reads about 1.9 words per second, so a 9-second scene holds one short sentence and a 12-second scene holds two. Write complete sentences that explain what's on screen — the full register, with real rejected-vs-accepted lines, is in the script guide.
Budget for revision — the real numbers
From our production records, not estimates: simple videos took 4–6 revisions. Flagship videos took 13, 16, and 24, across three staged versions each — a first build, a rebuild from review, and a final restage. About 27% of all mainline production commits were revision-shaped, and counting rejected parallel attempts, roughly half of all production work was response to review.
Plan for that. The first-pass build is about half the real effort, whoever does the work. Two habits make the revision half cheap: never overwrite a version (keep every take renderable, so rejecting one costs nothing), and treat a failed video as a restage, not a patch — polishing a structurally wrong video is the expensive way to keep it wrong.
FAQ
Can I write the script first if writing is how I think?
Write the beats and the beat intents first — that's thinking, and it belongs early. What waits until the visuals are locked is the narration prose itself, because the exact words carry the timing.
How long should the video be?
60–90 seconds for a single concept. The finished cores of our produced videos run about 54–124 seconds, and the tight ones are 6–8 scenes with no dead holds. Longer runtimes buy less than they cost — drop-off scales with length.
What if I can't describe a scene's visual?
That's the method working. The inability to picture a beat is the earliest possible failure detector — it means the beat isn't understood yet, and it fires before any money is spent. Fix the thinking, not the drawing.
Do I need to be an animator to use this method?
No. Every gate in it — the one-idea sentence, the scene contract, the still review — is a planning and judgment step. If you're starting from zero on the production side, begin with the broader how to make animated videos guide.
If you'd rather judge finished directions than build them: send us your product's URL and pick from twenty candidate cuts in 24 hours.