UX Feedback Patterns

Purpose

Ensure users never wonder "What's happening?" or "Did that work?" through clear, consistent feedback patterns.

---

Core Principle

Users must receive feedback for EVERY interaction.

Every user action needs feedback in one or more states:

1. Loading/Processing
2. Success
3. Error
4. Empty

---

Loading States

When to Show Loading

Timing thresholds (adjust to your context):

• < 100ms: Perceived as instant, no feedback needed
• 100-300ms: Optional subtle indicator
• 300ms-1s: Show spinner or skeleton
• 1-5s: Spinner + explanatory text
• 5-10s: Progress bar with percentage
• 10s+: Progress bar + explanation + cancel option

Loading Patterns

Button Loading:

• Disable button to prevent double-submission
• Show spinner inside button or change text
• Keep button in place (don't shift layout)

Content Loading:

• Prefer skeleton screens over spinners
• Match skeleton structure to actual content
• Maintain layout space (prevent content jump)

Progress Indicators:

• Use for file uploads, large operations
• Show percentage when determinable
• Provide cancel option for long operations

---

Success States

When to Show Success

Always show for:

• Form submissions
• Data mutations (create, update, delete)
• File uploads
• Account changes

Skip for:

• Very quick actions (near-instant completion)
• Continuous interactions (likes, toggles) - use optimistic updates
• Actions where feedback is inherent in result

Success Patterns

Toast Notifications:

• Auto-dismiss after 3-5 seconds
• Position: top-right or top-center (consistent)
• Specific message, not generic "Success"

Inline Messages:

• For form submissions: show below form
• Less intrusive than toasts
• Can stay visible longer

Visual Confirmation:

• Button state change (e.g., "Save" → "Saved ✓")
• Brief color change (green tint)
• Return to normal after 2-3 seconds

---

Error States

Error Message Principles

Be Specific:

• ❌ "Error occurred"
• ✅ "Email already exists. Try logging in instead."

Be Helpful:

• Explain what happened
• Suggest what to do next
• Provide recovery action when possible

Be Human:

• Natural language, avoid technical jargon
• Don't blame user
• Empathetic tone for serious errors

Severity Levels:

• Critical: System failure, data loss - modal, manual dismiss
• High: Form validation, API errors - prominent, actionable
• Medium: Warnings, non-blocking - dismissible notices
• Low: Helper text, suggestions - subtle, informative

Error Patterns

Form Field Errors:

• Show inline, next to/below field
• Trigger on blur (not every keystroke)
• Include error icon for visibility
• Keep visible until corrected

Global Errors:

• Prominent alert at top or modal
• Include error icon and title
• Explain what failed and why
• Provide action: Retry, Contact support, Learn more
• Manual dismiss (don't auto-hide critical errors)

Error Recovery:

• Always provide a path forward
• "Try Again" button for transient errors
• Link to help/support for persistent issues
• Save user's work when possible

---

Empty States

Never Show Blank Screens

Empty state must include:

1. Icon/Illustration: Visual context
2. Title: "No [items] yet"
3. Description: Brief explanation
4. Action (when possible): CTA to create first item

Empty State Types

First-Time Empty:

• Welcoming, encouraging tone
• Clear next step to get started

Search No Results:

• Acknowledge the query
• Suggest alternatives (check spelling, try different terms)
• Provide way to clear/modify search

Filtered Empty:

• Explain filters are active
• Show way to clear filters

---

Interaction Patterns

Form Validation

Validation Timing:

• On blur: Validate individual field
• On submit: Validate entire form
• On change: Only for real-time feedback (password strength, username availability)

Success Indicators:

• Optional: show checkmark for valid fields
• Only after field touched
• Subtle, not distracting

Button States

Required states:

• Default: Normal appearance
• Hover: Visual feedback
• Active/Pressed: Depressed appearance
• Loading: Spinner + disabled
• Disabled: Grayed out + tooltip/explanation
• Success: Brief confirmation (2-3s)

Optimistic Updates

Pattern: Update UI immediately, rollback on error

Best for:

• Fast, reliable operations (likes, favorites)
• Low-stakes actions
• When instant feedback improves perceived performance

How it works:

1. Update UI immediately (assume success)
2. Send API request
3. If success: nothing (already updated)
4. If error: rollback + show error

When NOT to use:

• Destructive actions (delete)
• Complex validations
• Critical operations (payments)

Destructive Actions

Always confirm before:

• Deleting items
• Permanent changes
• Bulk actions

Confirmation pattern:

• Modal dialog with clear title
• Explain consequences: "This cannot be undone"
• Primary action labeled clearly ("Delete", not "Yes")
• Use danger color (red) for destructive button
• Provide "Cancel" as escape hatch

---

Best Practices

Timing

• Feedback should feel immediate (instant perceived response)
• Success messages: auto-dismiss after 3-5 seconds
• Error messages: manual dismiss or longer timeout
• Loading threshold: Show indicators after ~300ms

Tone

• Be specific, not vague
• Be helpful, suggest next steps
• Be human, avoid technical jargon
• Don't blame user

Accessibility

• Use ARIA live regions for dynamic messages
• Associate errors with form fields
• Provide text alternatives for visual indicators
• Don't rely on color alone

Consistency

• Same pattern for same action across app
• Predictable feedback locations
• Consistent timing and animations
• Unified messaging tone

---

Common Mistakes

1. Silent failures - Action fails with no feedback
2. Vague errors - "Error" tells nothing useful
3. No loading state - User clicks repeatedly
4. Blank screens - Empty state without explanation
5. Disabled without reason - No tooltip explaining why
6. Flickering loaders - Show only for operations with noticeable delay
7. Success overload - Toast for every tiny action
8. Technical error codes - Show user-friendly messages
9. No recovery path - Error with no next step
10. Blocking entire UI - Use local loading when possible

---

Validation Checklist

For every interactive feature:

• Loading state for async operations with noticeable delay
• Success feedback (toast, inline, or visual confirmation)
• Error messages specific and actionable
• Empty states have helpful messaging + action
• Optimistic updates rollback on failure
• Destructive actions require confirmation
• All feedback is accessible (ARIA, alt text)
• States are visually distinct and clear
• No silent failures
• Consistent patterns across application

---

Key Takeaway

Never leave users guessing. Clear, timely feedback is the difference between a frustrating experience and a delightful one.

Timing guidelines are based on UX research but should be adjusted to your context. When in doubt, over-communicate rather than under-communicate.