Your Animations Are Decorating the UI. They Should Be Explaining It.
The card animates on hover. Smooth shadow lift, subtle scale-up, satisfying. The designer is proud of it. The engineer implemented it correctly. The stakeholder approved it.
Nobody asked what it means.
Hover animation that communicates nothing except "this is hoverable" is decorative motion. It looks considered. It isn't. In most design systems, the majority of animation works this way — applied to components because animation is in the brief, not because anyone mapped what system state the motion is encoding.
This is the gap between animation that makes a product feel alive and animation that makes a product legible.
The Default Mental Model Is Wrong
Animation gets introduced into products in one of two ways. Either the design system includes motion tokens (typically borrowed from Material Design or a third-party component library), or a designer adds animation during polish. Both approaches treat motion as a layer that goes on top of a finished design.
This mental model produces animation that has no relationship to what the system is doing. The transition plays whether the state is loading, error, or success. The same easing curve appears on a button that's enabled and a button that's disabled. The modal animates in regardless of whether it's carrying critical information or optional input. The motion is there because the component has motion, not because the motion is communicating anything.
Compare this with what animation can actually do when it's designed semantically. A loading state that uses a specific motion pattern — distinct from success, distinct from error — tells the user what kind of waiting they're doing. An animation that reverses when an action fails doesn't just look correct; it encodes causality. A disabled button that doesn't animate on hover communicates affordance through absence. These are meaning-bearing choices. Most implementations don't make them.
State Machines Make the Problem Visible
The most clarifying exercise for motion design is to map your components to their state machines before you design any animation.
A button isn't a single thing. It has states: default, hover, focus, active, loading, success, disabled, destructive-default, destructive-hover. Each state transition is a potential animation event. The question for each is: what does the user need to know when this transition happens, and does the animation help communicate that?
Default → hover: low information need. The user moved their cursor. They know that happened. Motion is optional and should be subtle.
Loading → success: high information need. Something important changed. The motion should be distinct, confirmatory, and quick — the user needs to know the action completed before they move on.
Enabled → disabled: medium information need. Something changed the button's availability. Motion can communicate this shift — a subtle desaturation or opacity change that reads as "this path is closed" rather than just a static state difference.
Most design systems don't make these distinctions. They apply a single motion profile across all states because state machine thinking wasn't part of how the motion system was designed. The result is that high-information transitions look identical to low-information transitions, and users can't use motion as a signal at all.
The Material Design Motion Spec vs What Teams Actually Build
Google's Material Design 3 motion spec is thorough and semantically grounded. It distinguishes container transforms (persistent elements that morph between states) from forward/backward transitions (directional navigation) from fade patterns (elements that enter and exit independently). Each pattern maps to specific use cases with specific meaning.
What most teams build: one or two animation utilities applied inconsistently across the component library, driven by whatever the first engineer to implement animations chose. The spec says that forwards navigation should feel different from backwards navigation because it communicates direction and hierarchy. Most implementations use the same fade for both, which makes the navigation system ambiguous.
Design system adoption fails partly because the system doesn't teach people to use it correctly. Motion is a particular casualty — motion specifications in design systems are often technically present but practically ignored, because they require more judgment to implement correctly than color tokens or type scales. You can use a color token mechanically. You can't use motion semantically without understanding what you're communicating.
Design tokens need discipline at the semantic layer — the same applies to motion tokens. A duration token doesn't tell you when to use a long duration versus a short one. The semantic layer — the decision about which motion pattern maps to which state transition — is the part that can't be automated, and it's the part that most teams skip.
Cognitive Load and What Motion Is Actually For
The research anchor here is cognitive load theory, specifically the work of John Sweller, who identified three types of load: intrinsic (the inherent complexity of the content), extraneous (complexity introduced by poor design), and germane (the cognitive work of building mental models).
Good animation reduces extraneous load by making system state visible without requiring the user to infer it. Bad animation increases extraneous load by adding visual events that don't correspond to meaningful state changes — creating noise the user's attentional system has to filter.
The loading spinner is the canonical example of this going wrong. A spinner communicates "something is happening," but it doesn't communicate what, or how long, or whether it's working. A spinner that appears on every async operation — quick network calls, slow database queries, third-party API timeouts — treats all waiting as identical, which it isn't. Users learn to be uncertain about what the spinner means, which is the opposite of what animation is supposed to do.
Designing for AI agency visibility has pushed this problem into sharp relief — when the system is doing complex, time-consuming, multi-step work, the question of how to communicate state becomes acute. The same problem exists at smaller scale in every product. What is the system doing right now? Animation can answer that question. Most animation doesn't.
The Diagnostic Question
Before you add an animation to a component, ask one question: what does the user need to know at this moment, and does this motion communicate that?
If the answer to the second part is "not really" — the animation is decorative. That's a choice you can make. Decorative animation isn't inherently wrong. But it should be a conscious decision, not a default. The mental model shift is from "this component should animate" to "this state transition should communicate something, and motion is how we'll do it."
Systems that animate semantically don't always feel as immediately impressive as systems that animate for delight. They feel clearer. They feel like the interface knows what it's doing. That's a different quality — harder to demonstrate in a Figma prototype, much more noticeable after a month of daily use.
The spinner that tells you what's loading, the transition that reverses when the action fails, the disabled state that feels visually closed — these are small choices that add up to a system the user can trust. Decoration impresses once. Communication compounds.
Photo by Egor Komarov via Pexels — a high-tech digital interface showcasing control parameters and data visualization