Designing Better Error Messages: Turning Frustrating Moments Into Helpful Experiences

Error messages are among the smallest elements in a digital interface, but they can have an outsized impact on the user experience.

A user may spend minutes carefully filling out a form, navigating a checkout process, uploading a file, or setting up an account, only to encounter a message saying, “Something went wrong.”

At that moment, the design has a choice. It can leave the user wondering what happened and what to do next, or it can turn an otherwise frustrating moment into a clear, recoverable experience.

Good error messages aren’t simply notifications that something failed. They are part of the interface’s communication system. When designed well, they explain what happened, reduce uncertainty, and help users move forward.

An Error Is a Design Problem, Not Just a Technical Problem

From a development perspective, an error may be a straightforward event: an invalid input, a failed request, an expired session, or a server problem. From the user’s perspective, the technical cause is usually irrelevant.

They want to know three things:

• What happened?
• Why did it happen?
• What can I do now?

An error message that answers only the first question isn’t particularly helpful.

For example, “Invalid input” tells the user that something is wrong, but not which input is incorrect or how to fix it.

A better message identifies the problem and provides a path forward: For instance, “Enter a valid email address, such as name@example.com.” is more helpful. The difference is small in terms of wording, but significant in terms of usability.

Avoid Blaming the User

Errors are already frustrating, so the language surrounding them shouldn’t make the experience worse.

Messages such as “You entered the wrong password” or “You failed to complete the form” can sound accusatory, even when the intention is purely informational.

A more neutral approach focuses on the situation rather than the person. Instead of:

“You entered an invalid card number.”

Consider:

“Check your card number. It should contain 16 digits.”

The second version communicates the same basic information without assigning blame. This principle becomes particularly important when an error isn’t actually caused by the user.

If a service is temporarily unavailable, telling someone to “Try entering the information again” creates confusion. The interface should acknowledge when the problem is on the system’s side.

Be Specific About What Went Wrong

Vague error messages force users to become detectives. They include:

• Something went wrong
• An error occurred
• Invalid information

These phrases might be technically accurate, but they provide almost no useful information. Specificity gives users a better chance of recovering without assistance. Consider a file-upload experience. Instead of saying “upload failed”, the interface could say:

“This file is larger than 10 MB. Choose a smaller file and try again.”

The improved message identifies the problem and immediately suggests a solution.

Specificity is particularly valuable in forms, where multiple fields can fail at once. Highlighting the relevant field and explaining the problem next to it is generally more useful than displaying a generic error at the top of the page.

Tell Users How to Recover

An error message shouldn’t stop at explaining what happened. Whenever possible, it should tell users what to do next.

For example, “Password must contain at least 8 characters, including one number” is more useful than “Password requirements not met.” Similarly, “Your session has expired. Sign in again to continue” provides a clear recovery path.

The best error messages reduce the amount of thinking required after something goes wrong. The user shouldn’t have to search through a help center to discover the next step if the interface can explain it directly.

Put the Message Where the Problem Occurs

Location also matters. Imagine a long registration form with 15 fields. After the user clicks “Create account,” a small message appears at the very top saying, “Please correct the highlighted fields.”

The user now has to search the entire page to discover which fields need attention. A better approach is to combine an overall summary with contextual messages beside the relevant fields.

For example:

• Email: “Enter a valid email address.”
• Password: “Use at least 8 characters.”
• Phone number: “Enter a 10-digit phone number.”

The closer the message is to the problem, the less effort the user needs to locate and understand it.

This is especially important on mobile devices, where navigating back and forth across a long screen can be frustrating.

Don’t Make Users Start Over

One of the worst error experiences is losing information that the user has already entered. Picture completing a long application form only to discover that one field contains an error, and then having the entire form reset.

The technical failure may be minor, but the perceived cost is enormous. Good error handling preserves user input whenever possible.

If a submission fails because of a network problem, the interface should ideally retain the completed information. If a form contains one invalid field, correcting that field shouldn’t require users to re-enter everything else.

Designing for errors means designing for recovery, not simply detecting failure.

Use Visual Design to Support the Message

Words aren’t the only way to communicate an error. Color, icons, borders, spacing, typography, and positioning can reinforce the message. However, designers should avoid relying on color alone.

A red border might indicate an invalid field, but users with certain forms of color-vision deficiency may not distinguish it easily. Adding an icon, descriptive text, or another visual indicator provides additional context.

Similarly, error states should be visually distinct without becoming unnecessarily aggressive. Not every error needs a huge red banner. A minor validation issue might need a subtle inline message, while a serious system failure may require a more prominent notification. Visual emphasis should reflect the severity and consequences of the problem.

Distinguish Between User Errors and System Errors

Not every error should be handled in the same way. A user entering an incorrect email address is different from a payment service becoming unavailable. These situations require different messages and different recovery options.

• For a user input problem:

“Enter a valid date in the format DD/MM/YYYY.”

• For a system problem:

“We couldn’t process your payment right now. Your card hasn’t been charged. Please try again in a few minutes.”

The second message is particularly useful because it addresses an important concern: what happened to the user’s money?

Good error design anticipates the questions users are likely to have, not just the technical event that triggered the message.

Avoid Technical Jargon

Users shouldn’t need to understand the system’s internal architecture to recover from an error. Messages containing terms such as “500 Internal Server Error,” “authentication token expired,” or “null reference exception” may be useful to developers, but they rarely help ordinary users.

Technical information can still be captured in logs or made available through an advanced troubleshooting interface.

The primary user-facing message should focus on what the person needs to understand and do. For instance, instead of:

“HTTP 403: Authentication token invalid.”

Try:

“Your session has expired. Please sign in again.”

The underlying technical problem may be identical but the communication should be simple to be useful.

Give Users Feedback When Waiting Is the Solution

Some failures aren’t actually failures yet. A request, for instance, might simply be taking longer than expected. If the interface provides no feedback, users may assume something has gone wrong and repeatedly click a button, refresh the page, or abandon the task.

Loading states, progress indicators, and reassuring messages can prevent this. For example: “Uploading your file…” is better than leaving the interface unchanged for several seconds.

If something does eventually fail, the interface can then transition from the loading state to a clear error state. This helps users understand that the system is working rather than silently ignoring their action.

Treat Error Messages as Part of the Product’s Voice

Error states are part of the brand experience. That doesn’t mean every error needs a clever joke or playful illustration. In some contexts, humor can make a frustrating situation worse.

An approachable consumer application might use conversational language. A banking or healthcare product may require a more restrained and reassuring tone. But whatever the tone, it should remain clear.

Design for Recovery, Not Perfection

No interface is completely free of errors. Networks fail, users mistype information, services go offline, files are rejected, sessions expire, and unexpected conditions occur. The goal of good UX isn’t to pretend these situations don’t exist. It’s to make them easier to recover from.

A well-designed error message identifies the problem, explains it in understandable language, appears in the right place, and gives the user a realistic next step. It preserves their work whenever possible and avoids unnecessary blame or technical jargon.

Most importantly, it treats the error as part of the experience rather than an interruption to it. When designers approach errors this way, a frustrating moment becomes an opportunity to demonstrate clarity, empathy, and reliability.

The best error message isn’t the one that sounds clever. It’s the one that leaves the user thinking “I know what happened, and I know what to do next.”