Feedback patterns for microinteractions skill

Feedback Patterns for Microinteractions

Feedback is how a microinteraction communicates its rules to the user. It answers the most fundamental question in any interaction: "What just happened?" Without feedback, users operate in the dark -- unsure if their action registered, if the system is working, or if the result was what they intended. Feedback bridges the Gulf of Evaluation by making the invisible visible.

The Feedback Hierarchy

Not all feedback is equal. The type, intensity, and duration of feedback should match the significance of the event.

Event Significance	Feedback Level	Duration	Example
Micro (hover, focus)	Subtle visual change	Instant, continuous	Background lightens on hover
Minor (tap, toggle)	Clear visual change	100-300ms	Toggle slides, color shifts
Medium (save, send)	Visual change + state label	1-3 seconds	"Saved" text appears briefly
Major (purchase, delete)	Multi-signal confirmation	3-5 seconds, user-dismissable	Confirmation banner with undo option
Critical (error, failure)	Prominent, persistent	Until acknowledged	Red banner with error message and action

The Minimum Feedback Rule

Use the least amount of feedback that still communicates the message. A hover state does not need a sound effect. A successful save does not need a modal dialog. A button press does not need a full-screen animation. Escalate feedback only when the event demands it.

---

Visual Feedback

Visual feedback is the primary feedback channel for nearly every microinteraction. It is silent, non-intrusive, and universally accessible (when designed with sufficient contrast).

Color Changes

Pattern	When to Use	Implementation	Example
State color shift	Show current state	Background or border color changes	Toggle track: gray (off) to green (on)
Validation color	Indicate input validity	Border or icon color changes	Green border = valid, red border = invalid
Progress color	Show completion level	Fill color changes as progress increases	Upload bar shifts from blue to green at 100%
Attention color	Draw focus to a change	Brief highlight animation	Row flashes yellow after being updated
Semantic color	Communicate meaning	Consistent color system	Red = error, green = success, yellow = warning, blue = info

Animations

Animation Type	Duration	Easing	When to Use	Example
Button press	50-100ms	ease-out	Every button interaction	Scale down to 0.97, then back
Toggle slide	150-250ms	ease-in-out	Binary state change	Thumb slides from left to right
Expand/collapse	200-300ms	ease-in-out	Revealing or hiding content	Accordion section opens smoothly
Fade in/out	150-300ms	ease-in (in), ease-out (out)	Elements appearing/disappearing	Toast notification fades in
Slide in/out	200-400ms	ease-out (in), ease-in (out)	Panels, drawers, sheets	Side panel slides from right edge
Skeleton to content	200-400ms	ease-in-out	Content loading	Gray placeholders crossfade to real content
Checkmark draw	300-500ms	ease-out	Success confirmation	SVG checkmark animates stroke from left to right
Shake	300-500ms	ease-in-out (oscillate)	Invalid input	Field shakes horizontally 2-3 times
Bounce	200-400ms	spring	Attention, arrival	New item bounces into list

Animation Principles for Microinteractions

1. Purpose over decoration. Every animation should communicate something: state change, direction, connection, or confirmation. If you cannot articulate what the animation communicates, remove it.

2. Interruptible. If the user acts before an animation completes, the animation should yield to the new action. Never make users wait for an animation to finish.

3. Consistent timing. Use a small set of durations (100ms, 200ms, 300ms, 500ms) and apply them consistently by category. Do not use random durations.

4. Physics-based easing. Use ease-out for elements entering (decelerating arrival), ease-in for elements leaving (accelerating departure), and ease-in-out for elements that stay but change state.

Progress Indicators

Indicator Type	When to Use	Design Details
Determinate progress bar	Duration is known or estimable	Shows percentage; bar fills left to right; show time remaining if > 10s
Indeterminate spinner	Duration is unknown, expected < 10s	Rotating circle or dots; use brand-consistent style
Skeleton screen	Content layout is known, data loading	Gray rectangles matching final layout shape and size
Percentage text	Long operations where users want precision	"47% complete" text; pair with progress bar
Step indicator	Multi-step process	"Step 2 of 4" with visual step markers
Inline spinner	Loading within a specific component	Small spinner inside the button or field that triggered loading

Progress Indicator Selection Guide

Load Time	Best Indicator	Why
< 0.3s	None (instant)	Any indicator would flash and distract
0.3-1s	Subtle inline spinner	Acknowledges loading without overdoing it
1-5s	Skeleton screen or spinner	Shows the system is working
5-30s	Determinate progress bar	Users need to see progress
30s+	Progress bar + percentage + estimated time	Users need reassurance and ability to leave

