Animation timing and easing: why your video feels off

When an explainer video feels cheap and you can't say why, the problem is almost always timing. Not the drawings, not the colors — the when: two related things changing at unrelated moments, a frame that sits frozen while the voice keeps talking, a cursor that drifts across the screen like a ghost.

Across sixty-odd produced videos, most of the review notes we've ever received were timing notes. Reviewers rarely say "the box is the wrong shade of blue." They say "the clicks appear too quickly," "this part just sits there," "boring." This guide translates what we learned into plain words, with the actual numbers we tuned by shipping things wrong and getting told so.

Timing is meaning, not polish

Here's the core idea: viewers decide what caused what by watching when things happen. Not by reading arrows. Not by reading labels. By timing.

If a button lights up and, at that same moment, a row appears in a table, the viewer's brain says: that button made that row. No connector line needed. No caption. The synchrony IS the explanation.

And the reverse is just as true. In one early build of ours, a query block ran, and then — on its own schedule — some table rows highlighted. Both things happened. Nobody connected them. The fix wasn't an arrow or a label; it was re-timing the highlights to land in sync with the block going live. Same pixels, different timing, and suddenly the video explained itself.

So the first question to ask of any animation isn't "does it look smooth?" It's "what is this synced to?" If an animation can't name its sync partner — the other thing on screen it changes with — it's decoration, and decoration is what makes videos look cheap.

The 0.7-second rule

One number matters more than any other here: cause should precede effect by about 0.7 seconds.

A worker finishes its job; its result row fills 0.7 seconds later. That gap is what makes the relationship read as consequence. Make them perfectly simultaneous and it reads as coincidence — two things that happened to occur together. Stretch the gap much longer and the connection snaps; the viewer files them as separate events.

We didn't design that number. It came out of measuring the renders that reviewers graded best. Cause, small beat, effect. That's the shape of "this did that."

Holds: alive vs. dead

A hold is a stretch where the layout rests — nothing new arrives, the frame just is. Holds are not the enemy. A hold after a payoff is a breath; the viewer needs it. The enemy is the dead hold: a frame that settles early and sits frozen while the voiceover finishes its sentence.

This is the single most common failure in template-made video, and we know exactly how bad it gets because we measured one of our own bad builds: 44% of its runtime was fully static — 52 seconds of settled frames in a 93-second video. Another build, the worst-graded of its batch, ended every one of its six scenes in three to five seconds of total stillness while the voice kept going. It passed every mechanical check we had at the time. It died in review anyway. Viewers can't articulate the problem, but they feel the video stop caring.

The diagnostic is simple. Pause the video at a random moment. If you land on a completely still frame more than a third of the time, you've made a slideshow with a soundtrack.

Two rules fix it:

1. Cap dead holds at about 3 seconds. A hold after something happened can run that long. A hold before anything has happened shouldn't exist at all.
2. Budget ambient life into every hold longer than a second. This costs almost nothing: a slow camera drift, a status light still pulsing, a small working dot on the element that's mid-task. The frame doesn't need action — it needs a pulse.

There's a refinement worth knowing: an unresolved frame survives a hold much longer than a resolved one. A ring still burning on a block is a held question — the viewer waits with it. A settled green everything-is-done frame is a closed book, and camping on it just tells the viewer the video ran out of things to say. If a scene has to end on a hold, end it on the question, not the answer.

Easing is behavior, not a preset

Easing is the curve of a movement — fast then slow, slow then fast. Every animation tool offers a menu of them, and the menu is where most people stop thinking. Here's the story that taught us the menu isn't the point.

One build showed a cursor moving between two click targets. It had a perfectly respectable ease-in-out curve — textbook. But the two clicks were five seconds apart in the script, so the movement was stretched across the whole gap: a 4.5-second glide across the screen. Review flagged it instantly. Nothing about the curve was wrong. It just didn't move like a hand.

