An explainer video should be built from your product's real surfaces: real components, real labels, real output from a real run. Invented interface is the most common reason product videos read as brochures instead of demonstrations, and viewers discount it even when they can't name what went wrong.
A real product is a set of ordinary panels, a video wants a spectacle, so the maker draws a grander surface than the product has. Take Petal, an invoicing product: a list of invoice drafts, a send button, statuses that flip from sent to paid. A video can show Petal as it is, or as someone wished it looked.
We built four topics twice each: one take rejected for visual quality, one accepted, same tooling, days apart. Line counts and component counts were similar, so effort wasn't the difference. Every rejected take had invented its display surface — a hand-built table while the real table component sat in the library, a floating candidate list, a fake email client. The accepted takes used the product's real shared surfaces 4 to 13 times each.
Fake surfaces fail with both audiences
Viewers who know the product spot the fake instantly. A "revenue command center" Petal never shipped reads the way a stock photo of "your team" reads, and the video stops being about the product.
Viewers who don't know the product sense it through texture. Real software keeps data inside things — rows, panels, fields. Invented visuals float information in chips and pills and park values on top of labels. The viewer files that texture as marketing and discounts everything the voice says. Dressing the fake in real brand colors doesn't help: an invented panel wearing the product's real tokens drew a three-word review in our corpus, "these look disgusting."
A third failure arrives after purchase. A prospect watches the video, buys, opens Petal, and the screen from the video isn't there. That is a refund, not a craft note.
A cursor click is a product claim
Animation gets some honest fictional license. Panels can dock on their own and layouts can rearrange themselves, because that reads as the film directing your attention. Nobody believes the panels move themselves in the real app.
The license ends at the cursor. A cursor clicking a button asserts that the button exists and does that thing. If the video shows a cursor clicking "Auto-chase overdue invoices" and Petal has no such button, every prospect who signs up will test the promise. So a cursor may only operate controls the product truly has.
Staged outcomes break the same rule. One of the worst-graded videos in our corpus arranged its payoff for the camera instead of catching it, and the reviewer called it false. If a concept can't be shown truthfully with real surfaces, change the concept, not the interface.
The grounding method
Four steps keep every frame traceable to the product:
- Request a real artifact before anyone writes a script. Someone with a live account builds the demo configuration, runs it once with real input, and sends back the configuration, the full output, the run log with real durations, and anything that surprised them. The surprise item matters most: where an operator's expectation diverged from the product is exactly where viewers get confused.
- Store the response verbatim. It lives in the video's folder, and every on-screen value traces back to it.
- Build a grounding table into the script. Every string, number, label, and color gets a row naming its product source. No row, no value: an ungrounded value stays off screen. You ship around it, you never fake it.
- Re-derive at every build. Labels get renamed, colors get retuned, metrics change units. Values are re-read from the source each build, and when sources disagree, the running product wins.
In our production records, every rejected video was designed — invented diagrams, invented demo content. Every accepted one was ported from the product's shipped surfaces, with motion as the only original layer.
Animate the concept, record the live product
Showing the real product doesn't mean every video is a screen recording.
- Concepts get animation. How Petal decides an invoice is overdue, and what happens when a payment lands mid-cycle, are invisible in a recording. Animation stages what a screenshot can't: causality, timing, structure. The surfaces stay ported from the product; the motion is the invented layer.
- The product in action gets recorded. The "click send and watch the invoice go out" beat should be the product running. Rebuilding your UI in animation is expensive, slightly wrong, and ages at your next redesign.
Strong videos intercut the two: animation explains the idea, live capture proves the product does it. Animation pretending to be the live product never works — it fails exactly the way invented UI fails. The demo-vs-explainer breakdown walks the choice between the two jobs, and the storyboard guide covers locking surfaces per scene.
Check the stills before the motion
Invented UI, wrong surfaces, and broken framing are all fully visible in a single static frame, so the cheapest place to catch them is before animation starts. We gate our own builds on still frames; the batch that taught us that gate, numbers included, is in how to make an animated explainer video.
If you're commissioning rather than making:
- Ask your vendor for still frames before they animate. Five minutes on images can save you from rejecting a finished video.
- Check every still against the live product. Is that your actual invoice table, are those real field names, would a user recognize this screen? A frame that fails these questions fails harder in motion.
The other failure modes that separate rejected videos from accepted ones are cataloged in why explainer videos look cheap.
FAQ
Our UI isn't pretty yet. Should we still show it? Show it, staged well. Framing, focus, and motion do enormous work, and a real screen shot with care reads better than a beautiful fake. What you can't do is ship a video whose screens your users will never find.
Can the video show a feature that hasn't shipped yet? As concept animation, clearly staged as concept, yes. As a cursor clicking through UI that doesn't exist, no. That click is a claim, and prospects test claims.
Isn't animation by definition "not the real product"? Animation invents the motion, not the surfaces. Your real invoice table filling with your real data is a truthful dramatization. An invented dashboard is fiction. Viewers hold the two to different standards, even when they can't say why.
What if the vendor has never used our product? Then they should ask for a grounding artifact before they script: a real configuration, a real run, real output. A vendor who never asks for real product material is going to invent the screens.
To see this on your own product, send us the URL. Twenty short candidate videos come back, and you pick the ones worth finishing.