An explainer video script is a scene list written backwards: first decide the one sentence the viewer must believe by the end, then design the picture for each scene, and write the spoken words last. Most weak explainers were made in the reverse order — words first, pictures bolted on afterward — and that order is where narrated slideshows come from.
This guide covers the working order, the one-idea-per-scene rule, the anatomy of a real scene list, and rejected lines from our own production record next to the rewrites that shipped.
Write the visuals before the words
The intuitive pipeline is concept → script → visuals that illustrate the script. It feels natural because that's how blog posts work. For video it fails. The order that survives review:
- Learning outcome. What must the viewer be able to think after watching? Pull it from your docs and your support tickets, not from vibes.
- The one idea. A single declarative sentence the whole video argues.
- The causal chain. Sequence the ideas: orient from what the viewer already knows, go macro to micro, then work one example through mechanically.
- Beats. The chain cut into scenes, one idea each. This becomes the locked scene list.
- Visuals per beat. Describe each scene's picture and motion in words, before any production.
- Narration last. Written to the finished picture, never the reverse.
Two reasons the order matters. First, sync only works in one direction: a line written to a locked picture can land its key word on the key visual moment, but a picture animated to fit fixed words never lands — it floats, and the whole video reads as slides with a voice on top. Second, the two channels have different jobs. The picture shows state; the voice says what it means. When the words come first, the picture ends up illustrating the words, which makes it redundant.
The rule we'd tape to any writer's monitor: if a beat has no visual, the beat isn't understood yet. Not being able to describe the picture is the earliest failure detector you have, and it fires before any money is spent.
Start with the one idea
Every script we produce opens with a mandatory field:
The one idea: one sentence. Everything in the video exists to make it feel obvious.
Not the topic. Not a list of features. One claim — and the acceptance test is emotional: the viewer should finish the video feeling the sentence is obvious, not merely stated. Real examples from our curriculum work, shape preserved: "an agent is just a workflow that can reason." "Every source normalizes to one file object, so any producer wires into any consumer."
Three tests for your own thesis sentence:
- Is it falsifiable? "Our integrations are powerful" fails. "You connect a source once and your product's knowledge updates itself instead of going stale" passes.
- 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.
- Does this video own it? In a series, each video owns exactly one idea and defers its neighbors. When two videos both half-teach a concept, both fail.
One idea per scene
The one-idea rule repeats at scene level, and it comes with a built-in test:
the scene's name. In our scripts every scene is named with a slug that states
its idea — waits-for-all, read-it-backwards, a-block-that-holds-blocks,
swap-the-container. If you can't name a scene with its idea, the scene has
more than one idea, and it needs to be split.
Each scene also carries a beat intent: what the viewer must take from the scene. The intent is written for whoever writes the narration later — it never goes on screen as text. This split is load-bearing: the picture makes the claim, the intent tells the voice what to say about it. We wrote a full guide on this rule alone at one idea per scene.
The anatomy of a real scene list
A finished script isn't prose with stage directions. It's a contract, and once the stakeholder blesses it, production builds exactly those scenes — changes are new versions, never silent edits. Beyond the one idea, the document names its macro arc, justifies its run economy (how many times the demo "runs" on screen), grounds every on-screen value in a real product artifact, locks the scene list — name, duration, a visual described concretely enough to build from, and the beat intent, per scene — and states the continuity contract at every scene boundary. Each field makes the script checkable: a reviewer can look at a built scene and say "that is or isn't what we agreed." The full row-by-row anatomy, with a worked contract-grade scene entry, lives in the storyboard guide.
A full video is short: 6–8 scenes, 8–12 seconds each, 60–90 seconds total. More on runtime in how long should an explainer video be.
Bad lines vs. good lines
Every rejected draft in our record failed in one of two ways: performing instead of explaining, or compressing instead of condensing. Here is one real pair from each, rejected line first, shipped rewrite second.
Performing instead of explaining — the closing scene of a video about run logs:
- ❌ "Every run writes one of these. Nothing about a run is a mystery."
- ✅ "Every run produces a log automatically. When a workflow does something unexpected, the log is the first place to look."
"Nothing about a run is a mystery" is a marketing aphorism. It asserts a feeling instead of telling the viewer what to do. The rewrite gives the behavior: where to look, and when.
Compressing instead of condensing — the opening scene of a video about loops:
- ❌ "Some jobs are a list — same steps, every item. The Loop is a block that holds blocks: the inside runs once per item."
- ✅ "Some jobs are a list — the same steps need to run for every item. For that, the platform has the Loop: a block that holds other blocks. Whatever you place inside it runs once per item."
The rejected version isn't wrong; it's clipped — three stubs doing the work of sentences. The rewrite keeps the same content with its connective tissue intact. Condensing removes fluff and keeps grammar; compressing removes grammar and keeps keywords. The full register, with every pair from our record, is in explainer video voice over.
Write the closing line first
One narration line is allowed to exist before the visuals: the closer. Write it down first, because the whole video aims at it — the scenes are choreographed toward that final sentence, and everything else is written after the visuals lock. Hold the closer to the same standard as every line: behavior or payoff, never a slogan, and it still gets a verb. A director-approved closer from a real video: "That's the whole model. A trigger starts it, each block runs as soon as its inputs arrive, data moves through connection tags, and the run ends at the Result." One spoken sentence, the entire video compressed.
FAQ
How many words is a 60–90 second script? A production read runs about 1.9 words per second, and each scene wants a short breath after its line. A 9-second scene holds roughly one short sentence of 15–18 words; a 12-second scene holds two. A 90-second video is around 150–170 spoken words. If that sounds thin, good — the picture is carrying the rest.
Do I write the script or the storyboard first? They're the same artifact at different resolutions. The scene list — names, durations, described visuals, beat intents — is the script, and the storyboard renders those descriptions into frames. The spoken words come after both.
Does every scene need narration? No. A silent beat that holds its authored duration is a legal, useful choice. Not every scene needs words; every scene needs an idea.
Can I reuse my website copy as the script? Read it aloud first. Web copy is written to be scanned; narration is written to be said. If a line would embarrass you spoken to a colleague across a desk, it isn't narration yet.
If you'd rather pick a direction than write one from scratch, send us your product's URL and judge twenty candidate scripts as rendered video instead.