Error messages should explain the problem in plain language

What it is

The first layer of error recognition, diagnosis, and recovery is letting people understand what happened: an error message should state which action failed, what condition the system detected, and what it means for the user's outcome. Plain language is not about sounding casual — it is stating facts using the objects and states from the user's own task. The test of whether copy counts as plain language is not how polite it sounds, but whether the user can map the sentence back to the action they just took without consulting documentation.

Why it happens

Before a user can fix anything, they must build a problem representation in their head, which is essentially narrowing a hypothesis space of possible causes. Jargon, a vague "operation failed," or accusatory copy does not narrow that space — it widens it: the user cannot tell whether the failure belongs to input, permissions, network, or system fault, and can only trial-and-error across these categories, usually while already mildly anxious from having their task interrupted, which amplifies the cost of that trial and error. Plain language does the translation from internal system state to task event on the user's behalf, stating the detected technical difference directly in task terms — "your card was declined by the issuing bank" rather than "payment gateway returned code 402." That translation step is inference work the user would otherwise have to do themselves; the error copy does it in advance, narrowing the hypothesis space from "guess a broad category" straight down to "confirm one specific fact."

Where it stops holding

Plain language must not fabricate certainty. When the cause is unknown, state the known facts, the scope of impact, and the next step — do not invent a plausible-sounding but unverified cause (writing "unstable network" when the system genuinely does not know it is a network issue). A fabricated cause is worse than admitting the cause is unknown, because the user will troubleshoot along the wrong line and waste their own time. Security, privacy, and legal constraints sometimes forbid disclosing specifics — a failed login should not confirm "this email is not registered," to prevent account enumeration — and in that case the right move is to make clear what can be disclosed (a retry path, a support channel), not to let this principle force disclosure of something that should stay hidden. Copy also needs re-review after localization, since a literal translation easily loses the task-fit that made the original plain language work.

Applying it

• Use a fixed template: what happened, what it affects, why (if known and disclosable), what to do now — in that order, and do not reshuffle it.
• Use the vocabulary of the user's task; keep internal service names, exception class names, and abstract status codes out of the primary copy.
• Distinguish input error, insufficient permission, network interruption, system fault, and third-party rejection — these five map to completely different next actions for the user, so lumping them together is the same as having no categorization at all.
• How to check: run a failure-replay test — show the error state to a participant and immediately ask them to state in their own words what just happened and what they plan to do next; anyone who cannot answer, or gets the category wrong, is proof the copy failed to complete the translation.

Related

• Same group: B3.09.2 Pinpoint the location of the problem · B3.09.3 Provide an actionable path forward · B3.09.4 Do not use an error code as the only information
• Nearby: B3.05 Error Prevention · T1 Interface Copy and Content
• Search terms: error message · plain language · error recovery · problem representation