Content Benefit

Content Strategy | UX Writing | Content Design | Globalization | Communications

Error messages are opportunities

Error messages are opportunities

Error Messages: The Small Copy That Makes or Breaks Your Product

There is a quote often attributed to Maya Angelou that has always stuck with me: “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.” I think about this a lot when I write for digital products. And nowhere does it apply more directly than in error messages.

Users won’t remember the exact wording you chose for your button labels or your onboarding tooltips. But they will absolutely remember the moment your product made them feel stupid, lost, or stuck. Error messages are that moment, and we don’t spend nearly enough time getting them right.

Why error messages matter more than you think

Error messages are not edge cases. They are guaranteed touchpoints. Every user who fills in a form, makes a payment, uploads a file, or tries to log in will hit at least one at some point. Yet they are often the last thing a team thinks about.

As Nielsen Norman Group puts it, product teams can be so focused on designing or engineering the ideal user path that deviations from it become a frustrating afterthought. That afterthought has real consequences.

Don Norman, widely considered the father of user experience design, was direct about this in The Design of Everyday Things. His advice to designers: do not blame people for failing to use your products properly. Take people’s difficulties as signifiers of where the product can be improved. Eliminate all error verbiage from electronic or computer systems. Instead, provide help and guidance.

That is a high bar, and it is the right one.

Jakob Nielsen reinforced this with two of his ten usability heuristics. Heuristic #5 is error prevention: we should prevent problems from occurring by eliminating error-prone conditions or by providing a confirmation option before users commit to actions with serious consequences. Heuristic #9 helps users recognize, diagnose, and recover from errors. Error messages should be expressed in plain language, communicate the problem and a solution, and use visual styling that helps users notice them.

Prevention first, recovery second. And when recovery is needed, clarity above everything.

The three things every error message needs to do

Over the years, I have simplified this down to three non-negotiables.

1. Be clear about what happened. Do not make the user guess. Error messages should communicate in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution. If your message requires the user to interpret or decode anything, you have already lost them.

2. Explain the problem without blaming. It is important to remember not to blame the user. Even if they have clicked the wrong button, it is probably because they thought it was the right one. The design and content should solve these usability problems. It is not the user’s fault. The moment someone reads an error message and feels like an idiot, your product has damaged their trust, possibly for good.

3. Tell them what to do next. An error message with no path forward is just a dead end. State what the issue is in plain language, then what the user can do about it. Keep the tone factual yet friendly. A good error message is a guide, not a wall.

A real example from PayPal: what not to do

When I worked at PayPal, I came across an error message that has lived rent-free in my head ever since:

“No UTF-8 characters allowed in this field.”

I want to use this as a teaching moment because it is one of the most perfect examples of a developer writing for themselves rather than for the user.

UTF-8 is a character encoding standard. Most people using a payment platform have never heard of it and have no reason to. When they see this message, they have no idea what they did wrong, no idea how to fix it, and no confidence that they can move forward at all. The most likely outcome? They abandon the task entirely. For a checkout flow, that is a conversion killer. For any flow, it is a trust killer.

Here is a better version:

“This field only supports standard letters and numbers. Please remove any special characters and try again.”

It tells the user what is accepted. It tells them what to change. It does not require them to know anything about encoding standards. That is the whole job.

Three error messages that get it exactly right

Good error messages are rare enough that the good ones are worth celebrating. Here are three that show what is possible when UX writing is taken seriously.

Mailchimp: “Oops! That email address is already on this list.” Simple, warm, precise. It tells you exactly what the problem is (a duplicate email), suggests you may already have an account, and does not make you feel like you have done something wrong. It even opens the door to recovering the existing account without explicitly stating so.

Google: “Your password must be at least 8 characters.” This is a perfect inline validation message. Instead of a generic “Error,” it tells the user exactly what went wrong and how to fix it. The fix is embedded in the message itself. You do not need to read anything else or go looking for instructions. Done.

Slack: “We couldn’t send your message. Check your connection and try again.” When something goes wrong on the system side, Slack takes responsibility rather than blaming the user. For some error messages, it is especially important to take responsibility. If there is a system issue, you want to make sure the user does not think it is their fault. Slack does this well. It says “we couldn’t” rather than “your message failed to send,” and it offers a clear next step.

All three of these messages are short. All three are human. All three give the user somewhere to go. That is the formula.

Tone matters, but clarity comes first.

There is a temptation, especially in consumer products, to inject personality into every piece of UI copy, including errors. A little warmth goes a long way. But warmth without clarity is just noise.

As UX writer Dominic Warren put it in UX Collective, you can have friendly messages that are still clear. But if you use bad puns in your error messages, the user has no idea what is going on.

Amy Leak, also writing in UX Collective, described the goal well: the aim is to make your user feel like you are there, walking them through it. We are talking to humans, remember. And for more serious errors like payment failures or data issues, she is clear: steer clear of anything too lighthearted. Avoid mechanical language and jargon, opting for plain language at all times.

The sweet spot is human, calm, and useful. Save the humor for moments that can carry it.

Error messages and UX writing are the same discipline

If you are thinking about how to get your error messages right, you are already thinking about UX writing. The same principles that govern every word in your interface apply here, maybe even more so, because the stakes are higher. Users in an error state are already frustrated. They need your words to do real work.

If you want a solid foundation for approaching all interface copy, including errors, my piece on the core discipline of UX writing covers the thinking behind it. And if you want to go deeper on a specific (and chronically underestimated) error state, I have also written about how to handle 404 pages, which are their own category of error message with their own rules.

The feeling stays

I will come back to where we started. Users won’t remember what your error message said word for word. But they will remember whether your product made them feel capable or helpless, guided or lost, respected or blamed.

An error is not just a functional interruption. It is a psychological event. It triggers confusion, frustration, and even panic, especially if the user feels at fault or does not know what to do next.

Your job as a writer, designer, or product person is to make that psychological event as short and painless as possible. A good error message does not just solve a technical problem. It tells the user: “We see you, we know what happened, and here is how we get through this together.”

That is the whole point.

Related sources

Chiara Bonifazi