A button presses down. A sheet slides up. A card tilts under your finger. None of these things have mass in any physical sense, yet the ones that feel right seem to. You can tell, without being told, whether a designer has thought about weight.
Weight is what separates motion that feels alive from motion that feels scripted. It is the quiet signal that the software understands the world you live in — a world where nothing accelerates instantly, where stopping always takes a little longer than you expected, where light things flit and heavy things settle. When interface motion ignores this, it reads as synthetic. When it respects it, it reads as intentional.
This post is about finding that weight, and about the handful of habits that put it there.
Motion as a Material
Designers tend to think of color, typography, and spacing as materials — things you pick with intent, that say something about your product before a user reads a single word. Motion is a material too, but it is rarely treated as one. It gets bolted on at the end. It gets a default. It gets "300ms ease-in-out" because that is what the last person wrote.
The easiest way to start thinking about motion as a material is to ask: what is this object made of? A tooltip is a feather. A modal dialog is a heavy door. A navigation sheet is something in between — a book cover, maybe. Each of these has a different natural speed, a different natural delay, a different natural settle. Once you have that image in your head, the specific numbers almost pick themselves.
Try it the next time you are reaching for an easing curve. Instead of scrolling through Framer's presets or copying the last config, close your eyes and ask what the element is made of. The answer will feel obvious, and the motion will follow.
Acceleration and Settle
Real objects do not start at full speed and they do not stop on a dime. They ease in, and they ease out, and those two phases are rarely equal.
Physical intuition tells us that starting is harder than stopping. A book on a table resists being pushed; once it is moving, friction is what slows it down. This is why ease-out dominates good interface motion — users initiate, then watch the object decelerate into place. Ease-in can feel wrong for user-initiated actions because it implies the object is building up to something, as though there were a hidden force we are not aware of.
The one place ease-in earns its keep is on exit. When a modal dismisses, it is being pulled away from the user — accelerating out of view. An ease-in on dismiss mirrors that intuition, and the asymmetry of in-versus-out becomes a signature of considered motion.
Durations follow from this too. An object with more visual weight wants a longer settle. A heavy sheet arriving in 150ms looks jumpy. A light chip taking 400ms to appear looks sluggish. Match the duration to the perceived mass, not to a house default.
Springs Over Curves
Easing curves are a simulation of physics. Springs are physics.
When you switch from a tuned cubic-bezier to a spring, the thing that changes is not usually the speed — it is the quality of the stop. Cubic-bezier stops are always clean. Spring stops overshoot slightly, wobble once, and settle. That tiny wobble is the difference between an object that was placed and an object that arrived.
Springs come with their own vocabulary — stiffness, damping, mass — and once you internalise those three dials, you rarely go back to curves for anything interactive. Stiffness is how strongly the object wants to reach its target. Damping is how much it resists oscillating. Mass is how much it resists changing direction. Tune those three against each other, and you can dial in the personality of almost any motion.
Not every animation needs a spring. Progress indicators, scrubbers, and anything tied to a continuous input value are usually better served by linear or curve-based motion. But for anything that snaps into position — menus, sheets, cards, toasts — springs almost always win.
Direction Inherits Intent
One of the most reliable ways to give motion weight is to respect the direction of the user's action. An object should move in the direction the user implied, not in whatever direction is easiest to code.
A pull-to-refresh animation that bounces downward feels correct because the user pulled downward. A dismiss-by-swipe animation that follows the swipe direction feels correct because the user pushed it that way. When motion inherits intent, users stop noticing the animation — which is what you want. The ones you remember are the ones that moved wrong.
This also applies to entrances. If a user taps a button in the bottom-right corner and a panel appears from the top-left, the disconnect is small but real. The best interfaces make the origin of a new element traceable to the thing that summoned it.
This is the principle behind hero transitions, shared element animations, and pretty much every "magical" moment in mobile UI. Start where the user was looking. End where the user needs to look. Draw a line between them.
Restraint
Most interface motion is too much. A typical dashboard does not need page transitions, staggered card entrances, hover-scales, press-scales, and parallax on the hero image. Pick one, maybe two, and let the rest of the product breathe.
Restraint is what lets the few animations you do include carry weight. If everything is moving, nothing is moving — it is all just visual noise. But if a single element animates in response to a specific action, and the rest of the interface is still, the motion reads as meaningful. The user registers it. The user feels the product responded to them.
The test I use: if I removed this animation entirely, would anyone notice? If the answer is no, cut it. If the answer is yes, and the thing they would notice is confusion or loss of flow, keep it. Everything in between is decoration — and decoration is the first place a good product trims before it ships.
Footnotes
Animate with Springs from WWDC23 is the clearest explanation of spring physics in interface context I have come across. The vocabulary translates directly to any framework.
Rauno's Invisible Details of Interaction Design is essential reading for anyone who wants to see motion through a craft lens rather than a checklist.
Lochie Axon's easing.dev is the best playground I know of for feeling the difference between a curve and a spring. Build a few presets by hand; it rewires your intuition.
The original Disney 12 Principles still hold up. Squash-and-stretch translates to UI as compression under pressure; follow-through is what springs give you for free.
Val Head's book on Designing Interface Animation is the most thorough treatment of the craft I have found, and it holds up a decade later.