When does a microinteraction earn its complexity vs add overhead?

A microinteraction earns its complexity when it does a real job, confirming an action, communicating a state, or smoothing a transition the user actually benefits from, and it becomes overhead when it decorates without doing any of those things. The deciding test is whether the interaction performs a job worth both the effort to build it and the user’s attention to receive it. Function is what justifies the flourish. A microinteraction with no function is not craft, it is cost wearing the costume of craft.

The reason this test holds is that a microinteraction is never free on either side of the ledger. It costs the team time to design, build, and maintain, and it costs the user a sliver of attention and sometimes a sliver of time every time it fires. When the interaction returns confirmation or clarity, those costs are repaid: the user knows their tap registered, sees that a toggle is now on, or follows an element from one place to another without losing their bearings. When it returns only decoration, the costs are still paid but nothing comes back, and across a busy interface those unpaid costs accumulate into clutter and drag.

Consider the difference between two animations on the same button. A submit button that, on tap, shows a brief inline spinner and then a checkmark is doing three jobs at once: it confirms the tap was received, communicates that work is happening, and signals when the work is done, all without sending the user to a new screen to find out. That microinteraction has clearly earned its build. Now consider a button that, on tap, ripples, bounces, and emits a small burst of particles before doing anything. The ripple might confirm the tap, but the bounce and the particles communicate nothing the user needed; they are overhead stacked on a moment that only required a single clear acknowledgment.

The wrinkle is that the same animated effect can be earning or wasteful depending on context, so the judgment is about the job, not the technique. A satisfying toggle animation earns its place on a control whose state genuinely matters and is worth making legible. The identical animation on a decorative element that has no state to communicate is pure overhead. This is also why earning is not a function of how impressive the interaction looks; an unglamorous, near instant state change that clearly confirms an action is more justified than an elaborate sequence that communicates nothing.

This cuts directly against the instinct to add microinteractions everywhere because they show craft. Spreading them across every element does not demonstrate craft, it demonstrates the absence of editing, and the interactions that carry no function are the first thing a discerning user reads as fussy. Real craft shows in restraint, in the microinteractions you chose not to build as much as the ones you did, because every one that survived is doing a job.

So before you build or keep a microinteraction, name the job it does in a single sentence: it confirms this, it communicates that, it smooths this transition. If you can name the job and it is one the user benefits from, the complexity is earned, build it well and keep it quick. If the only sentence you can write is that it looks nice or shows polish, it is overhead, and the right move is to cut it and spend that effort on the interactions that actually do work.