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.