Interaction Feedback Patterns
Users need to know what's happening. When interfaces respond to actions with appropriate feedback, they feel responsive and trustworthy. When they don't, users feel uncertain, repeat actions unnecessarily, and lose confidence.
Last updated: September 2022
The feedback spectrum
All interactions need feedback. The type and intensity depends on the action:
| Action type | Feedback needed |
|---|---|
| Hover/focus | Immediate visual change (milliseconds) |
| Click/tap | Instant acknowledgment (< 100ms) |
| Simple action | Result visible (< 1 second) |
| Processing | Progress indication (1-10 seconds) |
| Long operation | Detailed progress (> 10 seconds) |
The principle from Apple's Human Interface Guidelines applies broadly: "Always acknowledge user actions, even if it's just a subtle visual change."
Immediate feedback
Hover states
Purpose: Show that an element is interactive before clicking.
Implementation:
- Cursor change (pointer for links/buttons)
- Background or border color change
- Subtle elevation or shadow
- Opacity shift
Accessibility: Don't rely on hover alone—touch users and keyboard users can't hover. Hover enhances; it shouldn't be required.
Active/pressed states
Purpose: Confirm that a click/tap registered.
Implementation:
- Button appears pressed (inset shadow, darker background)
- Scale reduction (98-99% for tactile feel)
- Color change
Timing: Immediate—no perceivable delay.
Focus states
Purpose: Show which element has keyboard focus.
Implementation:
- Clear, visible outline
- High contrast against background
- Consistent across all interactive elements
Accessibility requirement: Focus states must be visible. Don't remove outline without providing an alternative.
Use :focus-visible to show focus outlines only for keyboard navigation, not mouse clicks. This provides accessibility without visual noise for mouse users.
Loading and progress
Determinate progress
When to use: When you can calculate how much is done (file upload, multi-step process).
Patterns:
- Progress bar with percentage
- Step indicators (1 of 4)
- Circular progress with percentage
Best practices:
- Show percentage or step count
- Estimate time remaining if possible
- Never let progress go backward
- Animate smoothly (don't jump)
Indeterminate progress
When to use: When you can't predict completion time.
Patterns:
- Spinner
- Pulsing dot animation
- Skeleton screens
- Animated loading bar
Best practices:
- Use when operation exceeds 1 second
- Don't overanimate (distracting)
- Position near the action or content area
- Include text label if context isn't clear
Skeleton screens
When to use: When loading content that will fill a specific layout.
Implementation:
- Show layout structure with placeholder shapes
- Shapes should match expected content dimensions
- Subtle animation (shimmer, pulse) indicates loading
Advantages:
- Feels faster than spinners (perceived performance)
- Sets expectations for content layout
- Reduces layout shift when content loads
Optimistic updates
When to use: When action will almost certainly succeed.
Implementation:
- Show result immediately (before server confirmation)
- Quietly confirm or handle rare failures
- User experiences instant response
Example: Liking a post shows the heart immediately; server request happens in background.
Caution: Only for actions with high success rates. Frequent rollbacks are worse than waiting.
Success feedback
Visual confirmation
Patterns:
- Checkmark animation
- Color change (green success)
- Item appearing in expected location
- Toast/snackbar message
Best practices:
- Make success visible but not disruptive
- Position near the action taken
- Keep confirmation brief
- Don't require dismissal for simple successes
Celebration (sparingly)
When appropriate:
- Significant accomplishments (completing onboarding, major milestone)
- Actions that warrant emotional response
- Gamified contexts
When inappropriate:
- Mundane actions (saving a form)
- Frequent operations (liking content)
- Professional/serious contexts
Implementation: Confetti, animations, celebratory sounds—use restraint. Over-celebration becomes noise.
Error feedback
Covered in detail in Error States, but key points:
- Errors need immediate, clear feedback
- Position errors near the problem
- Explain what went wrong and how to fix
- Don't lose user's work
- Allow easy recovery
Microinteractions
Microinteractions are small, contained animations that provide feedback and delight.
Effective microinteractions
- Like animations: Heart filling, bouncing
- Toggle switches: Smooth slide with color change
- Form success: Check appearing in field
- Pull to refresh: Custom animation during pull
Principles
Purposeful: Every animation should communicate something.
Quick: Microinteractions should be 200-400ms. Longer feels slow.
Subtle: Enhance, don't distract. Users shouldn't notice animation, just feel responsiveness.
Consistent: Same action should produce same feedback throughout.
- Instant: < 100ms (feels immediate)
- Fast: 100-300ms (good for micro-interactions)
- Normal: 300-500ms (good for larger transitions)
- Slow: > 500ms (only for emphasis or complex changes)
Accessibility considerations
Reduced motion
Respect prefers-reduced-motion:
- Replace animations with instant state changes
- Keep essential feedback (checkmarks) but remove decorative motion
- Never use motion as the only feedback mechanism
Screen reader feedback
- Use
aria-liveregions for dynamic updates - Announce state changes (loading, success, error)
- Don't announce every small change—find the right balance
Color independence
- Don't use color as the only feedback indicator
- Pair color with icons, text, or other visual changes
- Test with color blindness simulators
Common feedback mistakes
No feedback
User does something and nothing visibly happens. They don't know if it worked, click again, and may cause duplicate actions.
Delayed feedback
Feedback comes too late. User has already moved on or repeated the action.
Incorrect feedback
Success message when action failed. Error shown for successful action. Destroys trust.
Overdone feedback
Every action triggers elaborate animation. Exhausting. Feels unserious.
Feedback only for errors
Users get feedback when something goes wrong but not when things go right. Creates anxiety—is silence good or bad?
Skeletons work when you know the content structure and want to reduce perceived wait time. Spinners work for unpredictable content or actions. When in doubt, skeletons feel better for content loading.
Show a spinner after about 1 second. Under 1 second, no indicator needed—it feels instant. Over 1 second, users need to know something is happening.
For success messages, yes (3-5 seconds). For errors requiring action, no—let users dismiss manually. For important info, consider longer duration or manual dismissal.
For operations users initiated, show progress somewhere accessible (toolbar, status area). For automatic background operations, only surface if something needs attention.
No. Instant state changes can provide feedback without animation. Animation enhances perceived smoothness but isn't required. Prioritize clarity over flourish.