Motion Is Not Delight. It Is State.
Animation communicates status, causality, priority, and trust — not decoration. A practitioner's guide to treating motion as UX infrastructure, not polish.
Animation is not a reward for users who have waited long enough for your product to feel "finished." It is data. When a panel slides in from the right, it tells you where it came from. When an element fades in place, it tells you it always existed there. When nothing moves at all, you are left to infer the relationship between what you saw before and what you see now — and you will probably infer it wrong.
I spent over a decade doing motion graphics for television and music videos before moving into product engineering. What I learned from that work is not how to make things look cinematic. It is that every frame is a statement. Every motion decision either carries meaning or it steals attention from something that does.
Most product teams treat animation as the final coat of paint — something added in the last sprint and cut in the first round of budget pressure. I think this is almost always a mistake, and not just aesthetically. It is a structural problem. It means the team never asked what the motion is for.
The Mistake Is Conceptual, Not Executional
The conversation around motion in UI tends to sound like this: "Can we add some microinteractions to make this feel more polished?" Or, worse: "Users love little animations — it adds delight."
I have nothing against polish or things that feel good to use. But "delight" is doing enormous damage to how product teams reason about motion. It positions animation as a bonus — something earned after the real work is done. Something for users who are already satisfied, as a treat.
That framing makes motion the first thing cut when timelines compress, because it has been defined as optional. And it makes motion harder to design well, because the brief is vague. "Make it delightful" is not a brief. It is a feeling someone wants to have without knowing how to ask for it.
The shift I want to argue for is simple: stop designing motion to create feelings, and start designing motion to communicate state. The feelings will follow, but they will be grounded in something real.
Four Things Motion Actually Communicates
1. Causality
When a user clicks a button and something happens elsewhere on the screen, motion can answer the question: did that cause this?
Without motion, the user has to hold two things in working memory — the button they pressed and the result that appeared — and infer a connection. With motion, you can show it. An element that originates from the button's position and expands into its final location makes causality legible without a word of copy.
This is not decoration. This is information architecture expressed in time.
2. Continuity
Is this the same element I was just looking at, or a different one?
Shared-element transitions exist to answer this. When a card in a list morphs into a detail view, the user understands that no context was lost. The world did not reset. When that transition is missing and you just swap the view, the user has to re-orient from scratch — which takes time and creates the low-level cognitive friction that accumulates into a product feeling "clunky" without anyone being able to say why.
After years of cutting between shots in video editing, I developed an instinct for this. A hard cut is not wrong. It is a specific decision. It means: we are starting something new. If you use hard cuts everywhere in a UI, you are saying "everything is new" all the time, even when it is not.
3. Priority
Attention is not infinite. In any interface, some things are more important than others in a given moment. Motion can do the work of directing that attention without requiring the user to scan the entire screen.
An error state that pulses once. An unread indicator that scales in rather than appearing instantly. A notification badge that animates only when new content arrives. These are not decorative choices — they are editorial choices about where to look right now.
The key word is now. Priority communication is always time-sensitive. A spinner that loops forever stopped communicating after the first second. A progress bar that fills to 80% and stalls is communicating something, but probably not what you intended.
4. State Transition
This is the one most teams understand intellectually but routinely underinvest in. Loading, loaded, error, empty, partial, retrying, degraded — each of these is a real state, and each of them has a relationship to the states before and after it.
Motion is the most efficient way to communicate a state transition because it is sequential by nature. It happens between states. That is precisely where the information lives.
Map States First. Then Assign Motion.
Here is a heuristic I use when working on any component with animation: draw the state machine first. Every node in that graph is a state. Every edge is a transition. Motion belongs on the edges.
If you find yourself adding animation that does not correspond to an edge in the state machine — if nothing changed, but something is moving — that is a signal. It is either decorative (remove it) or you have an undocumented state (name it and document it).
A practical example. Take a form submission flow:
idle → submitting → success
↓
error → idle (retry)
Now assign motion:
idle → submitting: The submit button collapses into a loading indicator. This communicates that something is happening and the button is no longer available.submitting → success: The loading indicator morphs into a checkmark. Same location, same size, clear causal link.submitting → error: The form shakes (briefly, once) and an error message appears from below. The shake is priority communication — look here, something is wrong.error → idle (retry): The error message collapses, the button resets. The world is ready again.
Every one of those animations is load-bearing. Now ask: if I remove any of them, does the UX degrade? If yes, that animation was doing work. If no, it was decoration.
This is the test.
Reduced Motion Is the Proof
The accessibility specification prefers-reduced-motion is not a niche accessibility concern for a small percentage of users. It is a diagnostic tool for every team.
Here is the test: disable your animations entirely. Not reduce them — disable them. Now walk through the flow. If something feels broken — if you can no longer tell whether an action succeeded, if you cannot track where an element came from, if the state transition is ambiguous — then your animation was doing structural work. That work now needs to be done another way, or the animation needs to be preserved in reduced form.
If nothing feels broken, you had decoration. That is fine — decoration has its place — but you should know which is which.
Most teams interpret prefers-reduced-motion as "turn off animations." That is the wrong interpretation. It means: respect the user's preference for less motion, while preserving the meaning.
The Four Policies in @reactzero/flow
In my @reactzero/flow library, I built out four explicit policies for handling reduced-motion preferences. Each one corresponds to a different answer to the question: how much is this animation doing?
skip — The animation is purely decorative. Remove it entirely. No replacement needed.
reduce — The animation is doing light communication work. Keep it, but shorten the duration and reduce the distance traveled. The meaning survives at lower intensity.
crossfade — The animation communicates continuity or causality, and that meaning can be preserved through opacity changes alone. A shared-element transition becomes a crossfade. The "these are the same thing" message still lands without any spatial movement.
respect — The animation is deeply structural — for example, a progress animation that the user needs to watch to understand what is happening. Keep it as-is, because removing it would be more disorienting than showing it.
These four policies force a decision at design time. You cannot assign a policy without first asking: what is this animation communicating? That question is the whole point.
A Concrete Example: Three Loading States
This is the one I return to most often when explaining this to teams, because it makes the difference visible.
The spinner
A circular spinner appears when content is loading. It disappears when content arrives.
This communicates one bit of information: loading or not loading. It tells you nothing about what is coming, how long it will take, or how much of it has arrived. It is binary. When it disappears, the UI jumps from empty to full.
Remove the spinner and replace with an instant empty-to-full switch. Does the UX degrade? Slightly — the spinner at least signals that work is happening. But the content appearance itself is still a hard cut.
The skeleton screen
A skeleton screen shows the shape of the incoming content — gray blocks in the proportions of the actual elements — while data loads.
This communicates structure. The user sees that a title is coming, that there will be an image on the left, that there are three lines of body text. When content arrives, it fills in the skeleton. There is no jump because the layout was already established.
Remove the skeleton. The UX degrades more meaningfully. Without it, the layout shift on content arrival is jarring. The skeleton was preserving continuity across the loading boundary.
Streaming text
Text arrives character by character, or token by token, as it generates.
This communicates progress and content simultaneously. The user is not waiting — they are reading. The motion is the content. Remove it and replace with a spinner-then-reveal, and you have degraded the experience significantly: the wait is longer subjectively, and the user has less to engage with.
Three loading patterns. Three different things being communicated. Three different reduced-motion strategies needed. None of them are decoration.
Motion as Editorial Judgment
Working in broadcast motion, I was never asked to make things feel delightful. I was asked to make sequences legible — to get a viewer from one idea to the next without losing them, to mark what was important, to show relationships between elements in time.
Product UI is not that different. The screen is a sequence. The user is moving through it. Motion is how you direct that movement.
The difference is that in broadcast, motion is considered core craft from day one. Nobody cuts a music video trailer and adds motion in the last week. The cut, the timing, the pacing — that is the work. In product design, we somehow arrived at a convention where layout and copy are "the work" and motion is added after.
I think most portfolios miss this entirely. They show components with nice transitions but never explain what state those transitions are representing, what information they are carrying, or what the UX cost would be without them. The motion looks good, which is fine — but it could be working, which is better.
Where to Start
If you are working on a product and want to take motion more seriously as infrastructure, here is where I would start:
-
Audit your state machines. For every major component, write down the states it can be in. If you cannot write them down, you do not understand the component well enough to animate it yet.
-
Assign motion to transitions, not states. Motion belongs on the edges of the graph. If something is moving while the component is in a stable state, ask why.
-
Write a reduced-motion policy for every animation. Is it
skip,reduce,crossfade, orrespect? If you cannot answer, the animation's purpose is unclear. -
Test without motion. Disable animations and walk through your critical flows. Note what feels ambiguous. That ambiguity is the animation's job description.
-
Design motion early. Not in the last sprint. In the same conversation where you define the states.
Motion is not the reward for shipping. It is part of how you communicate while the user is there. Treat it like copy. Treat it like layout. Give it a job, and make it do that job.
The craft — the timing curves, the easing, the duration — all of that matters. But craft in service of nothing is just style. And style alone does not hold up when the deadline moves and someone asks what can be cut.
If you can explain what every animation is doing, it will survive that conversation. If you cannot, it probably should not.