The fix wasn't a different curve. It was a different window. Real human pointing looks like this: the hand dwells at the last target, then makes one quick, decisive flight — fast launch, long deceleration — and settles a beat before the click. So we rebuilt it: dwell, then a flight of 0.32–0.55 seconds (scaled to distance), settling about 0.12 seconds before the click lands. Same family of curve. Right window. It suddenly read as a person.

The general lesson: things that imitate physical behavior must take their duration from the behavior, not just their curve from a menu. A correct curve over a wrong duration still reads wrong — and duration is the larger share of what feels natural.

The working defaults we settled on, in plain words:

• Arrivals decelerate. Things landing into place launch fast and slow into their spot (ease-out). Nothing in the physical world arrives at full speed.
• Camera moves breathe on both ends. Ease in, ease out — the camera is a head turning, and heads don't snap.
• Physical-feeling elements get springs. A tiny overshoot-and-settle reads as weight.
• Decide these once. Our timing profiles are system constants, not per-video choices. Re-tuning easing by feel on every project is how a studio produces sixty videos with sixty different accents.

Rhythm: uniform timing is a slideshow

The last layer of timing is rhythm — the spacing between events. And the rule is blunt: uniform timing reads as a slideshow. Real systems don't finish their work in order at even intervals, and viewers know it in their bones even if they've never thought about it.

Three rhythm tools do most of the work:

Staggers with the right cadence. When several items light up one after another, the gap between them carries tone. We use two speeds and they mean different things: about 0.35 seconds per item is a presentation cadence — a narrator pointing at things one by one. About 0.14 seconds per item is a machine cadence — a system sweeping a selection. Swap them and you get a tone error: the machine looks sluggish, or the narrator looks frantic.

Scrambled finish, even beat. When parallel workers land their results, we shuffle the order they finish in — because real parallel work doesn't finish in order — but lock the gaps between finishes to an even beat. The order says "parallel." The rhythm stays readable. Randomize both and it's chaos; regularize both and it's a slideshow again.

Compressing gaps. When events arrive at shrinking intervals — 1.6 seconds apart, then 1.4, then 1.2 — the frame reads as a system under load. Density comes from overlap, not from making anything move faster.

And one meta-rule over all of it: vary the beat shape. One of our technically cleanest builds repeated the same well-made beat five times over the same two surfaces. The entire review verdict was one word: "boring." Repetition of a good beat is still repetition. The builds that graded best changed shape as they went — a wide pull, then a fan-out, then a close-up, then a scrambled finish. Same run, four shapes. (Where the camera fits into that variety is its own craft — we wrote it up in camera moves in product videos.)

The one exception: when uniform is right

Uniform timing isn't banned — it's reserved. When the message is simultaneity ("all five of these update together, that's the point"), even timing is the honest choice. The rule is the same one that governs everything above: timing carries meaning, so spend it on purpose. Sameness should mean "these are the same," not "we didn't think about it."

This is also why timing belongs in the plan, not the polish pass. It's a scripting decision — which is why we sort it out at the storyboard stage, before a single frame renders.

FAQ

Do I need to know animation software to use any of this? No. Every rule here is a decision about when, and you can mark it in a script or storyboard: "row fills 0.7s after the worker finishes," "hold 2s, keep the status light pulsing." Whoever animates it — a freelancer, a tool, a studio — executes better with those notes than without.

What's the fastest way to check a finished video for timing problems? Two tests. Scrub to random frames: if you keep landing on totally still frames, the holds are dead. Then watch it muted: if you can't tell what caused what without the narration, the sync is broken.

Is slower animation more "premium"? No — appropriate is premium. A 4.5-second cursor glide reads as broken, not luxurious. Slow works for camera moves between ideas; behavior (clicks, arrivals, selections) should move at the speed the real behavior moves.

How exact do these numbers need to be? Treat them as strong defaults, not physics. 0.7s cause-to-effect, 3s hold cap, 0.32–0.55s cursor flights — these came from graded work and they hold up. What matters most is that you pick values deliberately and keep them consistent across the whole video.

If you'd rather judge timing than tune it: send us your product's URL and pick from twenty rendered directions where this is already handled.