Microinteractions in UI Design: Examples, Principles and Best Practices

Microinteractions are small, single-purpose moments in an interface, such as a button showing it's working, a field confirming valid input or a toggle switching on. Each has a trigger (what starts it), rules (what happens), feedback (how users see it happen) and loops or modes (how it repeats or changes). Good microinteractions make status visible, prevent mistakes and confirm actions. Keep them fast, consistent and purposeful, never rely on motion alone to carry meaning, and respect users' reduced-motion settings.

A microinteraction is a contained product moment that does one thing: set an alarm, like a post, save a draft, apply a filter, switch a setting. The term was popularized by designer Dan Saffer, who argued that the small details are often what separate products people enjoy from products they merely tolerate.

Most interfaces are made of hundreds of them. They're where the principles of UI design, especially visibility of system status and feedback, become concrete.

Saffer's model breaks every microinteraction into four parts. Designing each part deliberately avoids half-finished interactions.

Animation is one possible form of feedback, not the microinteraction itself. A text change from “Save” to “Saved”, a colour change on a valid field or a haptic tap on a phone can all be effective feedback with no motion at all. Start with what the user needs to know, then decide whether motion helps them understand it.

Buttons need distinct states: default, hover, focus, pressed, disabled and loading. When an action takes time, show that it's in progress on the button itself, prevent repeat submissions and confirm the result. A payment button that looks unchanged for several seconds invites a second click and a duplicate charge.

Nielsen's classic response-time limits are a useful guide: around 0.1 seconds feels instantaneous, around 1 second keeps the user's flow of thought, and around 10 seconds is about the limit of attention before users need progress information. See response times: the 3 important limits.

Inline validation is one of the most useful microinteractions when timed well. Validate a field after the user has finished with it, not on every keystroke, so they aren't told an email is invalid before they've typed it. Once an error is shown, update it as they correct it, and confirm when it's fixed. Show requirements such as password rules up front and tick them off as they're met, rather than revealing them only after failure. Pair each state with text, not just a red or green border.

A switch should take effect immediately; if a setting needs saving, use a checkbox and a save button instead. Make the current state unambiguous with position, colour and, where space allows, a text label. If a change fails to save, revert the switch and explain why. Toggle states must also be exposed to assistive technology so screen reader users hear “on” or “off”.

Toasts suit low-stakes confirmations such as “Link copied”. Don't put essential information or the only undo option in a message that disappears quickly, and leave enough time to read it. Status messages should be announced to assistive technology without moving focus, which WCAG success criterion 4.1.3 requires. Errors that need action belong next to the problem, not in a floating toast.

Use a determinate indicator (percentage or steps) when you know how long something will take, and an indeterminate spinner only for short waits. Skeleton screens that match the final layout make loading feel more predictable than a blank page with a spinner and reduce layout shift when content arrives. For multi-step flows such as checkout or onboarding, a step indicator shows where users are and how much remains.

Hover states show that something is interactive on pointer devices, but touch screens don't have hover, so never hide essential information or actions behind it. Focus states are required for keyboard users: WCAG requires a visible focus indicator (2.4.7), and WCAG 2.2 adds that focused elements shouldn't be entirely hidden by other content such as sticky headers (2.4.11). Design focus states as deliberately as hover states rather than removing the browser default.

Touch interfaces add gestures, haptics and system conventions. Pull-to-refresh, swipe-to-delete and long-press menus are efficient but invisible, so provide a visible alternative for every gesture. Haptic feedback can confirm important actions but becomes noise if overused. Follow platform conventions from Apple's Human Interface Guidelines and Material Design so interactions behave as users expect on each platform. See mobile app UX design.

Motion should explain change: where something came from, where it went or how two states relate. Most interface transitions work best short, typically a few hundred milliseconds or less, with larger movements taking slightly longer than small ones. Use easing that starts fast and settles gently for elements entering the screen. Animate properties such as transform and opacity, which browsers can animate smoothly, rather than layout properties that force the page to reflow.

Motion can cause discomfort or nausea for people with vestibular disorders. Respect the operating system's reduced-motion setting, exposed on the web through the prefers-reduced-motion media query, by replacing movement with fades or instant changes. WCAG 2.3.3 (level AAA) asks that motion triggered by interaction can be disabled unless essential, and 2.2.2 (level A) requires a way to pause, stop or hide content that moves automatically. Never flash content more than three times per second (2.3.1).

Also make sure every state change that motion communicates is available in text and to screen readers. See accessibility in UI/UX design.

A prototype shows the feel; a written spec removes guesswork. For each microinteraction, document the trigger, rules and conditions, every visual state, timing and easing, what happens on errors or slow networks, and the reduced-motion alternative. Keep common patterns in the design system so they're built once. See design handoff for how to package this.

Test on real devices, including slower phones, and with throttled networks so loading states actually appear. Try keyboard-only and screen reader use, turn on reduced motion, and watch users in usability tests for repeated clicks or hesitation, which usually mean feedback is missing or unclear.

Microinteractions are the small feedback loops that make an interface understandable. Design the trigger, rules, feedback and loops deliberately, keep them fast and consistent, and make sure they work without motion and without a mouse. For the words inside them, see UX writing.