The biggest explainer video mistakes are planning mistakes, made before a single frame moves: starting from a topic instead of a claim, deciding the video in adjectives, writing the narration first, going to render without reviewing a still, leaving revision unplanned, and explaining at the wrong altitude. The visual failures everyone can point at — frozen frames, invented interfaces — are mostly downstream symptoms of these six, which is why fixing a broken video in the edit never quite works.
A claim costs nothing to rewrite while it is still a sentence. It costs more once it is a described scene, more again as a rendered still, and by the time it is a finished 90-second render with voice and music, changing it throws away hours. All six mistakes let a question that a sentence could have settled travel downstream and get answered at render prices.
Picture a 90-second explainer for an analytics dashboard: events stream in from an app, charts fill as events are counted, a funnel view shows where users drop off. All six mistakes below happen to that video. In our production records, nearly every rejected build traced back to one of them — the visual failure registry catalogs what the wreckage looks like on screen.
1. Starting from a topic instead of a claim
Ask a team what their video is about and the answer is usually a noun — "our analytics", "the funnel view". A noun feels like an answer, so scripting begins. But a topic gives the video no way to decide what to leave out. Every feature is equally related to "our analytics", so every feature gets a scene, and the finished tour is competent, complete, and impossible to remember.
The cost lands in review. Without an agreed claim there is no agreed definition of done, so reviewers give contradictory notes, each individually defensible, and the revision rounds that follow are the team discovering, at animation prices, what the video should have been about.
- Write one falsifiable sentence before any script exists. "Our analytics are powerful" fails — no viewer could find it false. "You can see where users drop off within a minute of connecting your data" passes, because a viewer can watch for exactly that.
- Use the sentence as the deletion criterion. Any scene that doesn't push it toward feeling obvious gets cut, however good it looks alone.
- Give every scene its own one-sentence claim. One idea per scene is this rule applied recursively.
2. Deciding the video in adjectives
The brief says "clean, modern, dynamic, not too corporate", the kickoff produces a mood board, and everyone leaves believing alignment happened. It didn't — adjectives don't constrain pictures. Five people now hold five different videos in their heads, and the words fit all five.
The misalignment surfaces at the most expensive moment, the first render, as "this is not what I imagined." The sentence is literally true and nobody's fault, since no picture was ever agreed on. The project then spends its revision budget converging on taste.
The quieter form of the same mistake is a beat nobody can picture. "We show how easy setup is" describes a decision no one has made — "easy" is not a picture. "A chart starts filling within seconds of the API key being pasted" is a picture.
- Decide by choosing between concrete artifacts. Two thesis sentences, two beat lists, two rendered stills. A choice between two frames settles in seconds what three calls about vibe cannot.
- Reject any beat that has no visual. If nobody can say what is on screen, the beat isn't understood yet, and the scene list is the place to find that out.
3. Writing the narration first
Almost every team starts with the voiceover script, because a script feels like the natural first artifact and reads beautifully in the document. Visuals get commissioned to illustrate it, and the result is a narrated slideshow: pictures gesturing at the words, timing that never lands, text drifting onto the screen to cover for visuals that can't carry the sentence.
Narration written to a finished picture can land its key word on the key visual moment. Visuals bolted onto fixed narration only float beside it. Underneath the sync problem sits a cost problem: words are the cheapest layer to revise and pictures the most expensive, and a narration-first pipeline welds the cheap layer underneath the expensive one, so every wording change threatens animation timing.
- Author in this order: concept, beats, visuals, narration, audio. Lock the picture, then write the voice to what is on screen, saying only what the picture can't show. The funnel scene gets staged and timed before anyone writes the sentence that plays over it.
- Write the closing line first — the one exception. The whole video is choreographed toward its final sentence (how an explainer should end covers why). The full authoring order is in the script guide.
4. Going to render without a still review
In many productions the first artifact any reviewer sees is a finished 90-second render — after the animation, the voiceover, and the render time have all been spent, and before anyone checked whether the layout was right or the content was real.
We measured the cost. A ten-video batch of ours went to full render with no intermediate review, and nine of ten were rejected, every one for a problem visible in a single static frame (the full story and the gate that fixed it). As stills, those failures cost minutes each. As finished videos, they cost the batch.
Put an approval gate at the cheapest artifact that exposes the most expensive failure class. For explainer videos that artifact is a still frame, because wrong surfaces, invented interface, and broken framing are all visible without motion.
- Review two stills per video before any motion exists. The money shot — the frame the video exists to show — and the final frame. For the dashboard video: the funnel at its fullest, and the settled ending. Each judged yes or no in a glance.
- Hold vendors to the same gate. A vendor who resists showing a still before animating is asking you to buy the nine-in-ten batch.
5. Leaving revision unplanned, or unbounded
Revision plans fail at both extremes. Unlimited revisions price the chaos in and remove everyone's incentive to make any round decisive. No revision plan assumes the first render will be close, so feedback arrives as a rolling stream, each round patches the last, and version three ends up being version one with scar tissue.
Revision is not an exception you can price away — in our records it accounts for roughly half the total effort on a video (the counts). A plan that budgets zero for it converts the cost into scope fights.
- Version takes instead of overwriting them. Scripts and cuts live as v1, v2, v3 side by side, so rejecting a version costs nothing.
- Decide restage versus patch honestly. A structurally wrong video needs a rebuild; polishing it is the expensive way to keep it wrong. Our best videos were re-made, not touched up.
- Write every rejection down the same day. The note explaining why a take failed stops round four from re-shipping round two's mistake.
- Fix the number of rounds and name the change-order line. Wording, pacing, and asset swaps sit inside a round. New scenes or a new thesis are new work, quoted separately.
6. Explaining at the wrong altitude
A video for buyers that explains the algorithm, or a video for engineers that explains why efficiency matters, is accurate and still loses the room — each audience is being taught the thing it doesn't need.
The cost is length, then attention. Wrong-altitude scenes are the hardest cut because each one is individually true and well made. So the video runs two minutes longer than its job requires, and the viewer it was for checks out in the middle.
- Set an altitude ceiling before scripting. Carry only enough mechanism to make the product's behavior predictable. If a scene explains how something works under the hood, reframe it to what the thing does and when the viewer would reach for it.
- Write the exclusion list next to the scene list. Name what the video deliberately does not teach and where each cut topic lives instead — docs, another video, a screen recording.
The pattern underneath all six
Each mistake survives because it feels productive while it happens. A lush voiceover script feels like progress, skipping stills feels like speed, unlimited revisions feel like generosity, a tour of every feature feels thorough. The work isn't visibly wrong until the render, which is exactly why the render is the wrong place to find out.
Make each decision at the cheapest artifact that can carry it. A thesis is testable as a sentence, a beat as a described picture, a layout as a still. Teams that ship good explainers never let an undecided question travel downstream to where deciding it costs hours instead of minutes.
FAQ
Which mistake is the most common? Narration-first, by a wide margin, because a script feels like the natural starting point. The most expensive per incident is skipping the still review, because it lets every other mistake reach the render unseen.
We already have a finished video with these problems. Patch or redo? Diagnose first. If the thesis and structure are sound and the problems are wording, pacing, or one bad scene, patch. If the video never had a falsifiable thesis or was built narration-first, restage from a proper scene list — polishing a structurally wrong video is the slowest way to keep it wrong.
How do I audit a vendor for these mistakes before hiring them? Three questions. What is the video's one-sentence thesis? A topic answer is mistake one. What do I approve before animation starts? "The first cut" is mistake four. What does the revision policy cover? "Unlimited" is mistake five wearing a bow.
Aren't the visual mistakes — dead holds, fake interfaces — the real problem? They are the visible problem. When we rebuilt the same topics twice, rejected and accepted takes had similar effort behind them; upstream discipline separated them. Fix the process and most of the visual registry stops appearing on its own.
When you're ready, send us your product's URL. We cut twenty short videos of it, and you keep whichever ones earn a full build.