Error messages are conversations with frustrated people.
Users tried to do something. It didn’t work. Now they need to know what happened and what to do next. The error message is your one chance to keep them on track instead of driving them away.
Most error messages fail this moment. They speak in technical language users don’t understand. They blame without helping. They describe problems without solutions. The user, already annoyed, becomes more annoyed.
Good error messages do the opposite. They explain clearly, guide helpfully, and maintain the relationship even when things go wrong.
Technical Language Alienates
“Error 500: Internal Server Error.”
To a developer, this means something. To a user trying to buy shoes, it means nothing. Worse than nothing, it signals that this website speaks a language they don’t share.
“NullReferenceException in Module.CheckoutHandler”
Even more alienating. The user sees code terminology and feels they’ve broken something complex. Anxiety increases. Trust decreases.
Users need human language. “Something went wrong on our end. We’re looking into it.” This says the same thing as Error 500 but treats the user like a person rather than a console.
Strip out status codes, exception names, technical jargon, database references, anything that requires developer knowledge to interpret. These details belong in logs for debugging, not on screens for users.
Translation exercise: explain the error as you would to a friend who knows nothing about technology. Whatever words you’d use in that conversation are the words that belong in the message.
Blame Destroys Relationships
“You entered an invalid email address.”
Who is “you” here, and why does the system sound accusatory? The user made a typo, not a moral failing.
“Invalid password: must contain uppercase, lowercase, number, and special character.”
Users didn’t know the requirements. Now they’re being told they did something wrong. The failure isn’t theirs; it’s the system’s failure to communicate requirements before submission.
Passive voice sometimes helps. “The email address wasn’t recognized” removes accusation. The address wasn’t recognized, not you failed to enter correctly. Subtle difference, but tone matters when users are frustrated.
Better still: constructive framing. “Email addresses include an @ symbol. Check your entry and try again.” No blame, just helpful observation and clear next step.
Ownership where appropriate. If the error is system-side, say so. “We’re having trouble processing your request right now.” Acknowledging that the problem is on your end preserves user confidence in themselves while maintaining honesty about what happened.
Solutions Not Just Problems
“Your session has expired.”
Okay. Now what? The message describes a problem but offers no path forward.
“Your session has expired. Please sign in again to continue.”
Better. The problem exists and here’s the solution. The user knows what to do.
“Your session has expired. Click here to sign in again and continue where you left off.”
Best. The solution is one click away. The user won’t lose progress. Anxiety addressed, path clear.
Every error message should answer: what happened, why it matters, and what to do next. Messages that answer only the first question abandon users mid-problem.
Action links within error messages reduce friction. Instead of telling users to go somewhere, take them there. “Return to cart” is more helpful than “Go back to your cart to try again.”
When problems have multiple possible solutions, list them. “This could mean your card declined, your billing address doesn’t match, or the transaction timed out. Try re-entering your payment details or use a different card.”
Visual Design Communicates Severity
Color coding sets expectations. Red signals something is wrong. Yellow suggests caution. Blue indicates information. Green confirms success.
Users process these colors before reading text. A red banner creates urgency. A blue banner suggests routine information. Match color to actual severity.
Icons reinforce meaning. An exclamation mark draws attention. A checkmark confirms completion. A question mark suggests additional information is available. Icon plus color plus text creates redundant signals that ensure the message lands.
Don’t rely on color alone. Colorblind users can’t distinguish red from green reliably. Include text that conveys severity independent of color. The icon and text should make sense even without color information.
Position matters. Errors related to specific fields should appear near those fields. Users shouldn’t scroll to find where the problem is. General errors can appear at the top of the page, but field-specific errors need field-adjacent placement.
Prominence should match importance. A critical error preventing transaction completion deserves prominent placement. A minor validation issue on an optional field deserves modest presentation.
Brand Voice Applies Here Too
Casual brands can be casual in error messages. Formal brands should be formal. The error message is still brand communication.
Mailchimp’s error messages include gentle humor. That matches their playful brand voice throughout. A bank trying the same humor would feel inappropriate.
Conversational tone can humanize errors. “Oops, that didn’t work” feels friendlier than “Error: Operation failed.” But conversational tone must match overall brand voice.
Never let humor override clarity. A joke that obscures what went wrong serves the brand voice at the user’s expense. Clarity comes first; voice comes second.
Empathy is always appropriate. “We know this is frustrating” acknowledges user feelings without being patronizing. Even formal brands can express understanding.
404 Pages Deserve Attention
Page not found errors happen constantly. Users follow broken links, type URLs incorrectly, find outdated search results.
A default 404 page communicates nothing helpful. White page, black text, “404 Not Found.” The user is stuck with no guidance.
Custom 404 pages provide paths forward. Search box to find what they wanted. Links to popular pages. Navigation to main sections. The missing page is unfortunate; the user being stuck is preventable.
Brand expression is acceptable here since 404 pages aren’t critical errors. Creative illustrations, brand personality, even gentle humor can work. Unlike transactional errors where users need immediate solutions, 404 errors have space for brand moments.
But don’t let creativity obstruct function. The search box and navigation should be more prominent than the clever illustration. Helping users matters more than delighting them.
Preserving User Input
Few things frustrate more than losing work.
User fills a long form, submits, sees an error, and finds the form is blank. Everything they entered is gone. They have to start over.
This happens when forms clear on error. Don’t do this. When validation fails, keep the input and highlight the problem. Users should fix only what’s wrong, not re-enter everything.
Session timeouts are trickier. If a user spent time composing something and the session expires, where does that content go? Ideal: preserve it through the re-authentication process. Acceptable: warn before timeout with save prompts. Unacceptable: silent deletion without warning.
Multi-step forms especially need progress preservation. If a user completes three steps and fails on step four, they shouldn’t return to step one. Save completed steps. Return them to the failure point with their data intact.
Proactive Prevention
Best error message is no error message.
Inline validation catches problems before submission. User types invalid email, the field shows the issue immediately. No submit, no error page, no frustration.
Format hints prevent format errors. “DD/MM/YYYY” next to a date field tells users what you expect. “Password must be 8+ characters” shows requirements upfront.
Confirmation modals catch consequential mistakes. “Delete this item? This can’t be undone.” gives users a chance to reconsider before the error becomes permanent.
Character counters prevent truncation. Users see how much space remains before they exceed limits. No surprise errors when they submit.
Auto-correction handles predictable mistakes silently. If users commonly type “gmail” as “gmial,” auto-correct or suggest correction rather than rejecting the input.
Prevention costs less than recovery. Engineering effort toward preventing errors pays off more than engineering effort toward explaining errors.
FAQ
Should error messages ever use humor?
Only if humor is part of your brand voice and doesn’t obscure the message. For serious contexts like financial transactions or health information, skip humor entirely. For casual consumer products with established playful voice, light humor can humanize errors. Never let jokes make the problem or solution unclear.
Sometimes errors confuse even us. What then ourselves?
Be honest. “Something unexpected happened. We’re looking into it.” is better than making up explanations. Include a way to contact support or report the issue. Behind the scenes, ensure these errors are logged with enough context for debugging.
Our development team insists on showing error codes for support purposes. How do we balance?
Show codes in a small, unobtrusive way that doesn’t dominate the message. “Reference: ERR-2847” at the bottom in small text gives support teams the code without confusing users. Lead with human language, end with technical reference.
How often should we review and improve error messages?
Regularly. Monitor support tickets for confusion patterns. Track which errors trigger exits. User test error states alongside happy paths. Error messages often get written quickly during development and never revisited, which is why most are bad. Scheduled reviews improve them.
Sources
Nielsen Norman Group. Error Message Guidelines. nngroup.com/articles/error-message-guidelines
Baymard Institute. Form Validation Usability. baymard.com/blog/inline-form-validation
Microsoft Writing Style Guide. Error Messages. docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/e/error-message
A List Apart. The Design of Error Messages. alistapart.com