Easing and duration: why one animation feels premium and another feels cheap

In the micro-animations lesson we covered why an interface needs motion at all. This is the next step: how to make that motion feel well crafted. The main tool is easing — the curve that describes how an element's speed changes from the start of an animation to its end. Without it (linear), the element moves at full speed from the very first frame and stops just as abruptly.

web.dev puts it simply: nothing in nature moves linearly from one point to another, which is why linear motion feels robotic. Apple's talk on spring animations shows why: a linear animation's velocity graph has a sharp jump at the start and at the end. The eye reads that jump as a jerk — and the interface starts to look like a cheap slideshow.

The names are confusing at first: ease-out is used when something appears, ease-in when it leaves. Nielsen Norman Group explains the logic: ease-out on entry slows the element before it stops, so the eye can predict where it will land; ease-in on exit speeds the element up, so it feels like it is accelerating away off the screen.

Any of the standard curves can be written as cubic-bezier — a function with four numbers. As MDN describes it, it's a graph where the horizontal axis is elapsed time and the vertical axis is progress along the path. The start (0, 0) and end (1, 1) are fixed, and the four numbers set two control points in between that pull the curve into shape.

• A steep rise at the start means a fast start; a flat stretch at the end means a soft stop. That's ease-out
• A flat start and a steep end mean a slow build-up and an abrupt finish — that's ease-in
• An S-shaped curve is ease-in-out: speed up, fast middle, slow down
• If a control point's second coordinate goes above 1 or below 0, the element overshoots the target and comes back — that's how CSS does a light "kick"
• The standard values are defined in the W3C specification: ease-in is cubic-bezier(0.42, 0, 1, 1), ease-out is cubic-bezier(0, 0, 0.58, 1), ease-in-out is cubic-bezier(0.42, 0, 0.58, 1)

The standard keywords are fairly mild. On InterLAB projects we usually tune our own, more pronounced entry curve — a sharp start and a long smooth tail: at the same duration the interface feels faster. The easiest place to tune it is the browser itself: in Chrome DevTools, any transition in the Styles pane has an Easing Editor where you can drag the control points and see the result immediately.

A spring animation isn't defined by a curve and a time but by physics: how stiff the spring is and how much friction damps it. In its WWDC 2023 talk, Apple simplifies the setup to two parameters — duration and bounce. With zero bounce you get smooth motion without overshoot; with positive bounce the element overshoots the target and oscillates around it a few times as the motion dies down.

The spring's main advantage isn't the bounce. It can pick up the velocity at which a person released an element with their finger and carry on without a jerk, and if the target changes halfway, it turns around smoothly. That's why springs became the default animation in SwiftUI. On the web a spring can be approximated with the CSS linear() function over a set of points (documented on MDN) — which is exactly how the spring lane in the demo above works.

Nielsen Norman Group gives a range of 100–500 ms for most animations, with the exact value depending on how complex the change is and how far the element travels. Press Replay and see where, for you, the line falls between "instant", "smooth" and "I'm waiting".

• The smaller the element and the shorter the path, the faster the motion: a tooltip next to the cursor and a full-screen side panel can't share one duration
• Make exits shorter than entrances: per NN/g, a dialog may take 300 ms to open and 200–250 ms to close
• The more often an action repeats, the shorter or subtler its animation — Apple's HIG advises against adding motion to frequent interactions
• Animation shouldn't block: if someone is already clicking ahead, the interface doesn't wait for the effect to finish
• Even small differences are felt: NN/g notes that going from 250 to 300 ms can feel very different

When every developer picks durations by eye, the product ends up with 180, 250, 320 and 600 ms and five different curves — and the interface starts to feel sloppy, even though nobody can say why. The fix is to agree on a small set of named values — tokens — and use only those, just like colors and spacing from the palette.

In code it's a single line: transition: transform var(--duration-moderate) var(--ease-enter). On InterLAB projects motion tokens live next to colors and typefaces in the design system: the designer writes "enter — moderate, ease-enter" in the mockup, the developer uses exactly those values, and the "a bit faster?" debate happens once rather than on every screen.