UI Design · Motion

Micro-Interactions That Earn Their Keep (and the Ones That Don't)

Motion should answer a question the user just asked — where did that go, did it work, is it loading. If it isn't answering something, it's probably just noise.

Jaymin Maheta 23 Mar 2026 7 min read

Share:

Interface with subtle animated transitions

The test for whether motion belongs

Before adding any animation, ask what question it answers. A button press that scales down slightly answers "did my tap register?" A row that fades out on delete answers "did that action succeed?" A skeleton loader answers "is something happening or is this broken?" Motion tied to a real question earns its place.

Motion added purely because it "feels nice" — a bounce on every card hover, a slide-in on every list item on every page load — doesn't answer anything. In an enterprise tool used for hours a day, that kind of decoration becomes friction fast, not delight.

Worth it vs. not worth it

Worth it: state-change confirmation

A checkbox that visibly fills, a saved toast that slides in — these confirm an action landed. Skipping them leaves users unsure whether their click did anything.

Worth it: loading and progress indication

A skeleton screen or progress bar tells the user "working, not broken." Its absence is one of the most common reasons users double-click a button that's already processing.

Worth it: spatial continuity on navigation

A modal that grows from the button that opened it, rather than appearing instantly centered, helps the user's mental model track where they are in the interface.

Not worth it: animating every list on every load

A staggered fade-in on a data table a power user opens fifty times a day stops being delightful by the third open and starts being a tax on their time.

Not worth it: decorative hover effects on non-interactive elements

A card that lifts on hover but isn't clickable teaches users a false affordance — motion should signal what's true about the element, not just look nice.

Not worth it: long transitions that block the next action

Anything over roughly 300ms starts to feel like the interface is making the user wait rather than communicating with them. Fast, subtle motion; nothing users have to sit through.

Always respect reduced motion

`prefers-reduced-motion` isn't a niche accessibility flag — for users with vestibular disorders, it's the difference between a usable product and genuine physical discomfort. Every animation added for delight needs a reduced-motion fallback that keeps the functional confirmation (the state did change) while dropping the movement itself. This is a hard requirement, not a nice-to-have polish item.

The takeaway

Motion earns its place by answering a real question — did this register, is it working, where am I — in under 300ms. Motion added for its own sake wears out fast for daily users and adds friction instead of delight. Every animation needs a `prefers-reduced-motion` fallback, no exceptions.

Let's talk about your product