What is Error State?

Error States explain what went wrong and how to fix it. Good error states are specific, actionable, and empathetic. Include: what happened, why it happened (if known), how to fix it, and retry/recovery action. Use plain language, not technical jargon. Show inline (form errors), banner (page errors), or dedicated page (404, 500).

When Should You Use This?

Use error states for all failures: form validation, API errors, 404/500 pages, network failures, permission denied. Be specific: "Email already registered" not "Error 409". Provide action: "Try again" button, "Contact support" link, or alternate path. Use red color sparingly—only for actual errors. Log errors for debugging.

Common Mistakes to Avoid

• •Generic messages—"Error occurred" is useless; say what failed and why
• •Technical jargon—"500 Internal Server Error" → "Something went wrong on our end. We're fixing it."
• •No recovery—always provide next step (Retry, Go back, Contact support)
• •Blaming user—"You entered invalid email" → "Email format looks off. Try name@example.com"
• •No logging—errors you don't know about can't be fixed; log all errors

Real-World Examples

• •Stripe—payment errors explain exactly what failed ("Card declined - insufficient funds")
• •GitHub—404 page with search, popular repos, and report broken link
• •Linear—API errors show user-friendly message + technical details in expandable section
• •Vercel—deployment errors with logs, suggestions, and docs links