---

Audio Feedback

Audio feedback provides confirmation through sound. It is powerful when visual attention is elsewhere, but it is easily annoying and must be used sparingly.

When Audio Feedback Is Appropriate

Appropriate	Inappropriate
Confirmation of important action (payment, send)	Every button click
Error that needs immediate attention	Form validation errors
Background task completion (download, print)	Hover or focus changes
Accessibility (screen reader announcements)	Decorative or branding sounds
Physical product interaction (keyboard typing)	Any action that occurs frequently (> 10x/min)

Audio Feedback Design Rules

1. Short. Sounds should be 50-200ms for confirmations, up to 1 second for completions. Never longer.

2. Quiet. Default volume should be unobtrusive. Users should be able to disable all sounds.

3. Distinct. Success and error sounds must be obviously different -- do not rely on subtle pitch changes.

4. Non-verbal. Avoid spoken words in feedback sounds (they do not scale across languages and are slow). Pure tones or abstract sounds work best.

5. Consistent. Use the same sound for the same type of event across the entire product. Success always sounds the same.

Audio Feedback Patterns

Event	Sound Character	Duration	Example Reference
Success	Rising pitch, major chord	100-300ms	iOS payment success chime
Error	Low buzz or discordant tone	100-200ms	macOS alert sound
Notification	Gentle chime, mid-range	200-500ms	Slack notification ding
Completion	Satisfying click or chime	100-200ms	Camera shutter sound
Typing	Soft click per keystroke	20-50ms	iPhone keyboard clicks
Delete/Trash	Crumple or whoosh	200-400ms	macOS trash sound

---

Haptic Feedback

Haptic feedback uses vibration or force feedback to communicate through touch. It is available on mobile devices and some game controllers, laptops, and wearables.

Haptic Feedback Patterns

Pattern	iOS API	Android API	When to Use
Light tap	.light impact	HapticFeedbackConstants.CLOCK_TICK	Toggle, checkbox, minor selection
Medium tap	.medium impact	HapticFeedbackConstants.CONTEXT_CLICK	Button press, drag snap
Heavy tap	.heavy impact	HapticFeedbackConstants.LONG_PRESS	Confirmation of significant action
Success	.success notification	Custom pattern: short-pause-long	Action completed successfully
Warning	.warning notification	Custom pattern: two short bursts	Approaching limit, caution needed
Error	.error notification	Custom pattern: three rapid bursts	Action failed, attention needed
Selection tick	.selection changed	HapticFeedbackConstants.KEYBOARD_TAP	Scrolling through picker values

Haptic Design Rules

1. Pair with visual. Haptic feedback should always accompany visual feedback, never replace it. Some devices have haptics disabled, and users with motor impairments may not feel vibrations.

2. Match intensity to significance. Light tap for toggles. Medium for confirmations. Heavy for warnings. Never heavy for routine actions.

3. Use sparingly. Constant vibration is annoying and drains battery. Reserve haptics for moments where tactile confirmation adds genuine value.

4. Respect system settings. Always check if the user has disabled haptic feedback at the system level. Never override this preference.

---

Feedback Timing

When feedback occurs is as important as what feedback occurs. The human perception system has specific thresholds that determine whether feedback feels instant, delayed, or broken.

Perception Thresholds

Delay	User Perception	Required Feedback
0-100ms	Instantaneous -- feels like direct manipulation	Visual state change (color, position)
100-300ms	Slight lag but still responsive	Transition animation, inline spinner
300ms-1s	Noticeable delay	Loading indicator, cursor change
1-5s	Waiting	Spinner, skeleton screen, "Loading..."
5-10s	Attention wanders	Progress bar with estimate
10-30s	Impatient	Progress bar + percentage + "X seconds remaining"
30s+	Will leave or switch tasks	Progress bar + allow backgrounding + notification on completion

Optimistic UI Pattern

Show the result immediately and correct later if the action fails. This makes the interface feel instant even when the server takes time.

Step	What Happens	Example
1. User triggers	Show success state immediately	Heart fills red instantly on like
2. Send request	API call fires in background	POST /like runs asynchronously
3a. Server confirms	Nothing changes (already showing success)	Response 200: no visual change
3b. Server fails	Revert to previous state with error	Heart unfills; toast: "Could not save like"

When to use optimistic UI:

