Skip to main content
All Insights

Motion Design

Why Motion Should Be Quiet

Animation's job is to explain what changed and where things went. Everything past that is time the user spends waiting for your product to finish performing.

Motion Design

6 min read

Annabling Marketing · August 2026

Interface motion has one legitimate job, and it splits neatly into two questions. What changed? — a thing appeared, a thing left, a value updated, a state flipped. And where did it come from, or go to? — this panel slid out of that button, this row moved to the archive, this card expanded into the page you're now looking at.

Motion is extremely good at answering both. Screens are flat and instantaneous by default, so without it every change is a jump cut, and jump cuts make people re-scan the whole screen to work out what happened. A well-judged 200ms transition removes that re-scan entirely.

Motion is not good at making a product feel premium. That is a widespread and expensive misunderstanding. What reads as premium is responsiveness — and animation, by definition, delays the moment the user gets what they asked for.

Numbers, not vibes

Most bad interface motion is bad because it's too slow, and it's too slow because the duration was chosen by feel while the designer watched it in isolation, twenty times in a row. Watched once, in the middle of a task, everything feels slower. Start from defaults instead:

  • Small elements, small distances — toggles, checkboxes, hover and focus states, icon swaps: 100–150ms.
  • Standard UI transitions — dropdowns, tooltips, accordions, inline expansion, toasts: 150–250ms.
  • Large surfaces — modals, side sheets, bottom sheets, full-width drawers: 250–400ms.
  • Page or route transitions — rarely worth more than 400ms, and past roughly 500ms the product stops feeling responsive and starts feeling slow.

The variable that should drive duration is distance and area, not importance. A large element travelling across the viewport needs longer than a small one moving a few pixels, because our expectations about physical movement carry over. Important-but-small elements do not deserve a slow animation; a status chip fading in over 400ms just looks broken.

Easing follows the same physical logic. Things entering the screen should decelerate — fast at the start, settling at the end — because they are arriving. Things leaving should accelerate away, because the user has already stopped caring about them. Things that move within the screen and stay there want symmetrical easing. Linear belongs only to motion with no mass: progress bars, spinners, marquees.

And exits should be quicker than entrances — roughly two thirds the duration is a good starting point. Closing a dialog is a decision the user has already made. Making them watch it leave at the same pace it arrived is making them watch a decision they've finished with.

The best interface motion is the kind nobody can describe afterwards, but everybody notices the moment you remove it.

When motion actively harms comprehension

There is a category of animation that isn't merely decorative — it makes the product measurably harder to use.

Animation that delays feedback. If tapping a control starts a 300ms animation before the state visibly changes, you have made the product slower in order to make it look considered. The state change should begin immediately; the animation describes it, it doesn't precede it.

Scroll-jacking and parallax on text. Taking over the scroll wheel breaks the one interaction every user already understands perfectly. Parallax that moves body copy at a different rate to its container makes reading genuinely harder, and on long pages it is disorienting rather than impressive.

Reveal-on-scroll applied to content people came to read. Fading in a hero once is fine. Fading in every paragraph of an article means the reader is permanently one beat behind their own scrolling, and it breaks browser find-in-page for anything not yet revealed.

Too many things moving at once. Attention tracks one moving object well and several badly. If a grid of cards animates in, keep the stagger tight — around 40–80ms between items — so the group reads as a single gesture. Stretch it to 200ms per card and you've turned one event into eight, and the last one arrives long after the user started reading the first.

Motion that duplicates information already carried by layout. If a panel is obviously a panel, sliding it in from an arbitrary edge adds nothing except duration. Ask what the animation is telling the user that position, size, and elevation are not.

Reduced motion is a design constraint, not a switch

Some people get motion sickness, vertigo, or migraine from screen movement — large-area movement, parallax, and zooms are the main offenders; small opacity changes generally are not. Those users set a system-level preference, exposed to the web as prefers-reduced-motion. Treating that preference as an afterthought produces two predictable failures.

The first is doing nothing, which is straightforwardly excluding people. The second is the lazy fix: a blanket rule that sets animation and transition duration to zero across the whole site. That can leave elements stranded in their pre-animation state — an item styled at opacity 0 waiting for a transition that will never run is now permanently invisible. A reduced-motion implementation that hides content is worse than no implementation at all.

The right approach is to design two versions of every meaningful transition from the start. The full version, and a reduced version where movement is replaced by a cross-fade or an instant change — but where the state change is still perceivable. If a dialog now appears with no transition, elevation, backdrop, and a decisive focus move have to do the work motion was doing. If a list item is removed instantly, something else has to signal that it went to the archive.

Designing for this constraint usually improves the default experience too, because it forces you to check whether the animation was carrying real information or just covering for a layout that didn't explain itself.

Where motion genuinely earns its place

None of this is an argument for static interfaces. It's an argument for spending the budget where it does work:

  1. Continuity between states. A card that expands into a detail view, with the image and title travelling to their new positions, tells the user exactly where they are and how to get back. This is the single highest-value use of motion in product design.
  2. List changes. Insertion, removal, and reordering are close to unreadable without animation. When items shift to make room, the movement is the explanation.
  3. Origin and destination. An item flying towards the archive tab, or a file animating into a folder, answers "where did it go" more efficiently than any toast message.
  4. Progressive disclosure. Expanding a section while pushing subsequent content down shows that nothing was replaced, only added.
  5. Waiting. Skeletons and indeterminate indicators are motion doing honest work — provided they reflect what's actually happening.

Every one of those is motion in service of understanding. If you can't say which question a piece of animation answers — what changed, or where did it go — you're looking at decoration, and decoration on a control someone uses forty times a day is not a neutral choice. It's a small tax, collected forever.

Need motion that works as hard as it looks?