The best microinteraction is the one nobody notices

What is a microinteraction, and how is it different from an animation?

Microinteractions are the smallest working unit of interface behaviour: a contained trigger and feedback pair that does exactly one job. Something happens, either the user acts or the system changes state, and the interface answers in a small, local, specific way. Nielsen Norman Group, building on Dan Saffer’s framework, sorts the useful ones into four functions: communicating system status, preventing errors, encouraging engagement, and carrying brand identity.¹ An animation is any movement on a screen. A microinteraction is movement that reports something.

That distinction decides whether the motion earns its milliseconds. A spinner that turns at the same rate whether the request finishes quickly or stalls is an animation: it moves, and it tells the user nothing they did not already know. A submit button that runs from idle to working to confirmed is a microinteraction, because each frame maps to a real state.

Scope is the practical test. If the feedback settles one question, a toggle flipped, a field validated, an item added to a basket, you are designing a microinteraction. If it spans several decisions, you are designing a flow, and flows need the journey-level thinking set out in the design thinking process.

Do microinteractions pay, or are they just polish?

No credible public study isolates the change “we added microinteractions” and measures the revenue that followed. What is measured, repeatedly and at scale, is responsiveness, and microinteractions are one of the few levers a design team controls that changes how responsive a product feels. Google and Deloitte analysed 30 million user sessions and found that a 0.1 second improvement in load speed lifted retail conversion by 8.4 percent, travel conversion by 10.1 percent, average retail order value by 9.2 percent, and cart additions on luxury sites by 40.1 percent.²

One tenth of a second. That is the resolution at which this game is played, and it sits well inside the range a designer moves an interface by choosing one transition duration over another.

Two warnings about the evidence here, because this topic attracts bad numbers. First, much of what circulates in trend roundups about microinteractions is invented: large retention and engagement gains quoted with no study, no sample and no method behind them. Treat any figure in this area that does not name its sample as marketing. Second, the speed studies measure page load, not motion design. The line from a well-timed hover state to revenue is an inference, and we would rather say so than dress it up as a finding.

How do microinteractions change perceived performance?

Perceived performance is how fast a user judges an interface to be, driven by feedback and progress cues rather than by elapsed milliseconds. It is a separate lever from real performance, and it is the one design owns outright. A skeleton screen, an optimistic update, or an instant local state change can make an unchanged backend feel faster.

The research supports the mechanism. A controlled study of mobile waiting scenarios, published through ACM, found that progressive loading and skeleton screens improved users’ perception of loading speed, reduced their awareness of time passing, and produced a better emotional response than spinners or blank screens.⁴ Nielsen Norman Group gives the reason plainly: a skeleton screen shows structural progress, so the user watches the page assemble, while a spinner shows only ambiguous motion that could mean anything.⁵

Optimistic UI is the aggressive version of the same idea. The interface commits the change locally the moment the user acts, then reconciles with the server. The item moves, the message appears, the count increments. If the request fails, the interface rolls back and says so, which is the part teams skip and the part that decides whether users trust the pattern.

Any wait you cannot remove, you can narrate. Progress that shows structure beats motion that shows only that something is happening.

Does perceived speed excuse a slow product?

No, and the field data suggests most teams have not earned that argument yet. In 2025 reporting based on real-user Chrome data, 56 percent of desktop origins and 48 percent of mobile origins passed all three Core Web Vitals thresholds, while Largest Contentful Paint remained the most-failed mobile metric, with 62 percent of mobile origins rated good.⁶

The commercial gap is wide. The same analysis reports 40 to 50 percent higher conversion rates for sites with Largest Contentful Paint under two seconds than for sites sitting in the four to five second band.⁶ Patience is priced in as well.

Perceived performance buys goodwill on the wait you cannot engineer away. It does not buy a pass on the wait you have not tried to remove.

What duration and easing does a microinteraction need?

Most published UI animation principles hand teams a fixed millisecond value and stop there. That is the wrong starting point, because duration and easing carry meaning independently of whatever they are moving.

Fast, linear motion reads as mechanical and system driven. Slower motion on an eased curve reads as considered and physical. Mismatch the two and users feel that something is off without being able to name it: a slow ease-out on a rapid toggle makes a switch feel sticky, and a linear snap on a dialog that should feel weighty makes the whole product feel cheap.

Three rules travel better than any single number.

• Distance sets duration. A small control moving a short way needs less time than a sheet crossing the screen. One global duration applied to both will be wrong for at least one of them.
• Exits run faster than entrances. Content arriving is information the user wants to track. Content leaving is in the way.
• User-driven motion should track the input. Follow the finger or the cursor, and only ease once the user lets go. Motion that refuses to be interrupted or reversed feels broken.

The calibration test is subjective and reliable: if a colleague compliments the animation itself, it probably ran too long. The best microinteraction is felt rather than noticed. Users should register that the interface responded, not that someone added motion to it.

Do microinteractions hurt accessibility or performance?

They can, and both fixes are cheap. Motion that scales, parallaxes or shifts large areas can trigger nausea, dizziness and migraine in people with vestibular sensitivity. The operating system already carries the user’s answer, so honour it.

@media (prefers-reduced-motion: reduce) {
  .sheet { transform: none; transition: opacity 120ms linear; }
}

Reduced motion does not mean no feedback. The state change still has to be visible, so swap movement for a cross fade or an immediate change. The user keeps the information and loses the vestibular load. A blanket rule that kills every transition in the product is better than ignoring the setting, but it is not the finished answer.

Performance has a similarly short fix. Animate transform and opacity, which the compositor can handle without re-running layout, and avoid animating width, height, top and left. Anything running on the main thread competes with the work the user is actually waiting for, which is the exact opposite of the point.

Two more that get missed. Motion must never be the only channel carrying meaning, so pair it with text, colour and a status message screen readers can reach. And looping or long-running animation should stop when it is off screen, because battery is a real user cost even when nobody files a ticket about it.

How do you stop microinteractions becoming a pile of one-offs?

Treat them as a system rather than a series of good ideas. Without shared timing and easing tokens, every animation ships with its own rhythm, and the product reads as inconsistent even when each individual moment is well crafted. Put a small set of durations and curves in the design system, name them by intent rather than by value, and make reaching for one easier than writing a new one.

Then separate the two families, because they behave differently.

Error feedback is where a shaking input field earns its keep and also where it goes wrong. The motion should be short and should aim attention at the field, not perform frustration back at the user. It must never be the only signal either: colour, icon and message do the work, and motion only directs the eye.

On volume, the answer to “how many is too many” is a budget rather than a count. Motion is attention, and attention does not divide. If two things animate at once in the same region they compete, and the user reads neither. Audit a screen by asking what each moment tells the user. If a moment cannot answer, delete it.

Where should a team start this week?

Pick one high-traffic flow, sign-up, checkout or the primary create action, and work through it in order.

1. List every trigger in the flow and what the interface currently says back. The blank moments are the backlog.
2. Replace spinners on content-shaped waits with skeletons that match the real layout, not generic grey bars.
3. Make the primary action optimistic wherever failure is recoverable and the rollback is honest.
4. Move duration and easing into tokens, then delete the values scattered through individual components.
5. Add a reduced motion path to each one, then run the whole flow with the setting switched on.

The microinteraction examples worth copying all share one property: they answer a question the user was already asking. None of this needs a rebuild. It needs a designer and an engineer in the same file for a week, plus the discipline to delete motion that cannot explain itself. When motion gets scoped last it ships as decoration, which is why these questions belong in product development planning and in product development consulting scopes rather than in a polish phase at the end. If you want that audit run against a live flow, get in touch.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.