Micro-Interactions in UX: Design Patterns, Triggers & Examples That Actually Work (2025)
Great interfaces don't just work — they respond. The difference between a form that feels broken and one that feels intuitive is often a 200ms animation and a color change. Users never consciously think "that button gave me good press feedback" — but they feel more confident, make fewer errors, and come back more often. Micro-interactions are the design layer operating just below conscious awareness, transforming functional UIs into ones that feel genuinely crafted.
This guide covers every pattern you need: the foundational framework from Dan Saffer, all six categories of micro-interactions, exact CSS timing values, production-ready code patterns for CSS and Angular, accessibility requirements, and a 12-point checklist you can use before shipping anything. Whether you're a designer speccing animations in Figma or a developer implementing them in Angular, this is the reference to bookmark.
What Are Micro-Interactions? (Dan Saffer's Framework)
A micro-interaction is a single-purpose interaction moment — one small event, one specific response. Dan Saffer, who literally wrote the book on the topic (Micro-Interactions: Designing with Details, 2013), defines them as "contained product moments that revolve around a single use case." The key word is single. A form submit flow has multiple micro-interactions inside it. Each one handles one thing.
The Four Components
Every micro-interaction has exactly four parts. Understanding all four is what separates designers who add animations from designers who add communication.
1. Trigger — what initiates the interaction. Triggers are either user-initiated (a click, a tap, a focus event, a hover, a key press) or system-initiated (a push notification arriving, a background sync completing, a session expiring). The trigger defines the scope of the interaction. If the trigger is ambiguous, the micro-interaction will feel random.
2. Rules — what happens as a result. This is the logic layer. Rules determine what feedback plays, under what conditions, in what order. Rules are invisible to the user but their absence is immediately felt — a button that behaves differently depending on form state is running on rules; one that always does the same thing regardless of context is not.
3. Feedback — what the user perceives. This is the visible (or audible, or haptic) output: the color change, the animation, the sound, the vibration pattern on mobile. Feedback is the only part of a micro-interaction that users actually experience. Everything else serves the feedback.
4. Loops & Modes — how the interaction behaves over time. Does it loop (a spinner keeps spinning until the request resolves)? Does it change after repeated use (a "Pro tip" tooltip that only shows the first three times a user sees a feature)? Modes handle edge cases: what happens if the user triggers the interaction while it's already in progress?
Walking Through a Toggle: All Four Parts
Take a dark mode toggle. The trigger is a click on the toggle switch. The rules say: if current mode is light, switch to dark; update the CSS custom properties; persist the preference to localStorage; if system preference exists, still defer to the explicit user choice. The feedback is the thumb sliding from left to right over 200ms, the background color of the switch transitioning from grey to indigo, and the page colors shifting. The loops & modes define what happens on subsequent visits — the toggle initializes in the last-saved state, not the default.
Micro-Interactions vs Macro-Animations
All micro-interactions involve animation, but not all animations are micro-interactions. A hero section scrolling into view on page load is an animation — it's decorative, ambient, narrative. A loading spinner is a micro-interaction — it communicates a specific system state. The test: does this animation communicate something functional? If yes, it's a micro-interaction. If it's purely aesthetic, it's animation. This distinction matters because micro-interactions carry accessibility obligations that decorative animations don't.
Why They Matter
Micro-interactions drive three measurable outcomes. First, perceived performance: skeleton screens feel faster than spinners even when actual load time is identical, because they give users something concrete to look at rather than an abstract waiting symbol. Second, error prevention: inline validation that highlights a field error the moment a user moves to the next field catches mistakes before form submission — studies consistently show this increases form completion rates 20–30% over end-of-form error summaries. Third, brand personality: the specific way a like button animates, the exact easing curve on a modal open, the subtle scale on a button press — these accumulate into a felt sense of quality that users associate with your product.
The 6 Categories of Micro-Interactions
1. Form & Input Feedback
Form fields are the highest-stakes territory for micro-interactions. Users are doing real work — entering data they'll have to re-enter if something goes wrong. Every point of friction here is a completion rate hit.
Inline validation should fire on blur (when the user leaves a field), not on keydown. Validating on every keystroke makes the interface feel adversarial — the field turns red before the user has finished typing. On blur, the interaction is: user has committed to what they've entered, now check it. Show the result with a color change on the field border (green for valid, red for invalid) paired with a small icon and a text message below. Never rely on color alone — the text is required for accessibility.
Character counters (Twitter-style) should remain neutral until the user reaches 80% of the limit, shift to amber at 90%, and shift to red at or above 100%. The remaining character count displayed below the field is the feedback; the color shift is a secondary micro-interaction within the same field.
Password strength indicators are a classic example of rules-driven feedback — the same trigger (typing in the password field) produces different feedback depending on what was typed. Use a segmented bar: one segment (red) for weak, two (amber) for moderate, three (green) for strong, with a label text that changes.
Search autocomplete appearance should animate in — not pop instantly. A 150ms ease-out from opacity: 0; transform: translateY(-4px) to opacity: 1; transform: translateY(0) makes the dropdown feel attached to the field rather than appearing from nowhere.
2. Action Confirmation
When a user commits an action, they need to know it worked. The absence of feedback causes re-clicks, double submissions, and anxiety.
Button press states are the simplest and most skipped micro-interaction. A subtle scale(0.97) on :active with a reduced box-shadow creates a physical press sensation that costs five lines of CSS and makes every click feel more real.
Success checkmarks after form submission should replace the submit button content — the button stays where it is, the label fades to a checkmark, then after 2 seconds the form either resets or the user is navigated forward. This prevents the blank-page uncertainty of a page reload.
"Added to cart" fly-to-cart animations track the product image from its position to the cart icon in the header. This is a more complex micro-interaction but it directly answers the user's implicit question: "Did that actually go in there?"
Copy-to-clipboard confirmation should change the button label from "Copy" to "Copied!" with a checkmark for exactly 2 seconds, then reset. No modal, no toast unless the design system requires it. The inline feedback is faster and less disruptive.
3. State Change & Toggles
These micro-interactions communicate that something has changed from one state to another — and the animation itself communicates the direction of the change.
Toggle switches should animate the thumb sliding horizontally, not jumping. The background color should transition simultaneously. The total duration: 200ms, ease-in-out. If the thumb snaps, the interaction doesn't communicate — it just changes.
Like/favorite buttons benefit from a scale pulse: tap → scale up to 1.3 → scale back to 1.0 → icon fills. The fill should animate (if SVG) or transition opacity. Twitter/X's heart animation adds a particle burst which is an advanced version — effective but requires more implementation effort.
Checkbox animations should draw the checkmark rather than making it appear. A CSS stroke-dashoffset animation on an SVG path creates a drawing effect in about 200ms that feels tactile.
Accordion open/close should animate the height, but not with height: auto transitions (which don't work in CSS without JavaScript help). The Angular Animations API handles this well with style({ height: '*' }) — more on that in the Angular section.
4. Loading & Progress
Loading is where poor micro-interaction design costs the most. A user staring at a blank screen has no signal — they don't know if anything is happening.
Skeleton screens outperform spinners in perceived performance because they show the shape of incoming content. Users can predict where elements will appear, which reduces cognitive load during wait. Use skeletons when loading structured content (cards, lists, profile pages). Use spinners only for undetermined-duration operations or when the content shape is genuinely unknown.
Progress bars should fill continuously, not in jumps. If your actual progress is non-linear, fake a smooth animation: start fast (0–70% quickly), slow down at 70–90% to hint at real work, then jump to 100% when complete. Never leave a progress bar stuck at 99%.
Skeleton pulse animation (CSS only, no JavaScript required) uses a moving linear gradient to simulate a shimmer effect — see the CSS section below.
Optimistic UI updates are a micro-interaction pattern where the UI updates before the server confirms the change, then rolls back only if the request fails. A like count incrementing immediately on tap — then silently decrementing if the API call fails — feels dramatically faster than waiting for the round-trip.
5. Navigation Feedback
Navigation micro-interactions orient users. They answer: "Where am I? Where can I go?"
Active tab underlines that slide from the previously active tab to the current one (rather than disappearing and reappearing) communicate spatial relationship. The user sees movement from A to B, which reinforces the mental model of tabs as a spatial construct.
Hover underlines that grow from center outward (using transform: scaleX() with transform-origin: center) are more visually sophisticated than underlines that appear instantly and signal interactivity clearly without a cursor change.
Mobile back-swipe indicators — the translucent previous-page preview that appears when a user begins a right-swipe gesture on iOS — are a system-level micro-interaction that web apps can approximate with gesture detection libraries.
6. System Status
These micro-interactions carry information the user didn't ask for but needs to know.
Notification badges should pop (scale from 0 to 1 with a slight overshoot spring easing) when they appear, not simply render. A badge that pops draws the eye; one that renders is easily missed.
Online/offline indicators should animate in as a banner or subtle status pill and animate out when connectivity is restored. The offline state should be visually distinct from error states — offline is temporary and systemic, not caused by user action.
Auto-save "Saved" confirmations follow a pattern: idle → saving (spinner) → saved (checkmark + "Saved" label) → fade out after 3 seconds → return to idle. This entire loop should be silent unless the save fails, in which case the micro-interaction escalates to an error state.
Error shake animations (horizontal oscillation) communicate rejection without requiring the user to read an error message first. The motion is physically analogous to a human head-shake: "No." Combine with a red border and error text — never the shake alone.
Timing: The Rules That Make or Break Micro-Interactions
Animation timing is where taste becomes craft. The ranges below are starting points, not rules — test everything with real users on real devices.
- Under 100ms: Feels instantaneous. Use for hover color changes, focus ring appearance, cursor state changes. Anything longer than this for a hover state starts to feel laggy.
- 100–200ms: Feels responsive. Use for button press feedback, small icon swaps, badge appearances. This is the range where the interaction feels physically connected to the input.
- 200–400ms: Transition territory. Use for state changes (toggle, checkbox, input validation), modal opens, dropdown appearances. This range communicates deliberate change without feeling slow.
- 400–500ms: Complex feedback. Use for success animations, error shakes, onboarding callout appearances. This range is for moments that deserve attention.
- Over 500ms: Use only for intentional emphasis — first-use onboarding, celebration states (confetti), or interactions where the delay itself carries meaning (a satisfying "charging complete" animation). Every millisecond over 500 requires justification.
Easing Functions
The easing curve is as important as the duration. Use ease-out for elements entering the screen (starting fast, decelerating to rest — mimics how objects arrive in physical space). Use ease-in for elements leaving the screen (accelerating away — mimics how objects depart). Use ease-in-out for state changes where an element transforms in place (toggle, scale, color transition). Use linear only for looping animations (spinners, shimmer effects) where acceleration would look wrong.
The cubic-bezier CSS function lets you define custom curves. Common production-ready values:
- Ease-out snappy:
cubic-bezier(0.0, 0.0, 0.2, 1)(Material Design standard) - Spring overshoot:
cubic-bezier(0.34, 1.56, 0.64, 1)(good for badge pop, like button) - Smooth in-out:
cubic-bezier(0.4, 0, 0.2, 1)(Google's standard ease-in-out)
CSS Patterns for the 10 Most Common Micro-Interactions
These are production-ready patterns. Copy, adapt, test with your design system's tokens.
Button press feedback:
.btn {
transition: transform 150ms ease, box-shadow 150ms ease;
}
.btn:active {
transform: scale(0.97);
box-shadow: 0 1px 2px rgba(0, 0, 0, 0.2);
}
Skeleton loader pulse (shimmer):
.skeleton {
background: linear-gradient(
90deg,
#f0f0f0 25%,
#e0e0e0 50%,
#f0f0f0 75%
);
background-size: 200% 100%;
animation: shimmer 1.5s infinite;
border-radius: 4px;
}
@keyframes shimmer {
0% { background-position: 200% 0; }
100% { background-position: -200% 0; }
}
Input focus ring:
.input:focus-visible {
outline: 2px solid var(--ds-color-primary);
outline-offset: 2px;
transition: outline-offset 0.1s ease;
}
.input:focus-visible {
outline-offset: 4px;
}
Checkbox checkmark draw:
.checkbox-icon {
stroke-dasharray: 20;
stroke-dashoffset: 20;
transition: stroke-dashoffset 200ms ease-out;
}
.checkbox:checked + .checkbox-icon {
stroke-dashoffset: 0;
}
Toggle slide:
.toggle-thumb {
transform: translateX(0);
transition: transform 200ms ease-in-out, background-color 200ms ease-in-out;
}
.toggle-input:checked ~ .toggle-thumb {
transform: translateX(24px);
}
.toggle-track {
background-color: #ccc;
transition: background-color 200ms ease-in-out;
}
.toggle-input:checked ~ .toggle-track {
background-color: var(--ds-color-primary);
}
Error shake animation:
@keyframes shake {
0%, 100% { transform: translateX(0); }
20% { transform: translateX(-8px); }
40% { transform: translateX(8px); }
60% { transform: translateX(-6px); }
80% { transform: translateX(6px); }
}
.input--error {
animation: shake 400ms ease-in-out;
border-color: var(--ds-color-error);
}
Success scale confirmation:
@keyframes success-pop {
0% { transform: scale(0.8); opacity: 0; }
60% { transform: scale(1.1); }
100% { transform: scale(1); opacity: 1; }
}
.success-icon {
animation: success-pop 300ms cubic-bezier(0.34, 1.56, 0.64, 1) forwards;
}
Tab underline slide:
.tabs {
position: relative;
}
.tab-indicator {
position: absolute;
bottom: 0;
height: 2px;
background: var(--ds-color-primary);
transition: left 200ms ease-in-out, width 200ms ease-in-out;
}
Notification badge pop:
@keyframes badge-pop {
0% { transform: scale(0); }
70% { transform: scale(1.2); }
100% { transform: scale(1); }
}
.badge {
animation: badge-pop 250ms cubic-bezier(0.34, 1.56, 0.64, 1) forwards;
}
Hover underline grow:
.nav-link {
position: relative;
text-decoration: none;
}
.nav-link::after {
content: '';
position: absolute;
bottom: -2px;
left: 0;
right: 0;
height: 2px;
background: currentColor;
transform: scaleX(0);
transform-origin: center;
transition: transform 200ms ease-out;
}
.nav-link:hover::after {
transform: scaleX(1);
}
Angular Implementation: Micro-Interactions with Angular Animations
Angular gives you two tools for micro-interactions: the Angular Animations API (for complex state machines) and pure CSS with class bindings (for simple hover/active states). Knowing when to use which is the key decision.
Angular Animations API: Button Loading State Machine
Use the Animations API when you have three or more states, when you need to sequence animations, or when transition direction matters (entering vs leaving).
import {
trigger,
state,
style,
transition,
animate,
keyframes
} from '@angular/animations';
import { Component, signal } from '@angular/core';
@Component({
selector: 'app-submit-button',
template: `
<button
[@buttonState]="buttonState()"
(click)="handleSubmit()"
[disabled]="buttonState() !== 'default'"
class="btn"
>
<span *ngIf="buttonState() === 'default'">Submit</span>
<span *ngIf="buttonState() === 'loading'">
<span class="spinner" aria-hidden="true"></span>
<span class="sr-only">Submitting…</span>
</span>
<span *ngIf="buttonState() === 'success'">Done ✓</span>
</button>
`,
animations: [
trigger('buttonState', [
state('default', style({
backgroundColor: 'var(--ds-color-primary)',
transform: 'scale(1)'
})),
state('loading', style({
backgroundColor: 'var(--ds-color-primary-muted)',
transform: 'scale(1)'
})),
state('success', style({
backgroundColor: 'var(--ds-color-success)',
transform: 'scale(1)'
})),
transition('default => loading', animate('150ms ease-out')),
transition('loading => success', animate('300ms cubic-bezier(0.34, 1.56, 0.64, 1)')),
transition('success => default', animate('200ms ease-in'))
])
]
})
export class SubmitButtonComponent {
buttonState = signal<'default' | 'loading' | 'success'>('default');
async handleSubmit() {
this.buttonState.set('loading');
try {
await this.submitForm();
this.buttonState.set('success');
setTimeout(() => this.buttonState.set('default'), 2000);
} catch {
this.buttonState.set('default');
// trigger error micro-interaction separately
}
}
}
Pure CSS + Angular Class Binding: Simpler Cases
For two-state interactions (loading/not-loading, valid/invalid), class bindings with CSS transitions are faster to implement, easier to maintain, and perform better:
@Component({
selector: 'app-input-field',
template: `
<div
class="field"
[class.field--error]="hasError()"
[class.field--valid]="isValid()"
[class.field--loading]="isLoading()"
>
<input
class="input"
(blur)="onBlur()"
[(ngModel)]="value"
/>
<span class="field__message" aria-live="polite">
{{ errorMessage() }}
</span>
</div>
`
})
export class InputFieldComponent {
value = '';
hasError = signal(false);
isValid = signal(false);
isLoading = signal(false);
errorMessage = signal('');
onBlur() {
// Rules layer: determine feedback
const result = this.validate(this.value);
this.hasError.set(!result.valid);
this.isValid.set(result.valid);
this.errorMessage.set(result.message ?? '');
}
}
The CSS handles all the animation — the Angular component only manages state. This separation keeps components lean and animations declarative.
When to use Angular Animations API vs pure CSS:
- API: 3+ states, sequenced animations, enter/leave transitions (
*ngIf/@forblocks), accordion height animations - CSS: hover, focus, active states; two-state class toggles; anything that doesn't require JavaScript-timed sequencing
For more on Angular motion patterns, see the deep-dive in Motion Design as an Essential UX Layer.
Accessibility Rules for Micro-Interactions
Animation is a liability as well as an asset. Users with vestibular disorders can experience nausea, dizziness, and disorientation from motion — and motion preferences are a user right, not a suggestion.
Respect prefers-reduced-motion
The single most important accessibility rule for micro-interactions:
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
scroll-behavior: auto !important;
}
}
This global reset is the safe baseline. For more nuanced control — where you want to simplify rather than eliminate animations for reduced-motion users — use the media query per component and provide an alternative:
.skeleton {
animation: shimmer 1.5s infinite;
}
@media (prefers-reduced-motion: reduce) {
.skeleton {
animation: none;
background: #e0e0e0; /* static, no shimmer */
}
}
Never Convey State Through Animation Alone
If a field turns red and shakes to indicate an error, that's good — but the shake must not be the only indicator. A user who has prefers-reduced-motion enabled, or who simply didn't notice the animation, must still receive the error communication through color (but color alone is also insufficient for colorblind users) and through text. The rule: every state change communicated by a micro-interaction must also be communicated through at least one non-animation channel — text label, icon, or ARIA announcement.
Focus Indicators Must Not Be Animated Away
Focus rings are non-negotiable for keyboard navigation users. Some designs add a fade-in to focus indicators — this is acceptable if the indicator still appears within 100ms. What's not acceptable is animating the focus indicator out while focus is still active (e.g., a focus ring that fades to transparent to "look cleaner").
Screen Reader Announcements for State Changes
When a micro-interaction communicates a state change that matters (auto-save completing, form validation failing, online/offline status changing), add an aria-live region to announce it to screen readers:
<span class="sr-only" aria-live="polite" aria-atomic="true">
{{ statusMessage }}
</span>
Use polite for non-critical updates (auto-save status, character counter). Use assertive only for errors that block the user's current task. For full guidance on inclusive design and legal requirements, see European Accessibility Act 2025: A UX Designer's Guide.
Micro-Interaction Anti-Patterns to Avoid
Micro-interactions earn their place only when they serve communication. These five patterns do the opposite.
1. Animation on every hover. If every link, every card, every button has a different hover animation, the interface is visually noisy. Hover micro-interactions should signal interactivity — not showcase motion skills. Keep hover states consistent within component types: all cards have the same hover treatment, all text links have the same underline behavior. The moment every element has its own animation language, none of them communicate anything.
2. Animating layout properties (width, height, top, left). Animating these properties triggers browser layout recalculation on every frame — expensive, janky, battery-draining. Always use transform and opacity instead. Instead of animating height: 0 to height: 200px, animate transform: scaleY(0) to transform: scaleY(1) with transform-origin: top. The Angular Animations API's animate('*') syntax handles height animations correctly — use it rather than CSS height transitions.
3. Infinite spinning on instant operations. Adding a loading spinner to a button before a synchronous operation (one that resolves in under 50ms) trains users to wait when they don't need to. If the operation is truly instant, skip the loading state. If it's fast but asynchronous (50–200ms), an optimistic UI update is better than a spinner for operations with high success rates.
4. No feedback on form submit. A form that goes silent after the user presses Submit is one of the most common UX failure modes. The user doesn't know if the click registered, the request is in progress, the request succeeded, or the request failed. The button press itself is a trigger — the feedback is mandatory. Minimum: the button enters a loading state immediately on click, disabling re-submission.
5. Animating while also changing content simultaneously. If a card both fades out and changes its text content in the same moment, the user can't track either change. Sequence content changes and animation: fade out → swap content → fade in. Or keep the container stable and only animate the content within it. The rule: never animate a container and change what's inside it at the same time.
Figma: Prototyping Micro-Interactions for Handoff
A micro-interaction that can't be communicated to engineers during handoff doesn't exist in the final product. Figma's prototyping tools cover most cases.
Smart Animate is the primary tool. When you prototype a transition between two component variants in Figma, Smart Animate matches layers with the same names and animates between their properties. This means your toggle variants (off state / on state) produce a real animated prototype — and the timing and easing you set in the prototype are the values your developer implements.
Interactive Components (component properties + variants with prototype connections inside the component) let you prototype micro-interactions inside the component itself, not just in the top-level prototype flow. A button with a loading state can be prototyped once in the component — every instance inherits the interaction.
Prototype Triggers should match real triggers exactly. Use "On Click" not "On Tap" for desktop interactions. Use "After Delay" for auto-dismissing notifications. Use "While Hovering" for hover states. Mismatched triggers produce prototypes that mislead engineers about intended behavior.
Dev Mode Specs — when an engineer opens a component in Dev Mode, they see CSS properties automatically. But easing and duration are not always clear. Add annotation notes to your Figma frames specifying: duration: 200ms, easing: ease-in-out, property: transform for every meaningful micro-interaction. This removes ambiguity at handoff. For the full Angular-to-Figma handoff workflow, see Figma Dev Mode & Angular: The Complete Design Handoff Guide.
The Micro-Interaction Design Checklist
Use this before shipping any interactive component:
- Every interaction has a clearly defined trigger — user-initiated or system-initiated, not both.
- The feedback matches the effort level of the action — micro for micro, substantial for substantial.
- Animation duration falls between 100ms and 500ms for standard interactions.
- Easing is appropriate: ease-out for entrances, ease-in for exits, ease-in-out for state transitions.
prefers-reduced-motionis handled — either via the global reset or per-component override.- State is never communicated through animation alone — text, icon, or ARIA backs it up.
- Loading states never block the UI — the user can still interact with unaffected parts of the screen.
- Success states are visually clear and auto-dismiss within 2–3 seconds.
- Error states are non-punishing — they describe the problem and what to do, without red-screen drama.
- Hover states are consistent within component types — not unique per element.
- Mobile touch states are tested —
:activestates work on touch, hover-only interactions have touch fallbacks. - Tested on a slow 3G network simulation — skeleton loaders still look appropriate; spinners don't appear for 3 seconds before loading content.
Small Moments, Big Impact
The cumulative effect of well-designed micro-interactions is a product that feels crafted — users can't name it but they feel it. They describe it as "fast," "smooth," "polished," or just "I like using it." The interactions themselves are invisible; only their absence is noticed.
The highest-ROI place to start is always the highest-friction moment: usually a form submit or a loading state. Pick the one form in your product that users submit most often. Check whether the button enters a loading state immediately. Check whether inline validation fires on blur. Check whether success is visually confirmed before navigation. Add one micro-interaction this week — the button press scale, the inline validation color, the success checkmark — and watch how it changes the way the form feels to use.
Then work backwards through the six categories. Small moments compound. Over a few sprints, they add up to an interface that doesn't just work — one that responds.
Related reading: Motion Design as an Essential UX Layer · European Accessibility Act 2025: A UX Designer's Guide · Figma Dev Mode & Angular: The Complete Design Handoff Guide