Archive for category: Motion

Motion in interfaces and brand work is treated, almost universally, as decorative. Add a fade. Animate the hover. Make it smoother. None of these are wrong, but they describe motion as polish on a finished thing. We treat motion as a hierarchy tool.

What motion communicates

An element that animates in is more important than an element that appears statically. An element that animates with a 600ms ease is more important than one that animates with a 150ms snap. An element that originates from another element is causally related to it; an element that fades in independently is not.

Every motion choice answers a hierarchy question. What enters first? Why? What is the user supposed to look at as the page settles? Where is the click going to take them? Animation telegraphs the answers. Static design has to encode them in space, weight, and color alone.

The constraints we follow

One: motion should respect prefers-reduced-motion. Always. There is no exception. If your animation breaks the experience for users with vestibular conditions, your animation is the bug, not the user.

Two: nothing animates above 800ms. Nothing. Even cinematic transitions. If a motion takes longer, it is no longer felt as motion — it is felt as waiting.

Three: ease curves are not aesthetic, they are physical. Material moves with weight. A cubic-bezier(0.32, 0.72, 0, 1) feels right for most UI; a linear motion almost never does. We pick from a library of five curves and reuse them ruthlessly across the system.

The final test

Turn off the motion. Does the design still communicate the hierarchy? It should. Motion accelerates and reinforces hierarchy; it does not create it. If the static layout works, the motion makes it sing. If the static layout doesn’t work, no amount of animation will save it.