Commerce·December 2025·9 min read

How Motion Design Increases Buyer Confidence

Motion in a commerce interface exists to communicate a state change the interface can't otherwise show fast enough for a user to track. It stops working the moment it's added for mood instead of information, and it becomes an accessibility failure the moment it can't be turned off.

What motion is actually for in a commerce interface

Three jobs justify adding motion to an interaction: confirming that an action registered, linking a visible cause to its effect, and preserving context across a state change. Anything outside those three is decoration, and decoration is exactly what a user with a slow connection or a vestibular disorder pays the cost for.

None of this requires treating motion as a psychology problem. It's an information-design problem with a well-defined accessibility contract attached, and the engineering discipline is closer to designing error states or loading states than to picking a brand color.

The real failure mode of static-only interfaces

An abrupt state change, content that appears or disappears with no transition, forces a user to re-orient and re-scan the screen. That's a well-understood interaction-design cost: it adds a moment of "wait, what happened" between the action and the next decision, at exactly the point in a purchase flow where hesitation is most expensive to the business and most frustrating to the shopper.

The opposite failure is just as common: teams overcorrect by animating everything, on the assumption that more motion reads as more polish. Motion that doesn't map to a real state change adds visual noise on top of the original problem instead of solving it, and it's the pattern this piece argues against as directly as it argues against static-only interfaces.

The one hard constraint: motion must be optional

WCAG Success Criterion 2.3.3, Animation from Interactions, requires that motion animation triggered by user interaction "can be disabled, unless the animation is essential to the functionality or the information being conveyed" (W3C WCAG 2.1 — Understanding SC 2.3.3).

The rationale isn't aesthetic. The same guidance states plainly that "the impact of animation on people with vestibular disorders can be quite severe," with triggered reactions including nausea and migraine headaches, sometimes serious enough to require bed rest (W3C WCAG 2.1 — Understanding SC 2.3.3). Parallax scrolling and large-object scaling or panning are named as common triggers.

Reading the signal the browser already gives you

The prefers-reduced-motion media feature lets a user's operating system tell every website whether they've asked for reduced motion, with two possible values: no-preference and reduce (MDN — prefers-reduced-motion). It's also defined at the specification level in the CSS Working Group's Media Queries Level 5 draft (W3C — Media Queries Level 5).

@media (prefers-reduced-motion: reduce) {
  .add-to-cart-confirm,
  .checkout-step-transition {
    animation: none;
    transition: none;
  }
}

The same preference is queryable in JavaScript through matchMedia, which matters for canvas-based or JS-driven animations that CSS alone can't stop, and the preference can change without a page reload, so code should listen for the change event rather than checking it once (web.dev — prefers-reduced-motion).

Triggered vestibular reactions include nausea, migraine headaches, and in serious cases the need for bed rest to recover. That's the actual stake behind a media query, not a matter of taste.

What "essential" motion means under WCAG

The criterion draws a real line between decorative and functional motion. A progress indicator during a multi-step checkout conveys real state and is closer to essential; a parallax hero image on a homepage conveys nothing functional and should be disableable, or simply not shipped, by default.

Where motion functions as feedback, not decoration

Confirming an action

A brief state change on an "add to cart" button, a fill animation or a checkmark, confirms the click registered before the page has fully updated. This is the same category of feedback a physical button click provides mechanically, replicated for a flat touchscreen surface.

The failure case is a button that changes state on click but takes no visible action for a full second afterward. The animation confirmed the click; it didn't confirm the request succeeded, and conflating the two teaches users to distrust the feedback the next time it plays.

Linking cause and effect across a state transition

A cart drawer sliding in when an item is added ties the action directly to its visible consequence. Compare that to an item appearing in a cart icon count with no visible connection to the click that caused it, which asks the user to trust that something happened rather than showing them.

The same logic applies to form validation. An inline error that fades in next to the specific field that failed links the feedback to its cause directly, which is a meaningfully different experience than a single error banner at the top of a long form that leaves the user hunting for what actually went wrong.

Signaling progress without misrepresenting it

A skeleton screen communicates the layout about to load; a spinner communicates nothing about duration or content. Neither should be used to disguise a genuinely slow response as something else, because the underlying latency is the actual problem, and motion that masks it delays the fix rather than solving anything.

Testing motion under real conditions, not ideal ones

A reduced-motion implementation tested only through a browser DevTools emulation flag hasn't actually been tested against the OS-level setting real users have enabled, and the two don't always agree in every browser. Testing directly on the operating system's accessibility setting is the only way to know the actual behavior a user with that preference will see.

