The camera is the video's attention — where it points is where the viewer looks, and how it moves tells the viewer what kind of moment this is. A product video with no camera has no attention: one of our own flagship builds was rejected with the diagnosis "no camera: one framing for 100 seconds," and that note alone sent it back for a full restage.
There's nothing physical to film in an animated explainer, which is exactly why the camera gets forgotten. The whole product diagram fits in one wide frame, so the lazy default is to leave it there and animate inside it. This guide covers what we learned instead, across sixty-odd produced videos: when the camera should move, when it should cut, when it must do nothing, and the one measurement that separated our rejected videos from our accepted ones.
The camera is life
Start with why this matters at all. A static wide shot of a product diagram — even a well-animated one — reads like a poster someone is pointing a laser at. The viewer's eye has to do all the work: scan the frame, find the active region, decide what matters. Some viewers find it. Most find something else.
A moving camera does that work for them. It pushes into the detail when the detail is the story, pulls back when the consequence lands somewhere else, and drifts just enough during a rest to keep the frame breathing. In our grading, the difference wasn't subtle: the build ranked best in one batch watched a single run of the product at three different scales — wide to see the whole machine, pushed in to watch the detail work, pulled back to watch the result land. Same content as a static version. Completely different video.
There's a second job, quieter but just as real: ambient life. A slow camera drift is the cheapest way to keep a resting frame from reading as dead — a one-line fix we apply to almost every hold. (More on holds in animation timing and easing.)
The rule: move between ideas, cut within one
If you take one sentence from this page, take this one: the camera moves between ideas, and cuts happen inside an idea.
A camera move is a signal. When the frame glides from the trigger block over to the results table, the viewer's brain files it as we're going somewhere new — a paragraph break. A cut, by contrast, is invisible connective tissue: detail, reverse angle, closer look, all inside the thought you're already in.
Swap them and the video confuses people in ways they can't name. Gliding around within one idea makes the viewer feel lost — are we somewhere new? Was that important? Hard-cutting between ideas with no move and no transition makes the video feel like shuffled slides. The grammar matters because viewers already know it from every film they've ever watched; you're either speaking it or breaking it.
Two corollaries do a lot of work:
Settle before the beat. Every camera move must finish — fully eased, fully still — before the moment it exists to frame. If the camera is still drifting when the payoff fires, the drift steals the payoff. The viewer watches the motion instead of the event.
When the content is maximal, the camera does nothing. The camera's job is to deliver the viewer to the event and then get out of the way. During the climax, a moving camera isn't energy — it's competition.
The evidence: 0 framings vs. 35–59
Here's the strongest data we have, and it comes from a controlled comparison we didn't plan as an experiment. Four videos were each built twice — once rejected for visual quality, once accepted. Same topics, same tooling, same rules available, days apart. When we ran a census on the code afterward, the takes had similar line counts and similar effort. Three disciplines separated them, and camera was one of the three:
Every rejected take had zero named camera framings. The geometry was improvised scene by scene — each scene placed its content wherever seemed right that day. The results were the classic tells: content cropped at the edges, a layout that jumped between scenes, and in one case a seven-block workflow literally cut in half because it had outgrown the frame.
The accepted takes defined 35 to 59 named framings over one fixed layout — named, as in "wide," "trigger close-up," "table detail," each one a saved position — and moved one continuous camera between them.
That's the architecture worth stealing, and you don't need our tooling to steal it: build the entire world once, as a single layout that never changes, then shoot it. Every scene is just the camera visiting a different named framing of the same world. Nothing teleports between scenes, because there's only one world for things to be in. Continuity errors — the jump-cuts and size-flinches viewers report as "jarring" without knowing why — become impossible by construction rather than caught by review.
The rejected takes had it backwards: each scene owned its own copy of the layout, and the camera was left to improvise over shifting ground. Layout problems then got "fixed" with camera work — which brings us to the pan.
The linear pan (a camera fix for a staging problem)
One failure mode deserves its own section because it looks like a camera technique and isn't. A build of ours laid out a long chain of blocks in a straight line — too wide for any frame — and sent the camera slowly panning along it. The review note: the workflow "gets cut in 2, discontinuous; also very linear and weird."
The camera wasn't the error. The camera was compensating for a layout that had outgrown the frame. Watching a linear pan feels like reading a sentence one word at a time — no shape, no hierarchy, no sense of where you are in the whole. If your set piece has to be cut up or scrolled past to fit, the staging is wrong, and no camera move fixes staging. Rework the layout into something parallel and layered — which usually means the scene was carrying too many ideas anyway (one idea per scene is the deeper fix).
Riding a run: the one time camera and motion move together
We said the camera settles before the beat. There's exactly one pattern in our graded work where camera movement and content movement overlap on purpose, and it's worth knowing because it shows why the rule exists.
The pattern: a pulse of light travels along a wire toward the block where the payoff will land, while the camera eases back along the same path to the wide framing where that payoff is visible. Motion and camera arrive together. It works because they're carrying the same idea — both are taking the viewer home for the consequence. The eye rides the pulse; the pulse leads the eye exactly where the camera is going.
That's the test for any exception you're tempted to make: is the camera move and the on-screen motion one idea or two? One idea can share the frame. Two ideas compete, and the payoff loses.
The push-in: making the climax visible
One more job only the camera can do. Our floor rule for payoffs: if the climax is smaller than about 1/40 of the frame, it did not happen. We learned this from a rejected build whose money moment was a one-word text change inside a small box on a wide, never-moving shot. The event occupied maybe a fortieth of the screen. The director's whole verdict: "don't see anything cool." The event fired; it just never became visible.
When the payoff is physically small — a status flipping, a value changing, a cell filling — the camera is how it becomes frame-scale: push in before the beat (settling first, as always), let it land big, then pull back to see the consequence in context. Pair the move with dimming everything non-focal and the eye has exactly one place to be.
A working checklist
- Build one fixed layout for the whole video; define named framings; move one continuous camera between them. Never improvise geometry per scene.
- Camera moves between ideas. Cuts within an idea. Neither at random.
- Every move settles before the beat it frames.
- During the climax: camera still, non-focal content dimmed, payoff at frame scale (push in if it's smaller than ~1/40 of the frame).
- During holds: a slow drift keeps the frame alive.
- If you're panning along something to fit it in, stop — fix the layout.
- One continuous camera, cuts earned: if the last frame before a cut and the first frame after it don't match where things are, the cut will read as a flinch.
This is a big part of what separates a good explainer from a cheap one — not more animation, but a camera that behaves like attention.
FAQ
My product video is just a screen recording. Does any of this apply? Yes, directly. A raw full-screen recording is the "one framing for 100 seconds" failure. Even in an editor, you can punch in on the region that matters, move between regions when the idea changes, and hold still on the payoff. Recording at high resolution and "shooting" it in the edit is the same discipline.
How many camera moves should a 60–90 second video have? Count ideas, not seconds. Each idea change earns a move; inside an idea, prefer cuts or nothing. In practice our produced videos define far more framings than they have scenes — 35+ over a fixed layout — because details and payoffs each get their own saved position.
Zoom, pan, or cut — how do I pick? Push in when the next idea is a detail of the current one. Pull back when the next idea is the consequence or the context. Move laterally when attention shifts to a different part of the same world. Cut when you're staying inside the same idea. And do nothing when the payoff is on screen.
Is a static video ever fine? For a 10-second clip with one beat, sure — there's only one idea, so there's nothing to move between. Past about 30 seconds, a fixed frame means the video has no attention, and viewers feel it even when they can't name it.
If you'd rather see it than build it: send us your product's URL and twenty directions come back with the camera work already done.