Something broke. Tell me what. Tell me why. Tell me how to fix it.
Error messages must communicate problems clearly. Using plain language. That identifies specific issues. Explains causes. In user-understandable terms. And provides actionable recovery steps.
Enabling efficient problem resolution. Rather than generic failure notifications. Creating confusion. Blame. Or dead-ends. Forcing users to guess solutions. Or abandon tasks entirely.
Nielsen's usability heuristic #9 (1994) established the requirements. "Help users recognize, diagnose, and recover from errors."
Error messages should be expressed in plain language. No codes. Precisely indicate the problem. Constructively suggest solutions.
Yet research shows most error messages? Violate these principles.
Presenting technical jargon. Vague problem descriptions. Missing recovery guidance.
Fundamentally failing to serve users. During critical failure moments. When clear communication proves most essential.
Nielsen's foundational heuristic evaluation research (1990, 1994) identified poor error messages as among the most severe and frequent usability problems. His ninth usability heuristic "Help users recognize, diagnose, and recover from errors" established three critical requirements: problem recognition (error messages expressed in plain language without codes indicating precisely what went wrong), diagnosis (understandable explanation of why error occurred), and recovery (constructive suggestion of solution steps). Nielsen's extensive evaluations demonstrated that error messages failing any component leave users stranded—unable to understand problems, determine causes, or identify resolution approaches creating frustration, abandonment, and negative system perceptions.
Norman's The Design of Everyday Things (1988) reframed errors as design failures rather than user failures arguing that good design prevents errors or makes recovery trivial when they occur. His research distinguished between slips (correct intentions but incorrect execution) and mistakes (incorrect intentions based on faulty mental models), demonstrating that error communication must address root causes rather than merely identifying symptoms. Norman's work showed that blaming users for errors ("invalid input," "illegal operation") proves counterproductive—effective error messages acknowledge that systems create error conditions through inadequate constraints, unclear affordances, or insufficient feedback, with error communication serving as final opportunity to guide users toward success.
Reason's Human Error (1990) provided comprehensive taxonomy of error types distinguishing skill-based errors (slips and lapses during automatic processing), rule-based errors (applying wrong rules or misinterpreting situations), and knowledge-based errors (working with incomplete or incorrect understanding). His research demonstrated that error message effectiveness depends on addressing appropriate error type—skill-based errors (typographical mistakes, wrong button clicks) require simple correction guidance, while knowledge-based errors (misunderstanding system requirements, incorrect goal formation) demand explanatory education helping users build accurate mental models. Generic error messages fail because they don't differentiate between error types providing inappropriate communication for actual failure causes.
Shneiderman's Eight Golden Rules (1987) positioned error handling as fifth rule: "Offer simple error handling." His research demonstrated that systems should be designed to prevent errors when possible, but when errors occur, systems must detect them quickly, offer specific and constructive guidance for recovery, and leave users in states from which they can easily continue work. Shneiderman's studies showed that effective error messages reduce support burden by 30-40% when users can self-serve problem resolution through clear communication versus requiring assistance for vague error notifications.
Lewis and Norman's research (1986) on "Designing for error" established that error communication serves multiple functions beyond immediate problem resolution: education (helping users understand system constraints and requirements), prevention (guiding users to avoid similar errors in future), and trust maintenance (demonstrating system transparency and supportiveness during failures). Their work demonstrated that apologetic, helpful error tone significantly improves user perception compared to cold technical notifications or blame-oriented messages—users experiencing supportive error communication maintain higher confidence and system trust despite failures.
For Users: Clear error communication transforms failures from frustrating dead-ends into recoverable situations through actionable guidance. When error messages specifically identify problems (which field invalid, what requirement unmet), explain causes in understandable terms (email format incorrect, password too short), and provide recovery steps (correct format example, minimum length requirement), users resolve issues efficiently without external assistance. Stripe exemplifies this—payment validation errors specify exact problems ("Card number invalid—must be 15-16 digits, currently 14"), explain requirements clearly, and show correction examples enabling quick resolution maintaining transaction flow.
For Designers: Error specificity prevents repeated failures through trial-and-error guessing. Generic messages ("Invalid input," "Error occurred") force users to guess what's wrong trying random corrections hoping to stumble upon solutions—inefficient process generating frustration and abandonment. Specific error communication ("Password requires: 1 uppercase letter (missing), 1 number (✓), minimum 8 characters (currently 6)") enables targeted correction. GitHub's pull request validation demonstrates this—specific error messages identify exact problems (missing required reviewers, failing status checks, merge conflicts) with precise resolution guidance preventing repeated submission attempts.
For Product Managers: Non-technical language makes errors understandable to diverse users regardless of technical expertise. When error messages present system codes, technical jargon, or developer-oriented information ("HTTP 422 Unprocessable Entity," "CONSTRAINT FK_users_organizations VIOLATION"), users cannot determine problems or solutions requiring support escalation. Plain language communication ("Account not found—check email spelling or create new account") enables self-service resolution. Notion's error messages demonstrate this—collaboration limit errors explain "Workspace supports 10 members (currently 11 invited). Upgrade to add unlimited members" avoiding technical terminology while providing clear understanding and resolution path.
For Developers: Constructive tone maintains user confidence during failures preventing blame attribution and system distrust. Error messages using accusatory language ("Illegal operation," "Forbidden," "Invalid action") create perception that users did something wrong damaging confidence and willingness to continue. Supportive language ("Let's fix this together," "Something went wrong on our end," "Almost there—one more thing needed") acknowledges shared responsibility maintaining positive user-system relationship. Linear's error communication demonstrates supportive tone—validation messages frame errors as helpful guidance rather than user failures maintaining confidence even during correction cycles.
Specific problem identification clearly states what went wrong using precise descriptive language. Avoid generic errors ("Something went wrong," "Error occurred," "Invalid input") in favor of specific descriptions ("Email address format incorrect," "Password too short," "File size exceeds 10MB limit"). Include contextual information when helpful—which specific field invalid, current value versus required value, location of problem within larger context. Shopify's form validation demonstrates specificity—errors identify exact fields with problems, current values, and requirements enabling targeted correction without examining entire forms.
Plain language explanation communicates causes understandably avoiding technical jargon, error codes, and system-oriented terminology. Translate technical problems into user-understandable descriptions—instead of "HTTP 401 Unauthorized" explain "Login expired—please sign in again," instead of "FOREIGN KEY constraint failed" explain "Cannot delete item—other content depends on it." Provide context helping users understand why operations failed building mental models preventing future errors. Notion's error explanations demonstrate this—technical failures translated into understandable explanations with context about system constraints and requirements.
Actionable recovery guidance provides specific steps users can take to resolve problems. Structure recovery instructions as clear numbered steps or bulleted actions rather than vague suggestions. Prioritize most likely solutions presenting them prominently while offering alternative approaches when primary methods might not apply. Include examples showing correct format or required values when applicable. Stripe's API error messages exemplify actionable guidance—specific code corrections, field format examples, parameter requirement explanations enabling efficient problem resolution.
Constructive supportive tone uses language that acknowledges shared responsibility and maintains user confidence. Avoid blame ("You entered invalid data," "Illegal operation attempted") in favor of neutral or system-responsibility framing ("Let's try a different format," "System requires additional information," "This action isn't available right now"). Use apologetic language when appropriate for system failures ("Sorry, something went wrong on our end") and encouraging language for user input errors ("Almost there," "One more thing needed"). ChatGPT's error communication demonstrates supportive tone—failures acknowledged with understanding language maintaining conversational partnership rather than criticism.
Progressive error detail provides essential information immediately with optional access to technical detail or extensive troubleshooting. Structure errors with prominent primary message (problem identification, main recovery action), expandable explanation (why error occurred, system constraints), and additional resources (support links, documentation, technical codes for support tickets). This enables quick resolution for users understanding problems while supporting those needing deeper explanation. Figma's collaboration errors demonstrate progressive disclosure—concise primary messages with expandable technical details and support resources.
Contextual error placement displays messages near relevant interface elements using appropriate prominence based on error severity. Place field-level errors adjacent to problematic inputs, form-level errors at submission locations, system-level errors in dedicated notification areas. Use visual hierarchy distinguishing between critical errors blocking progress (prominent modals, blocking messages), important errors requiring attention (inline messages, notification banners), and warnings about potential issues (subtle indicators, informational messages). Linear's error placement demonstrates contextual positioning—field errors appear inline, operation errors show prominent notifications, warnings display as subtle toasts.