CPU throttling in the DevTools performance panel surfaces jank that a fast development machine hides completely. An animation that looks smooth on a current-generation laptop and stutters under 4x throttling is a preview of what a mid-range phone will show a real shopper.

Motion that runs on the main thread competes with the same thread rendering the rest of the page. Animating transform instead of layout-triggering properties like top or width lets the browser move the work off the main thread entirely (MDN — CSS and JavaScript animation performance).

Why the property you animate changes the performance story

Properties that trigger a layout reflow force the browser to recalculate positions for potentially the whole page before it can paint the next frame. Properties that only require compositing, chiefly transform and opacity, can be sampled and rendered without touching layout at all, which is what makes them safe to animate on lower-powered devices (MDN — CSS and JavaScript animation performance).

Heavy, main-thread-blocking animation work also degrades Interaction to Next Paint, the Core Web Vitals metric for responsiveness, because a blocked main thread can't process the user's next tap or click (web.dev — Interaction to Next Paint). A checkout animation that measurably delays the next input isn't a UX win regardless of how it looks in isolation.

Implementing JS-driven motion without fighting the platform

For animations that CSS transitions and keyframes can't express, such as a physics-based drag on a product image gallery, the Web Animations API gives the browser the same off-main-thread optimization opportunities as native CSS animation, instead of hand-rolling frame updates with requestAnimationFrame (MDN — Web Animations API).

Either approach still has to respect prefers-reduced-motion. A Web Animations API call can check matchMedia('(prefers-reduced-motion: reduce)').matches before starting, and should skip straight to the animation's end state when the preference is set, rather than playing a shortened version of the same motion.

Motion budget: what to animate and what to leave alone

Interaction	Worth animating	Why
Add to cart confirmation	Yes	Confirms the action registered, low implementation cost
Checkout step transition	Yes, minimally	Preserves context between steps, must respect reduced motion
Price update after selecting a variant	Yes, subtly	Links the changed price to the action that changed it
Page-level parallax scroll	No, by default	Named vestibular trigger under WCAG, rarely functional
Marketing carousel autoplay	No, or user-controlled only	Not triggered by user action, often ignores reduced-motion settings

Shipping motion responsibly

Does this motion communicate a real state change, or is it decorative.
Does it respect prefers-reduced-motion, tested with the OS setting actually enabled, not assumed.
Is it triggered by a user action, and can that be disabled per WCAG 2.3.3, or is it genuinely essential to the information conveyed.
Does it animate transform or opacity rather than layout-triggering properties.
Has it been tested on a throttled, lower-powered device, not only a development machine.

A team that runs every new animation through that list before shipping ends up with less motion overall, not more, because most of what gets proposed fails the first question. That's the correct outcome. Motion earns its place by carrying information, not by making the interface feel busier.

The checklist also forces a useful conversation earlier than it would otherwise happen. A designer proposing a parallax hero has to answer whether it's essential under WCAG 2.3.3 before an engineer builds it, rather than after an accessibility audit flags it in production and the fix competes with a launch deadline.

FAQ

Does prefers-reduced-motion mean turning off all animation?

No. It means removing or replacing non-essential motion, particularly large-scale movement like parallax and panning, while functional feedback like a button state change can often remain, scaled down (MDN — prefers-reduced-motion).

Is motion design an accessibility requirement or a nice-to-have?

Interaction-triggered motion that can't be disabled is a WCAG 2.1 conformance failure under Success Criterion 2.3.3, not a stylistic preference (W3C WCAG 2.1 — Understanding SC 2.3.3).

What's the actual WCAG rule that applies here?

Success Criterion 2.3.3, Animation from Interactions: motion triggered by an interaction must be able to be disabled unless it's essential to the functionality or the information it conveys.

Should loading spinners always be replaced by skeleton screens?

Not always, but a skeleton screen communicates more about what's coming than a spinner does, which tends to reduce the disorientation of content appearing all at once. Neither should be used to hide a response time that actually needs fixing.

Does adding motion to a checkout flow slow down the checkout?

Only if it's implemented poorly. Animations built on transform and opacity run on the compositor thread and don't block the main thread the way layout-triggering properties do.

How do I test that my reduced-motion implementation actually works?

Enable the OS-level reduced motion setting, not a browser dev tool emulation alone, and verify the media query listener responds to the change event, since a user can toggle the preference without reloading the page (web.dev — prefers-reduced-motion).

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.