The Error Message Is a Tiny Theory of Blame
An error message is never just a technical report. It is a tiny theory of blame: an interface deciding what happened, who must act, and how much of the system’s failure the person in front of the screen should be forced to carry. Good error-message design makes a breakdown legible and recoverable. Bad design converts uncertainty into accusation.
The difference is visible in two familiar sentences. “You entered an invalid date” treats the person as the defective component. “Enter a date in the format 23 September 2026” describes the system’s expectation and supplies a path forward. Both may refer to the same failed validation, but they build different moral worlds.
Every error message answers four hidden questions
An interface failure has at least four parts: an event, a cause, a consequence, and a recovery path. The message chooses which parts to reveal. That selection is political in the small sense: it distributes knowledge and responsibility between the organization that built the system and the person trying to use it.
First comes detection: what did the software notice? Second comes attribution: did the person, device, network, service, or policy cause the problem? Third comes impact: was anything lost, delayed, duplicated, or charged? Fourth comes agency: what can someone do now? A message that omits agency is not guidance. It is a locked door with a label.
The accessibility stakes are concrete. The W3C’s explanation of WCAG 2.2 error identification says people must be told in text that an error occurred and what is wrong. A red outline alone cannot carry that information for everyone.
A taxonomy of blame
Error messages tend to fall into four moral styles. The first is accusatory: “You did something wrong.” The second is evasive: “Something went wrong.” The third is bureaucratic: “Request failed, code 0x80004005.” The fourth is collaborative: “We couldn’t save your changes. Your draft is still here; reconnect and try again.”
Accusatory messages may be technically accurate, but accuracy is not the same as usefulness. If a password field forbids spaces, the useful fact is the rule, not a verdict about the person. When a form rejects a name because its database was designed around narrow assumptions, calling the name invalid conceals a design decision behind the language of natural law.
Evasive messages protect the system from making a false claim, yet they often protect the organization more than the reader. “Something went wrong” says almost nothing while quietly transferring the investigative work outward. Was the payment declined? Did the server time out? Was the button pressed twice? Should the person wait, retry, or call somebody?
Bureaucratic messages expose internal machinery without translation. Error codes can help support teams and expert users, but a code is an identifier, not an explanation. The humane pattern is layered: plain-language summary first, concrete recovery second, diagnostic detail available rather than dumped into the main path.
Collaborative messages describe the system as one participant in a shared problem. This does not require fake cheerfulness or an apology after every failed click. It requires candor: what failed, what state was preserved, what action is safe, and where responsibility currently sits.
The grammar of responsibility
Pronouns do quiet work. “You failed to upload the file” assigns failure to the person. “The file could not be uploaded” hides every actor. “We couldn’t upload the file because the connection ended” names the system, the event, and a plausible cause. Grammar becomes infrastructure for trust.
Tense matters too. A message in the present—“Your account is locked”—can feel permanent. A time-bound version—“Sign-in is paused for 15 minutes after five attempts”—turns a wall into a condition. Specificity reduces the supernatural aura that badly designed software acquires when it behaves like an offended god.
Buttons complete the sentence. An error ending in “OK” offers compliance, not recovery. A useful action says what happens next: “Try again,” “Save a copy,” “Review address,” or “Contact support with code 4812.” The action label should match the actual remedy, not merely dismiss evidence of the failure.
Microsoft’s Fluent guidance for fields treats validation messages as guidance that helps people move forward. The GOV.UK Design System is even plainer: explain what went wrong and how to fix it. These are modest rules, but many products still stop after announcing failure.
When kindness becomes camouflage
There is a counterargument: friendly error copy can become manipulative. A smiling mascot saying “Oopsie!” does not improve a lost tax filing, deleted project, failed medical portal, or duplicate charge. Tone cannot substitute for state preservation, honest attribution, or a working recovery route.
The same problem appears when companies anthropomorphize systems selectively. The product says “We’re sorry” when nobody is accountable, but switches to “Your payment failed” when money is involved. Politeness is useful only when it accompanies operational truth. Otherwise it is decorative fog.
Another counterargument is security. Some messages should not reveal whether an account exists, why authentication failed, or which internal service broke. That constraint is real. Yet safe ambiguity can still be actionable: explain that the credentials could not be verified, preserve entered data when appropriate, identify the next permitted step, and provide a reference code.
Good error design therefore balances disclosure with risk. It should reveal enough for recovery without leaking sensitive state. The result may be less specific than an engineer wants, but it should never be less useful than the system permits.
A six-question test for humane errors
A practical review can begin with six questions. What happened in ordinary language? What information is certain rather than guessed? What happened to the person’s work or money? What can they safely do next? Can they get more detail if needed? Does the wording blame them for a constraint created by the system?
Placement belongs in the test. The GOV.UK validation pattern pairs a summary with messages beside the affected answers. IBM Carbon’s accessibility guidance likewise combines visible and programmatic error states. A message across the screen from the broken field makes the reader perform spatial detective work.
Recovery also depends on reversibility. A system that preserves drafts, keeps form values, and distinguishes retrying from resubmitting is doing more ethical work than one with perfect prose and destructive behavior. This is where error design meets a larger argument about treating mistakes and interruptions as expected conditions, not moral defects.
That argument appears in The Undo Button Made Failure Reversible, where reversibility becomes a form of respect rather than merely a convenient feature.
Failure should leave a map
The best error message is not necessarily gentle. It is precise, proportional, and attached to a real way forward. Sometimes the honest sentence is severe: “This file is permanently deleted and cannot be recovered.” False reassurance would be worse. Humane design respects people enough to tell them where the edge actually is.
This also explains why intentional friction can be valuable. As argued in The Case for Friction in Interface Design, a pause before an irreversible act protects agency. The error state after the act should not pretend that the missing pause was the user’s personal failure.
An error message is the moment when an interface reveals its philosophy of power. Does it hoard knowledge, issue judgment, and demand obedience? Or does it share what it knows, admit what it does not, preserve what it can, and return a meaningful choice? Systems fail. The moral question is what they ask people to become when they do.
Which error message has stayed with you most—because it genuinely helped, unfairly blamed you, concealed the real problem, or became memorable through sheer absurdity?
If the aesthetics of visible system failure speak to you, explore Glitchwear and join the Claw & Riot Salon to continue the discussion.
Comments