A good explainer video shows the real product doing one real thing per scene, and it uses timing to carry the meaning.
You have probably watched a draft that felt lifeless without being able to say why. The animation was smooth, the colors were right, the script said true things. Across sixty-odd graded builds of our own, polish almost never explained the rankings. Diversity, motion, cleanliness, and harmony did, and each cost us a video that shipped wrong before we could state it as a rule.
Picture a 90-second explainer for a deploy tool: a queue of incoming commits, three build workers, and a status table that fills in as builds finish.
The picture teaches, the voice explains
Most videos get written script-first, and that order produces the genre's most common failure: a screen that restates the voice in text at the same moment. When both channels carry the same words, they compete for the same job, and the viewer reads instead of watches.
The screen owns motion and state, and the voice owns reasons. When a build fails, the worker's ring turns red and a ✗ lands in the status table while the voice explains why a failed build stops the release. A label may name a thing ("Queue"). The moment it starts explaining, it has taken the narrator's job.
- Watch it muted. If the whole argument reads off the screen, delete every on-screen sentence the narration also says.
- Write the script after the visuals. Narration written first produces pictures that merely illustrate (how to write it).
Timing carries the causality
Film has no arrows. When a viewer concludes that a worker wrote a row into the status table, the belief came from timing: the ring lit, then the row landed. Viewers infer cause and effect from when things happen, so timing decisions are meaning decisions.
In the renders that graded well, cause led effect by about 0.7 seconds. Simultaneous events read as coincidence, a long gap reads as two unrelated events, and at around 0.7 seconds the second event reads as a consequence of the first. We did not pick the number; the approved renders kept doing it.
- Ask every animation to name its sync partner. The ring lights with the row landing; the queue count drops as a commit enters a worker. An animation with no partner is decoration, so cut it or pair it.
One thing is focal at a time
When three things move at full strength at once, the viewer picks one at random, usually the wrong one. Dimming is the fix: everything that is not the current subject drops to about a third of its strength. When worker two is the story, workers one and three keep working at 35% brightness, and the eye goes where the video points.
Size has a floor too. One of our builds staged its climax at about 1/40 of the frame, and no viewer could feel that it happened (the rejection, verdict included). Three fixes for an undersized payoff:
- Push the camera in. A tighter framing makes the same event fill the frame.
- Scale the element up. The payoff element can grow for the beat.
- Restage the event. Move the payoff onto the surface the viewer is already watching.
A hold is alive or dead
Narration runs longer than animation, so every video has stretches where the picture is done and the voice is still talking. One of our measured builds froze for nearly half its runtime and died in review (the measurement). A short hold after a payoff gives the viewer a breath. Before anything has happened, the same hold is dead air.
- Keep ambient motion in every hold. A ticking cell or a slow camera drift across the filled table is enough.
- Cap any dead hold at three seconds. Past that, the viewer is looking at a poster.
- Re-pace the beats so nothing settles early. When each beat lands as the voice names it, long holds never form.
The camera moves between ideas and cuts within one
A camera move tells the viewer the subject has changed. A cut just changes the angle on the subject they already have. We built the same topics twice, and the rejected takes improvised their geometry scene by scene and kept cropping content, while the accepted takes moved one continuous camera between named framings over a fixed layout (the counts). The tooling and code volume were similar, so the camera work carried most of the grade.
- Move between ideas, cut within one.
- Let every camera ease settle before the beat it frames. A camera still drifting during a payoff steals it.
- Hold the camera still when the frame is dense. At the densest moment, the camera does nothing.
Show the real product
The built-twice comparison exposed a larger difference. Every rejected take invented its display surface — a hand-built table while the product's real table sat unused — and the accepted takes drew on real surfaces throughout (the exact counts). Viewers who know the product notice invented UI instantly, and viewers who don't still sense they are watching a brochure.
Real things visibly running are spectacular on their own: the queue drains commit by commit, the workers finish out of order like real machines, the table fills row by row. If a concept cannot be shown truthfully with real surfaces, change the concept, not the honesty.
Shuffled timing reads as a real system
Real systems do not finish their work in order at even intervals, so parallel work that lands in a visibly shuffled order reads as real. The speed of a stagger carries tone as well: a slower cadence reads as a narrator pointing, a faster one as a machine sweeping. And even a well-made beat wears out — one technically clean build repeated its best beat five times and drew the one-word review "boring" (the exact cadences and rhythm rules).
The frame keeps a record
In the builds reviewers loved, fresh events pulsed to full strength, decayed to about 35%, and stayed there, so the frame accumulated a visible record of what had happened. A video that resets to a clean frame after every beat teaches nothing cumulative. By second 80 of the deploy video, the status table itself is the proof that work happened.
Repeated runs spend attention
Viewers give a machine's first end-to-end run their full attention, the second less, and the fifth almost none, so use the fewest full runs that prove the point; one graded build got stronger going from seven runs to three. The strongest closing frame in our corpus re-fired the opening query and selected zero rows, because every row had already been processed. The empty result proved the thesis by contrast, and the staging depended on each scene carrying one idea.
A short checklist
- Watch it muted. If the argument reads off the screen, the text is doing the voice's job.
- Pause at random several times. Repeated still frames mean dead holds.
- Ask each animation to name its sync partner. No partner means decoration.
- Check that the climax fills at least 1/40 of the frame. Below that, the payoff did not happen.
- Check that camera moves land on new ideas and settle before the beat.
- Look for uniform timing. Even intervals have the rhythm of a template.
- Count the full end-to-end runs. Keep the fewest that prove the point.
- Look for a surface that fills up over the video. If nothing accumulates, nothing was accomplished.
- Ask whether every surface is the product's real one. A viewer who knows the product will flinch at a fake, and every other viewer feels the flinch without knowing why.
FAQ
What's the single most common failure? The dead hold: everything animates in a scene's first three seconds, then freezes while the voice finishes. The pause-at-random test catches it.
How long should a good explainer be? Most products fit 60 to 90 tight seconds — roughly six to eight scenes of 8 to 12 seconds, one idea each (length).
Can you judge a video before it's fully produced? Largely yes, from stills. Two static frames per scene, reviewed before any motion exists, catch most fatal errors at about 5% of a finished render's cost.
Does following these rules guarantee a good video? No. One build passed every written gate we had and still graded worst of its batch. The rules remove the known ways to fail; the remaining gap is taste, so we treat a scene as done only after its rendered frames have been looked at.
To see this on your own product, send us the URL. Twenty short candidate videos come back, and you pick the ones worth finishing.