An explainer video should be built from your product's real surfaces — real components, real labels, real output from a real run. Invented UI is the most common reason product videos feel like brochures instead of demonstrations, and it's the failure viewers punish hardest, whether or not they can name it.
We learned this the measurable way. Across sixty-odd produced videos, four topics ended up built twice — once rejected for visual quality, once accepted, same tooling, days apart. A census of the two sets found only three disciplines separating them — similar line counts, similar component counts — and the first was this: every rejected take had invented its display surface (a custom table hand-built while the real table component sat in the library, a floating candidate list, a fake email client), while the accepted takes used the product's real shared surfaces 4 to 13 times each. Effort was similar. Truth was the difference.
Fake UI fails with both audiences
There are two kinds of people watching your explainer, and invented UI loses both of them.
Viewers who know the product spot a fake surface instantly. A dashboard the product doesn't have, a scorecard nobody has ever seen, a settings panel with the wrong fields — to an existing user this reads the way a stock photo of "your team" reads. The video stops being about the product and starts being about the video.
Viewers who don't know the product can't point at the fake, but they sense it. The tell is texture: information floating in chips and pills beside a diagram, data with no container, values parked on top of labels. Real software keeps data inside things — rows, panels, fields. When a video draws annotations instead of surfaces, something in the viewer files it as marketing and discounts everything the voice says. In our review notes, the verdict on an invented panel dressed up in the product's real colors was three words: "these look disgusting." Borrowing a real surface's tokens does not make an invented surface real.
And there's a third, quieter failure. A prospect watches the video, buys, and opens the product — and the screen from the video isn't there. That's not a craft problem anymore. That's a refund.
A cursor click is a product claim
Here's the rule we hold ourselves to, and it's worth demanding from anyone who makes video for you: a cursor may only operate controls the product truly has.
An animated explainer has some honest fictional license. Panels can dock on their own, surfaces can slide in, a layout can rearrange itself — that reads as the film directing your attention, the way a documentary cuts between shots. Nobody believes the panels move themselves in the real app.
But the moment a cursor clicks a button, the video is asserting that the button exists and does that thing. If it doesn't, the video just made a product claim on your behalf that your product can't keep. Chrome may move of its own accord; hands may only touch what's real.
The same logic covers staged outcomes. One of the worst-graded videos in our corpus had its failure moment constructed for the camera — the "system catching its own error" had been arranged, not caught. The review was six words: "don't see anything cool, also false." Both halves kill a video. An invisible premise bores; a staged one burns trust. If a concept can't be shown truthfully with the product's real surfaces, the concept is wrong. Change the concept, not the honesty.
The grounding table: how to keep every frame true
Good intentions don't keep frames true. A process does. Ours has four steps, and every one of them transfers to any team making product video:
1. Request a real artifact before anyone writes a script. Someone who can operate the live product builds the exact demo configuration, runs it once with a real input, and sends back four things: the configuration exactly as built, the full real output, the run log with real durations, and anything that surprised them about the run. That last item is the gem — the gap between what an operator expected and what the product did is exactly where viewers will be confused too.
2. Store the response verbatim. It lives in the video's folder, untouched. Every value the video shows should trace back to it.
3. Build a grounding table into the script. Every on-screen string, number, label, and color gets a row mapping it to its product source. A value with no source yet gets flagged as pending. The rule is absolute: no row, no value. A pending value stays off screen until it's grounded — you ship around it, you never fake it.
4. Re-derive at every build. Product truth drifts. Labels get renamed, colors get retuned, a metric changes units. Values are re-read from the product source each time, never trusted from a previous video. When sources disagree — the docs say one thing, the running product another — the running product wins, and the divergence gets written down.
This sounds heavier than it is. In practice it's one email to someone with a live account, sent before the script locks. The one-sentence theory behind it, from our own production records: quality became a porting problem, not a design problem. Every rejected video was designed — invented diagrams, invented demo content. The accepted ones were ported from the product's own shipped surfaces, with motion as the only original layer.
Animate the concept, record the live product
"Show the real product" does not mean every video is a screen recording. There are two jobs, and the routing rule between them is one line: animate the concept, record the live product.
- Concepts get animation. How your data model fits together, why a run behaves the way it does, what happens when two branches finish at different times — these are invisible in a screen recording. Animation exists to stage what a screenshot can't show: causality, timing, structure. The surfaces in the animation are still ported from the real product; the motion is the only invented layer.
- The product in action gets recorded. The "click run and watch it go" beat should be the actual product running. Rebuilding your real UI in animation is expensive, always slightly wrong, and ages the moment you ship a redesign. Cut to the real thing.
The strongest showcase videos intercut the two: animation to explain the idea, live capture to prove the product does it. What never works is the third option — animation pretending to be the live product, which is the fake-UI failure wearing a nicer coat.
If you're deciding which of the two jobs your video is doing, the demo-vs-explainer breakdown walks that choice; the storyboard guide covers how to lock surfaces per scene before anything gets built.
Catch it in a still, not a finished render
The economics of product truth are lopsided in your favor, if you check early. Invented UI, wrong surfaces, and broken framing are all fully visible in a single static frame — no motion, no voiceover, no soundtrack needed.
So we gate on stills: before any motion or narration, a build renders two static frames — the money shot and the final frame — and stops for review. One look at one frame catches the invented-UI failure class at roughly 5% of a finished video's cost. Before we installed that gate, one production batch sent ten videos to full render and nine were rejected. After it, the next cold batch passed five out of five on first review.
If you're commissioning video rather than making it, this converts directly into a demand: ask your vendor for still frames before they animate, and check the stills against your real product. Is that our actual table? Are those real field names? Would a user recognize this screen? Five minutes of looking at images beats ninety seconds of watching a finished video you now have to reject. It's the single cheapest quality lever a buyer has — more on why videos fail in why explainer videos look cheap.
FAQ
Our UI isn't pretty yet. Should we still show it? Show it, staged well. Lighting, framing, focus, and motion do enormous work — a real screen shot with care reads better than a beautiful fake. And an animated explainer built from your real components can be more composed than a raw recording while staying true. 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's a claim, and it will be tested by every prospect who signs up.
Isn't animation by definition "not the real product"? The motion is invented; the surfaces shouldn't be. An animated version of your real table filling with your real output is a truthful dramatization. An invented dashboard is fiction. Viewers hold the two to completely different standards, even when they can't articulate why.
What if the vendor has never used our product? Then they should ask you for a grounding artifact — a real configuration, a real run, real output — before they script. If a vendor never asks you for real product material, you already know where their screens will come from.
If you want to see the method applied to your product, send us your URL and judge the candidate directions — every frame rendered from your real UI — before you spend anything.