• Action is very likely to succeed (> 99%)
• Reverting is possible and not confusing
• The action is low-stakes (not a payment or deletion)

When NOT to use optimistic UI:

• Action has a significant failure rate
• Action is irreversible
• Reverting would be confusing (e.g., message appears then disappears)

---

Progressive Disclosure in Feedback

Not all feedback needs to appear at once. Progressive disclosure reveals information in layers, starting with the most important.

Feedback Layering

Layer	What It Shows	When	Example
Immediate	"Your action was received"	0-100ms	Button changes state
Status	"Here's what's happening"	100ms-3s	Spinner, progress bar
Result	"Here's the outcome"	On completion	Success message, error details
Detail	"Here's the specifics"	On demand (hover, click)	Tooltip with timestamp, expandable error log

Progressive Error Disclosure

Level	What to Show	Example
Summary	One-line human-readable error	"Upload failed"
Explanation	Why it happened	"The file is too large (12MB). Maximum size is 10MB."
Resolution	How to fix it	"Try compressing the image or choosing a smaller file."
Technical detail	For developers or support	Expandable: "Error 413: Request Entity Too Large. Request ID: abc123"

---

Preventing Feedback Overload

Too much feedback is as bad as too little. When every action triggers a toast notification, animation, and sound, users become desensitized and miss the feedback that actually matters.

Signs of Feedback Overload

Symptom	Cause	Fix
Users ignore toast notifications	Too many toasts for minor events	Reserve toasts for actions user may want to undo
Interface feels "jittery"	Too many animations on trivial events	Remove animation from hover/focus; keep for state changes
Users disable notifications	Every event sends a push notification	Tier notifications; only push for high-priority events
Sound becomes annoying	Every click has an audio cue	Remove audio from routine actions; keep for confirmations
Screen reader users overwhelmed	Too many aria-live announcements	Announce only meaningful state changes

Feedback Reduction Strategies

1. Consolidate. Instead of four separate toast messages for four file uploads, show one: "4 files uploaded successfully."

2. Delay and batch. Accumulate minor events and present them as a summary: "While you were away: 3 likes, 2 comments, 1 share."

3. Tier by priority. Define three tiers of feedback intensity and assign every event type to a tier:

Tier	Intensity	Feedback Type	Events
1 (High)	Multi-signal, persistent	Banner + sound + haptic	Errors, destructive confirmations, payment success
2 (Medium)	Single signal, temporary	Toast or inline text	Save success, status change, minor warning
3 (Low)	Minimal, passive	Visual state change only	Hover, focus, toggle, minor selection

4. Respect context. Reduce feedback when:

• User is performing rapid sequential actions (bulk editing)
• System is in background/minimized
• User has indicated preference for fewer notifications

---

Feedback Accessibility

Feedback must work for all users, including those who cannot see animations, hear sounds, or feel vibrations.

Accessibility Requirements

User Group	Feedback Adaptation
Screen reader users	Use aria-live regions (polite for status, assertive for errors) to announce state changes
Low vision users	Ensure color changes have sufficient contrast (3:1 minimum for state changes); do not rely on color alone
Motion-sensitive users	Respect prefers-reduced-motion; replace animations with instant state changes
Deaf/hard of hearing users	Never rely on audio as sole feedback channel; always pair with visual
Keyboard-only users	Focus indicators must be visible on all interactive elements; state changes near focus

Accessibility Feedback Checklist

• Can every state change be perceived without color alone (shape, text, or icon accompanies color)?
• Are error messages announced to screen readers via aria-live="assertive"?
• Are success messages announced via aria-live="polite"?
• Do animations respect prefers-reduced-motion media query?
• Is all audio feedback accompanied by a visual equivalent?
• Can keyboard users perceive which element has focus?
• Do loading states have an accessible label ("Loading...", role="status")?
• Are progress bars accessible (role="progressbar", aria-valuenow, aria-valuemin, aria-valuemax)?

---

Feedback Design Checklist

• Does every interactive element provide immediate visual feedback on activation?
• Is feedback proportional to event significance (small action = small feedback)?
• For operations > 300ms, is there a loading indicator?
• For operations > 10 seconds, is there a progress bar?
• Do error messages explain what happened and how to fix it?
• Is success feedback brief and non-blocking (does not require dismissal)?
• Are animations under 500ms and interruptible?
• Is audio feedback optional and disabled by default (except essential alerts)?
• Does haptic feedback match system settings?
• Are all feedback channels accessible (visual + ARIA + reduced-motion support)?