Motion is everywhere in 2026. Liquid Glass makes iOS elements morph fluidly. Material 3 Expressive uses springs on every interaction. Websites have scroll-triggered transitions on every block. Every SaaS product has "delight moments" baked in. The problem is that most of this motion is bad — it's slow, arbitrary, inaccessible, and often actively harmful to the experience it's supposed to enhance.
This post is not another "motion is great" list. This is the contrarian take. I'm going to walk through nine specific mistakes that almost every team makes, explain why they matter, and give you the principles that separate motion-as-communication from motion-as-decoration. If you're shipping UI in 2026 and your motion feels laggy, annoying, or inaccessible, at least one of these applies to you.
TL;DR — Key Takeaways
- Motion should communicate, not decorate. If you can't explain what information an animation conveys, remove it.
- Nine mistakes kill most UI motion: linear easing, wrong duration, no accessibility toggle, no hierarchy, over-animation, decorative-only motion, inconsistent durations, low-end device blindness, and wrong easing curves for direction.
- Standard UI timing: 100-200ms for micro-interactions, 300-500ms for larger transitions. Anything over 500ms feels laggy.
prefers-reduced-motionis not optional. Vestibular disorders affect a large share of adults; ignoring the media query is shipping a broken product.- Motion design is separate from UI animation. Motion is structural; animation can be decorative.
- Real-world winners get motion right: Linear, Arc, Raycast, Apple's native apps, Figma.
The Core Test: Can You Explain What the Animation Communicates?
Before any of the specific mistakes, here's the test that separates intentional motion from expensive decoration: describe, in one sentence, what information this animation communicates to the user.
"It shows cause-and-effect between the button press and the modal appearing." Good. The animation earns its place.
"It adds delight and makes the product feel alive." Bad. "Delight" and "alive" are not information. This animation is decoration, which means it's costing performance, accessibility, and time-to-task for no user benefit.
The test is brutal but clarifying. Apply it to every animation in your product. A lot of them will fail. Those are the ones to delete.
Mistake 1: Linear Easing (The Single Biggest Giveaway of Amateur Motion)
Nothing in the physical world moves at constant velocity. Objects accelerate when they start moving and decelerate when they stop. Linear easing — where an element moves at the same speed throughout its animation — looks unnatural because it violates this basic physical intuition.
What it looks like: A modal slides in at the same speed from start to finish, then stops abruptly. A card fades at the same rate throughout the transition. Something just feels... robotic.
What to do instead: Use easing curves that match the nature of the motion.
- Elements entering the screen: ease-out (start fast, slow to a stop). Matches how objects "land."
- Elements exiting the screen: ease-in (start slow, accelerate away). Matches how objects "depart."
- Elements transitioning between states: ease-in-out (start slow, speed up, slow down). Smooth continuous motion.
This one rule fixes maybe 40% of the motion problems I see in products. Linear easing is the clearest tell that the designer animated without thinking.
Mistake 2: Wrong Duration
UI timing has rough but real norms. Ignore them and motion feels either too jittery or too laggy.
Standard timing references:
- Micro-interactions (button press, toggle switch, hover state): 100–200ms
- Mid-level transitions (dropdown open, tooltip appear): 200–300ms
- Large transitions (page transition, modal open, route change): 300–500ms
- Ambient animations (loading spinners, skeleton shimmer): ongoing at a steady tempo
What goes wrong: Designers pick durations that look good in isolation without testing in context. A 600ms page transition looks silky in a demo. In actual use, it feels like the app is lagging every time someone navigates.
Rule of thumb: If you're unsure, err shorter. 150ms feels snappy. 500ms feels sluggish. 800ms feels broken. Material Design suggests 200ms as the reference for standard UI transitions, and 300ms for inter-screen transitions. Apple's HIG suggests similar values. These aren't arbitrary — they come from decades of user testing.
Mistake 3: Ignoring `prefers-reduced-motion`
This is the motion mistake that's genuinely harmful. Vestibular disorders — which cause dizziness, nausea, and loss of balance in response to screen motion — affect a meaningful share of adults (per NIH data, roughly 35% of adults over 40 experience some form of balance disorder). Some users can literally get sick from animations that feel subtle to others.
Operating systems ship with an accessibility setting: "Reduce Motion" on iOS and macOS, equivalent on Android and Windows. This exposes a prefers-reduced-motion media query to the web and equivalent signals to native apps. Respecting this media query isn't an accessibility upgrade — it's a baseline requirement under WCAG 2.1 Success Criterion 2.3.3 (Animation from Interactions), which explicitly requires that motion triggered by interaction can be disabled.
Additionally, Google's Core Web Vitals Interaction to Next Paint (INP) metric targets ≤200ms for good user experience. Heavy motion that blocks interaction feedback beyond INP thresholds is now both a UX concern and an SEO concern.
What to do: In every animation you design, specify what happens when reduced motion is on. Usually one of:
- Replace the animation with an instant state change (most common)
- Replace with a simple opacity fade (for subtle transitions)
- Reduce duration by 50–70% (for animations users still need to perceive)
What not to do: Ignore the setting and ship motion that happens regardless. This is a shipped-accessibility-failure, and in some jurisdictions, a legal liability. See Accessibility Lawsuits Are Accelerating in 2026 for the compliance context.
Mistake 4: No Hierarchy in Motion
When multiple elements animate at once, users need to know which animation is primary and which are secondary. Without hierarchy, all animations fight for attention equally, and the user ends up noticing none of them.
What goes wrong: A modal opens, and at the same moment: the background dims, the modal scales in, the close button rotates, the heading types out letter by letter, and three form fields staggered-appear. Each of those might look OK alone. Together, they're chaos.
What to do:
- Primary animation: the most important motion, moves first or most prominently.
- Secondary animation: supporting motion, starts slightly after the primary or at lower visual weight.
- Ambient animation: background-level motion that doesn't compete for attention.
A modal opening should animate one primary element (the modal itself) while its contents appear without additional animation. Resist the urge to animate everything.
Mistake 5: Decorative-Only Motion
Motion that doesn't communicate anything is decoration. Decoration has a cost: performance, accessibility, time-to-task, and user attention. Sometimes decoration is worth the cost (brand personality for a consumer product). Often it isn't.
Common offenders:
- Scroll-triggered animations on marketing pages that don't add information
- Hover effects on every element (everything is hover-able = nothing is)
- Animated icons that loop infinitely in the corner of a dashboard
- Page transitions on SaaS tools where users navigate dozens of times per session
What to do: For each animation, apply the core test. If you can't name the information it communicates, either remove it or reduce it to an instant state change. Users trying to complete tasks don't want to watch your brand personality every three seconds.
Mistake 6: Over-Animation
The second cousin of decorative motion. This is when the animation is technically communicative but there's too much of it.
What goes wrong: Every list item has a staggered entrance. Every hover has a spring bounce. Every click has a ripple. Every page change has a 400ms transition. Individually, each makes sense. Collectively, the product feels slow, busy, and amateurish.
Rule: If your product has more than three "signature" motion patterns that fire frequently, you're over-animating. Pick the moments that most benefit from motion and leave the rest alone.
Reference: Linear is a good counterexample. The product has well-designed motion, but it's restrained — most interactions are instant or near-instant, and motion is used specifically to communicate state transitions (new issue appearing, status changing) rather than as ambient decoration.
Mistake 7: Inconsistent Durations and Easing Across the Product
A team ships motion without a motion system. Different designers pick different durations. One engineer uses ease-in-out, another uses a custom cubic-bezier. The product feels inconsistent in a way users can't articulate but absolutely perceive.
What to do: Define a motion token system. Minimum three durations, three easing curves.
Example tokens:
duration.fast: 150msduration.standard: 250msduration.slow: 400mseasing.standard: cubic-bezier(0.4, 0.0, 0.2, 1) — for most transitionseasing.entrance: cubic-bezier(0.0, 0.0, 0.2, 1) — for elements enteringeasing.exit: cubic-bezier(0.4, 0.0, 1, 1) — for elements exiting
Bake these into your design system. Refer to them by name, not by value. When motion feels "off" across the product, it's almost always because these tokens don't exist or aren't enforced.
Mistake 8: Designing Only for High-End Devices
Motion that looks beautiful on an M3 MacBook might be unusable on a three-year-old Android phone on a slow network. Designers who only test on their own devices ship motion that breaks for most users.
What goes wrong: Spring animations with physics rely on smooth 60fps rendering. On lower-end devices, they jank — the animation stutters, feels choppy, and makes the product feel broken. Meanwhile, the designer who shipped it sees a smooth animation on their flagship device and declares success.
What to do:
- Test on at least one mid-range Android device (not the latest flagship)
- Test on slow network conditions (throttle to 3G in DevTools)
- Consider degrading animations on low-end devices (the
prefers-reduced-motionmedia query can double as a performance escape hatch) - Measure frame rate during animations, not just visual appearance
Mistake 9: Wrong Easing Direction for the Interaction
Even when easing is non-linear, the wrong curve for the wrong direction creates subtly broken-feeling motion.
Quick rules:
- Entrance (element appearing): ease-out. Element arrives quickly and settles.
- Exit (element disappearing): ease-in. Element starts slowly and leaves fast.
- Transform in place (element changing size or state without moving): ease-in-out. Smooth both ways.
When these get reversed — ease-in on an entrance makes the element arrive slowly and stop abruptly, which feels wrong; ease-out on an exit makes the element start fast and drift away, which also feels wrong — users can't articulate why, but they perceive the product as less polished.
What the Best Products Get Right
A few products worth studying for motion that actually works.
Linear. Restrained motion throughout. State changes communicated through subtle slides and fades. No ambient decoration. Nothing takes longer than 300ms.
Arc browser. Per-interaction motion tuned specifically for each affordance. Tab switching, command bar opening, splits resizing — each has a distinct motion that communicates the action type.
Raycast. Motion at micro scale. Launching commands feels instant but with enough animation signal that you know the state changed.
Apple's native iOS apps. Obvious benchmark, but worth actually studying. The physics feel right because Apple has tuned the motion system for years. Notice how few extra animations Apple's apps add beyond the system defaults — even when Liquid Glass provides more material for motion.
Figma. Despite being a complex creative tool, Figma's motion is restrained. Panels open quickly. Canvas manipulation is instant. Animations exist where they communicate state change and nowhere else.
How to Actually Build Good Motion Into Your Team's Work
Four practical moves.
Establish motion tokens before you ship motion. Pick 3 durations, 3 easing curves, and put them in your design system. Enforce them in code. This single step fixes most consistency problems.
Always design the reduced-motion state. For every animation, specify what happens when prefers-reduced-motion is on. If you can't define a good reduced-motion fallback, the animation probably isn't important enough to keep.
Run the animation audit. List every animation in your product. For each one, answer: what information does this communicate? Delete any animation whose answer is "delight" or "personality." You'll keep the motion that matters and lose the motion that's just costing performance.
Test on real devices. Not your laptop. Real phones. Real networks. If your animations break on a $300 Android phone, they're broken — no matter how good they look on your development machine.
When Motion Is Actually Worth It
To end on the positive: motion, used well, does things text alone cannot.
It communicates spatial relationships — a detail view that slides in from the right tells users "this is a child of the list item you tapped" in a way that no text explanation matches.
It communicates state changes — an item that slides and fades away makes "this is gone" feel permanent in a way an instant disappearance doesn't.
It communicates cause and effect — a modal that scales up from the button that triggered it anchors the relationship between action and result.
It reduces perceived latency — skeleton loaders and progressive disclosure make a 2-second load feel faster than a blank screen, even though the total time is identical.
It expresses brand personality — this is the "delight" use case, and it's legitimate when done sparingly. Just don't confuse "decoration for brand" with "motion for function."
Most motion you ship should be functional. A small amount can be personality. The ratio matters.
Frequently Asked Questions
What are motion design principles?
Core principles: motion should communicate information (cause-effect, state change, spatial relationship), respect natural physics (easing curves, not linear), have appropriate timing (100–500ms depending on scope), follow hierarchy (primary vs secondary motion), and respect user accessibility settings (prefers-reduced-motion). Motion without communicative purpose is decoration — sometimes justified, often not.
When should I use animation in UI?
Animate when the motion communicates something text or static design cannot: a spatial relationship between elements, a state change with meaning, cause and effect between an action and a result, or the hierarchy of elements appearing. Skip animation when it's purely decorative, when it adds latency to task completion, or when it competes with content for attention.
How long should UI animations be?
Micro-interactions (button presses, toggles): 100–200ms. Mid-level transitions (dropdowns, tooltips): 200–300ms. Large transitions (page changes, modal opens): 300–500ms. Anything over 500ms feels laggy in UI contexts. Material Design's reference of 200ms for standard transitions is a good default.
What is the best motion design tool for 2026?
Depends on the work. For interactive prototypes: Figma's built-in Smart Animate for most cases, ProtoPie for complex multi-state prototypes. For shippable motion: Rive for vector-based interactive animation (now the preferred choice for many teams), Lottie for After Effects-exported animations with broad runtime support, Framer Motion for React-based web animation, and native CSS for simple UI transitions.
Why is motion important in UX?
Motion communicates information that static design can't: cause-effect relationships, state changes, spatial hierarchy, and progression through a flow. Done well, it reduces cognitive load and improves task completion. Done badly, it adds latency, triggers accessibility issues, and distracts from content.
What is the difference between animation and motion design?
Animation is the broader craft of moving visual elements. Motion design in UI contexts is specifically about using movement to support communication and usability in interfaces. Animation can be decorative; motion design should be functional. A logo reveal is animation. A modal that slides in from the button that triggered it is motion design.
Looking for motion design tools, Lottie libraries, and Rive files that actually integrate cleanly with your stack? Browse Mantlr's curated [motion design tools](https://mantlr.com/categories), [animation libraries](https://mantlr.com/categories), and [prototyping tools](https://mantlr.com/categories/prototyping-tools) — vetted by designers who ship real products.
To understand the motion systems behind the major 2026 design languages, read [Apple's Liquid Glass vs Google's Material Expressive](https://mantlr.com/blog/liquid-glass-vs-material-expressive). For microinteraction-level motion patterns tied to conversion, see [25 Microinteractions That Actually Convert](https://mantlr.com/blog/microinteractions-convert-25-patterns). For the accessibility compliance context, see [Accessibility Lawsuits Are Accelerating in 2026](https://mantlr.com/blog/accessibility-lawsuit-compliance).
Primary source references (all retrieved April 24, 2026):
- Apple Human Interface Guidelines — Motion
- Apple: Liquid Glass Developer Documentation (WWDC 2025, Alan Dye spokesperson)
- Material Design 3 motion guidelines
- Google: Expressive Material Design research (46 studies, 18,000 participants)
- WCAG 2.1 SC 2.3.3 — Animation from Interactions
- Google: Interaction to Next Paint (INP) — ≤200ms target
- NIH: Vestibular Disorders Statistics
- Disney's 12 principles of animation — historical foundation