Error messages that don't blame the user

What it is

This is about how error message copy should be written: pin the explanation on system state or a specific triggering condition, rather than implying or directly stating "you did it wrong" or "you entered it incorrectly." It is a concrete question of wording, not a general discussion of how to classify or attribute errors.

Why it happens

The wording of an error message directly shapes what the user does next. A message that pins blame on the user ("wrong password," "invalid action") only tells them "you're wrong" without giving any clue about what to do next — which pushes some users to retry the same way over and over, unsure what they got wrong, or to give up outright. A message that describes the specific state and cause ("the phone number entered doesn't match this account, please check and try again" or "the network connection was briefly interrupted, please try again shortly") lets the user figure out which side the problem is on and choose the right next action.

Where it stops holding

This doesn't mean glossing over or dodging a problem that really was caused by user input — when the password genuinely was typed wrong, the message still needs to accurately state that fact; the point is to drop the extra accusatory tone and offer a next step (retry, or recover the password), not to avoid stating what happened. For errors genuinely within the user's control (a formatting mistake, a required field left blank), spelling out exactly which field and what format is expected helps more than a vague "it's not your fault." Not every user experiences extra frustration from message wording either — the benefit of this adaptation is clearest for users with lower technical confidence who are quick to doubt themselves; it matters less to users who don't pay much attention to tone.

Applying it

• Avoid words like "error," "invalid," or "incorrect" that only describe the outcome without explaining the cause; state the specific triggering condition instead — replace "verification code error" with "the verification code entered has expired, tap to request a new one."
• Avoid second-person accusatory phrasing ("you entered it wrong"); use neutral state descriptions instead ("this field's format doesn't match what's required").
• Pair every error message with an actionable next step rather than only stating the problem.
• Verification: pull every error message in the interface out on its own and read through them, flagging any that only describe "what happened" without saying "what to do next," and any second-person accusatory phrasing, then rewrite each one.

Related

• Same group: A11.03.5 persistent, visible undo affordance · A11.03.9 proxy operation and remote assistance scenarios
• Nearby: A7 mental models
• Search terms: blameless error message · error copy · actionable error state