Microinteraction

Microinteractions are the details that show a system has registered what you did. Each one handles a single task, such as toggling a setting, confirming that a message was sent or showing that a file is uploading. Individually they are tiny; together they are a large part of UI design and decide whether an interface feels responsive and trustworthy or vague.

They are often confused with decorative animation. A microinteraction exists to communicate state or feedback. A spinning logo or a parallax background is animation, but it tells the user nothing about what they just did.

How it works

A common framework, popularised by the designer Dan Saffer, breaks every microinteraction into four parts: a trigger that starts it, such as a tap; rules that decide what happens; feedback that shows the result, such as a colour change, sound or short movement; and loops and modes that govern what happens over time or on repeat. Designing each part deliberately avoids feedback that is missing, confusing or annoying.

Motion should be quick and purposeful, usually a fraction of a second, and is easiest to judge in a prototype rather than a static design. Operating systems let people ask for reduced motion, and well-built sites respect that setting, which supports accessibility.

Timing is part of the design. Feedback for a tap should appear immediately, because any delay makes people think the tap did not register, while transitions between states usually work best when short. If an action takes longer, such as uploading a file, the interface should show progress rather than a frozen screen. You can check your own site by pressing every important button on a slow connection, which most browsers can simulate in their developer tools, and watching what happens in the gap.

Example

On a restaurant's booking page, visitors pressed Reserve, saw nothing happen for two seconds and pressed again, creating duplicate bookings. The fix adds three microinteractions: the button shows a small spinner and disables itself after the first tap, a green tick and a confirmation line appear when the booking is saved, and a clear message replaces the spinner if the connection fails.

The team also considers how each microinteraction reaches someone who cannot see it. The confirmation is written as text on the page and announced to screen readers, not shown only as a green tick. The error message names the problem in words, saying that the connection was lost and nothing was booked, and offers a Try again button. For visitors who have asked their device for reduced motion, the spinner is replaced by a static Saving message.

Why it matters for your business

Good feedback prevents errors that cost real money and time, such as double orders, abandoned forms and emails asking whether something went through. It also makes a site feel more polished than its competitors without adding features. The trade-off is restraint: too much motion slows people down, distracts and can make some visitors feel unwell, so use microinteractions where they answer a question rather than everywhere. Most of these details cost little when they are planned from the start, and far more to add later once a problem shows up in customer complaints.

Common mistakes

• Giving no visible response when a button is pressed or a form is submitted.
• Adding slow, showy animations to every hover and scroll.
• Ignoring the reduced-motion setting that some visitors rely on.
• Showing errors only after the whole form is submitted instead of beside the field that caused them.

Questions people ask

What are examples of microinteractions?

Common examples include a button darkening when pressed, a toggle sliding from off to on, a password field showing strength as you type, a basket icon updating its count when you add an item, pull-to-refresh on a phone, and a field turning red with a message when an email address is invalid.

Do microinteractions slow down a website?

Well-built ones do not. Simple state changes and short transitions handled with CSS are very light. Problems come from heavy animation libraries, large animated files or effects that run constantly while scrolling. Keep motion short, prefer CSS for simple effects and test on a mid-range phone rather than a fast laptop.

Are microinteractions important for accessibility?

Feedback helps everyone, including screen reader users, provided it is announced and not only shown visually. Motion can cause problems for people with vestibular disorders, so sites should respect the reduced-motion setting. Feedback should also never rely on colour alone; pair a colour change with text or an icon.