A microinteraction is a contained product moment built around a single task, such as switching a setting, liking a post, refreshing a list or showing that a password is strong enough. In UI design, microinteractions provide immediate feedback, show system status and make an interface feel responsive and understandable.
Microinteractions are small in scope but large in effect. A user may perform the same toggle or pull-to-refresh hundreds of times a week, so the quality of these moments shapes the perceived quality of the entire user interface. They are usually expressed through motion, state changes, sound or haptics attached to an existing UI component, rather than through new screens.
The structure of a microinteraction
A widely used model describes every microinteraction with four parts: trigger, rules, feedback, and loops and modes. Thinking in these parts forces the designer to define what starts the interaction, what happens, how the user learns the result and what changes over time.
| Part | Question it answers | Example in a toggle switch |
|---|---|---|
| Trigger | What starts it | User taps the switch, or the system changes a setting |
| Rules | What happens and in what order | Setting turns on, state is saved |
| Feedback | How the user perceives the result | Knob slides, track changes color, haptic tick |
| Loops and modes | How it behaves over time or in special states | Disabled state when the feature is unavailable |
Triggers are either manual, started by a click, tap, swipe or key press, or system-initiated, started by a condition such as a new message, low battery or a completed upload. Good manual triggers look interactive; good system triggers appear only when the information is relevant and do not interrupt unrelated work.
The rules are often invisible but decisive. For example, a rule decides whether a like can be undone, whether a form validates while typing or only after leaving a field, and whether an action is optimistic, updating the interface before the server confirms it.
Timing, motion and feedback parameters
Feedback must be fast enough to feel causal. Response within about 100 milliseconds feels instantaneous, while delays approaching one second break the sense of direct manipulation and call for a progress indicator. Motion durations are kept short so that animation explains the change without slowing the user.
| Feedback type | Typical duration | Design consideration |
|---|---|---|
| Press or hover state | 0-100 ms | Must appear without perceptible lag |
| Small state change, such as a toggle | 100-200 ms | Ease-out curve feels responsive |
| Expanding panel or card | 200-400 ms | Larger distance needs slightly longer time |
| Celebratory or brand animation | 400-1000 ms | Use rarely; must not block next action |
| Haptic tick | About 10-30 ms | Pair with visual change, never alone |
Easing matters as much as duration. Elements entering the screen usually use ease-out, decelerating as they arrive, while elements leaving use ease-in. Linear motion tends to look mechanical. Motion should also respect the operating system setting for reduced motion, replacing movement with a simple fade or an instant change.
Microinteractions and related UI patterns
Several neighboring UI design terms overlap with microinteractions, and the distinction is about scope and purpose. A microinteraction is a single-task moment; a pattern such as a toast notification or a skeleton screen can be one form of microinteraction feedback.
| Concept | Scope | Relation to microinteractions |
|---|---|---|
| Microinteraction | One task, one moment | Reference |
| Button states | Visual states of one control | Supply the feedback layer of many microinteractions |
| Toast notification | Brief, non-blocking message | Common feedback for a completed action |
| Skeleton screen | Loading placeholder for content | Feedback during waiting, part of a loading microinteraction |
| Modal dialog | Blocking interruption | Too heavy for most microinteraction feedback |
| User flow | Sequence of screens and steps | Contains many microinteractions |
Designing effective microinteractions
The best microinteractions are functional first and decorative second. Each one should answer a real user question: did my action work, what is happening now, what can I do next, or what went wrong.
| Situation | Recommended microinteraction | Reason |
|---|---|---|
| Saving a setting | Inline state change with optional subtle confirmation | Keeps attention in context |
| Invalid form input | Inline message after the field loses focus | Avoids scolding during typing |
| Action that can be reversed | Toast with an undo option | Faster than a confirmation dialog |
| Content loading over one second | Skeleton screen or progress indicator | Shows that the system is working |
| Destructive, irreversible action | Explicit confirmation step | Prevents costly mistakes |
Microinteractions belong in the design system. Defining shared tokens for durations, easing curves and feedback states keeps behavior consistent across the product and lets developers implement motion once instead of improvising it per screen. Prototypes are essential, because static mockups cannot show timing.
Pitfalls and accessibility concerns
Poorly designed microinteractions can make an interface slower, noisier or less accessible. The most common problems follow.
- Animation that delays the next action, which feels charming once and irritating the hundredth time.
- Feedback conveyed by color alone, which users with color vision deficiency may miss.
- State changes not announced to assistive technology, so screen reader users receive no confirmation.
- Ignoring reduced motion preferences, which can cause discomfort for users with vestibular disorders.
- Inconsistent behavior, such as different toggle timings on different screens of the same product.
A reliable test is to remove the animation entirely and ask whether the interaction still communicates its result. If the answer is no, the feedback depends on decoration rather than on clear state. Accessible microinteractions pair motion with a persistent visual state, a text label and a programmatic status message, so every user receives the same confirmation through at least one channel.
Put simply
A microinteraction is one of the small reactions an app gives after a simple action. When a switch slides and turns green, when a heart fills in after a tap, or when a phone vibrates slightly as a message is sent, the interface is answering the person: yes, that worked.
These moments are tiny, but people meet them constantly. When they are quick, clear and consistent, an app feels trustworthy and easy. When they are slow, confusing or missing, people tap twice, wonder whether something happened, and lose confidence.
In practice
A banking app team notices that many users tap the transfer button twice, creating support requests about duplicate payments. Analysis shows that the button gives no visible feedback during the one to two seconds the server needs to confirm the transfer.
The designers redesign the microinteraction. On tap, the button changes to a pressed state within 50 milliseconds, becomes disabled and shows a small spinner; after confirmation, it morphs into a check mark over about 200 milliseconds, and a screen reader announcement states that the transfer was sent. Duplicate taps disappear in testing, and the team adds the new loading button state to the design system so every form in the app behaves the same way.