Motion that explains something, and nothing that does not

Why movement is worth paying for, and why most of it is not

Motion earns its place in two ways. The first is that it explains. When something is added to a basket and visibly travels to the basket icon, nobody has to be told what happened. When a panel slides out from the edge it came from, its relationship to the screen behind it is obvious, and the way back is obvious too. Movement carries information about cause and place that static design has to spell out in words.

The second is less noble but entirely real — things that move feel more expensive. Two otherwise identical products will not be judged equally if one responds to touch and the other does not. On an app store listing or a social feed, a moving frame competes with a still one and wins. Clients rarely say this out loud, and it is frequently the actual reason the budget exists.

Both of those arguments cut the other way just as hard. Animation that does not explain something, direct attention or acknowledge an action is decoration that costs time — the user's time, on every single visit. The most valuable judgement in this service is usually about what should not move, and it is the judgement most often skipped by someone who has recently learned how to make things move.

How the work runs

1. Decide what moves and why. An inventory of every candidate — state changes, transitions, entrances, loading, success and error, plus any showpiece animation — with each one justified by what it explains or acknowledges. Anything that survives only because it looks nice is cut here, where cutting is free. Half a day to a day.
2. Write the motion system in numbers. Duration and easing for each class of movement, and the property being animated. Short and ease-out for anything responding to a press. Slightly longer and ease-in-out for a screen replacing another. Entrances ease out; exits are faster than entrances, because nobody wants to watch something leave. These become the constants everything else is built on, so a fifth developer adding a sixth component does not invent a new speed. One day.
3. Build it. Simple interface motion is prototyped and specified directly as CSS. Anything illustrated or multi-layered is built in dedicated animation software and exported as Lottie, keeping an eye on the effects that do not survive that export. Complex logo and explainer work is composed frame by frame. Three to twelve days, depending on how much of it there is.
4. Add the reduced-motion path and the focus states. Every animation gets an alternative for people who have asked their device for less movement, and keyboard focus stays visible throughout — a transition that hides the focus outline makes an interface unusable without a mouse. Half a day.
5. Run it in the real product, on a real phone. This is the step that is skipped most often and the one where the difference actually appears. A prototype eases differently from a browser, a Lottie file containing an unsupported effect can render as a blank rectangle, and a transition that felt right on a fast laptop feels sluggish on mid-range hardware. Timings are tuned here against the running build. One to two days.

What the price depends on

Design only, or design through implementation. Handing over a specification and assets is one job. Being responsible for the motion behaving correctly inside your product — across browsers, on low-end devices, without hurting performance — is a different one, and it is the biggest single factor between the ends of this range.

How much is illustrated. Interface micro-interactions are largely rules applied consistently, and once the system is written, each additional component is quick. An explainer sequence or a fully animated logo is bespoke frame work with no reuse between shots, and it scales with seconds of finished output rather than with components.

Whether three-dimensional work is involved. 3D is a separate craft with its own tooling, its own render times and its own file weight problems on the web. It can be spectacular and it is not a variation on 2D motion — it is priced as its own thing.

The three ways motion fails

Everything animates. Every card fades in, every section rises on scroll, every list staggers. Individually each is charming; together the product feels slower than a static one, because the user is waiting on choreography to finish before they can act. The rule worth enforcing is that if a movement does not explain, direct or acknowledge, it should not exist — and that rule has to be applied hardest immediately after a team has fallen in love with an animation library.

The wrong properties get animated. Width, height, top, left, box-shadow and filters are animated because they are what the design describes, and the browser recalculates layout on every frame. It looks perfect on a fast desktop and stutters visibly on the mid-range Android phone most of the traffic is actually using. Almost everything can be expressed as transform and opacity instead, and where it genuinely cannot, that is worth knowing at design time rather than at launch.

It is approved in a prototype and never seen in the build. Prototype tools apply their own easing and their own frame timing, so a transition signed off there is an approximation of what ships. Add an exported animation containing an effect the runtime does not support — which fails silently, as an empty box rather than an error — and the first person to notice is a user. Nothing here is finished until it has been watched running in the real product on a real device.