You've had this experience: an animation that's technically fine and still feels wrong. It moves, it lands where it should, and something about it reads as cheap or robotic or slightly nauseating, and you can't say why. The why is almost always timing, and specifically the two things most designers set by default and never think about again: the easing curve and the duration. Get those wrong and even a well-designed transition feels off. Get them right and motion becomes invisible in the best way, the interface just feels alive and responsive.
UI animation easing is the single most under-examined craft skill in interface design, because the tools hand you a default curve and a default duration and most people accept both. This guide covers what easing actually does, how to choose a curve on purpose, when a spring beats a curve, how long a motion should last, and the small set of rules that separate motion that feels right from motion that feels like a screensaver.
Timing is the whole game
You've had this experience: an animation that's technically fine and still feels wrong.
Here's the principle everything else hangs on: in the real world, nothing moves at a constant speed and nothing starts or stops instantly. A door swings, gaining speed then slowing as it settles. A dropped ball accelerates. A thrown object decelerates. Our eyes spent a lifetime learning how physical things move, and an animation that violates that learning reads as wrong even to someone who can't articulate the rule.
Linear motion, constant speed from start to finish, is the most common mistake and the easiest to spot once you know it. It's what you get when an element moves without any easing applied, and it feels mechanical because nothing physical moves that way. The fix for most "why does this feel cheap" problems is simply removing linear motion and letting things accelerate and decelerate like objects with weight.
That's the entire foundation. Motion should behave like the physical world, because that's the only motion vocabulary your users have. Everything below is just how to do that precisely.
Easing curves, demystified
An easing curve describes how speed changes over the duration of an animation. There are three you need, and they map to physical situations.
Ease-out starts fast and slows to a stop. This is the workhorse of UI, the curve you should reach for by default, because it maps to something arriving and settling: a menu opening, a card appearing, an element entering the screen. It feels responsive because the motion is quickest right after the user's action, so the interface appears to react instantly and then settle.
Ease-in starts slow and speeds up toward the end. Use it for things leaving: an element exiting the screen, a dismissed dialog. It maps to something departing and gaining speed as it goes. Used on an entrance, ease-in feels sluggish, because the slow start delays the perceived response to the user's action.
Ease-in-out starts slow, speeds up in the middle, and slows to a stop. Use it for things moving from one place to another on screen, where both the start and end points are visible: a card sliding to a new position, a toggle animating between states. It reads as a considered, deliberate move.
The mistake to avoid is using one curve for everything. A single ease-in-out applied to entrances, exits, and moves alike feels uniform and slightly wrong, because entrances want the responsiveness of ease-out and exits want the acceleration of ease-in. Match the curve to whether the thing is arriving, leaving, or moving.
Under the hood these are cubic-bezier curves, and you can tune them. A stronger ease-out (a more aggressive early speed) feels snappier; a gentler one feels softer. You don't need the math, you need to know that the curve is adjustable and that "snappier" and "softer" live at opposite ends of the same control.
Springs versus curves
A spring is a different way to describe motion, based on physics rather than a fixed curve. Instead of setting a duration and a shape, you set properties like stiffness, damping, and mass, and the motion plays out according to those, sometimes overshooting slightly and settling, the way a real spring does.
The practical difference: a curve has a fixed duration and always plays the same way, while a spring responds to context and can feel more organic, especially for anything interactive or gesture-driven. When a user drags a sheet and lets go, a spring that carries the momentum and settles feels natural in a way a fixed-duration curve can't, because the motion continues from the user's actual velocity rather than snapping to a preset animation.
The rule of thumb: use curves for discrete, triggered transitions where the same thing should happen every time, a menu opening, a page transition. Use springs for interactive and gesture-driven motion, where the animation should feel connected to the user's input, and for playful microinteractions where a little overshoot adds life. A slight overshoot on a spring reads as bounce and personality; too much reads as unserious, so tune damping until the settle feels confident rather than wobbly. The premium feel that products like Linear and Stripe are known for leans heavily on well-tuned springs for exactly this reason, a craft covered in how Stripe, Linear, and Vercel ship premium UI.
How long should it last
Duration is the other default nobody questions, and it has a real range that maps to perceived personality.
Roughly: microinteractions and small state changes want to be quick, in the neighborhood of 100 to 200 milliseconds, so they feel instant. Standard transitions, a menu opening, a card appearing, sit around 200 to 300 milliseconds, long enough to be perceived as motion, short enough to feel responsive. Larger movements across more of the screen can run 300 to 500 milliseconds, because a bigger distance needs more time to not feel abrupt.
Two rules make duration feel right. First, faster reads as more responsive, so when in doubt, err short; a motion that's slightly too fast feels snappy, while one that's slightly too slow feels sluggish and makes the whole interface feel heavy. Second, distance and duration should relate: something moving a long way should take longer than something moving a little, or the long move feels rushed and the short one feels padded. A one-size duration applied to every animation ignores this and makes some motions feel wrong at both ends.
There's an asymmetry worth knowing too: exits can be faster than entrances. When something leaves, the user has already moved on mentally, so a quick exit feels efficient, while a slow one makes them wait for something they're done with. Entrances can afford a touch more time because the user is arriving at the thing.
The rules, and one you can't skip
Pulling it together, the small set of rules that fixes most motion:
Kill linear motion; let things accelerate and decelerate. Use ease-out for entrances, ease-in for exits, ease-in-out for on-screen moves. Use springs for interactive and gesture-driven motion. Keep durations short, roughly 100 to 300 milliseconds for most UI, and let bigger moves run longer. Make exits a little faster than entrances.
And the rule you cannot skip: respect reduced-motion preferences. A meaningful number of users have vestibular conditions that make large or bouncy motion physically unpleasant, sometimes to the point of nausea. Every animation should have a reduced-motion path that cuts or minimizes movement for those users. This isn't optional polish; it's the difference between motion that delights most users and motion that makes some of them sick, and it's part of treating motion as craft rather than decoration.
Build a motion scale
Just as you don't pick a random font size or spacing value for each element, you shouldn't pick a random duration or curve for each animation. Define a small motion scale and reuse it: two or three durations (a fast one around 150 milliseconds, a standard one around 250, a slow one around 400) and a small set of curves (a default ease-out, an ease-in for exits, an ease-in-out for moves, one or two tuned springs), saved as styles or tokens. Then every animation draws from that set, and motion across the whole product reads as one system instead of a dozen designers' individual instincts. This is the same discipline that makes color and spacing coherent, applied to time. A product with a motion scale feels considered; one without feels like every screen animates slightly differently, because it does.
Start Monday
Open the last thing you animated and check two things: is any of it moving linearly, and are entrances using ease-out. Fix those two and record a before-and-after clip. Most designers are surprised how much better their existing work feels after removing linear motion and matching curves to direction, and it takes about ten minutes. Then set your default duration to around 200 milliseconds and your default entrance curve to a solid ease-out, so every new animation starts from the right place instead of the tool's generic default. Once the fundamentals are automatic, the microinteractions that actually convert become much easier to build well.
Good motion isn't about more animation. It's about motion that behaves like the physical world your users already understand, at a speed that feels responsive, with a path out for the users who need less of it. Get the curve and the duration right and the animation disappears, which is exactly what it should do.