One of the most consistently neglected parts of today’s user experiences is our handling of errors. We’re so busy designing the happy paths through our products that we often forget to give the same care and attention to the times when things will go wrong.
Our digital products are littered with dead ends, meaningless error codes, decipherable only to developers, and infuriating whimsy that leave our users frustrated and stuck. Even when we do take the time to craft helpful error copy, we rarely document or encode such decisions so they can be easily reused and standardised across our digital landscape.
Here’s how to create error messages that help users recover quickly and continue their path through your products and services.
Consider the types of errors a user might encounterpermalink
The first step in planning and creating good error messages is to identify the different types of errors that could occur within our user experience. For example:
- form errors from missing or incorrect data
- validation errors on data a user submits
- error pages - like 404s or 500s
- search queries that return no results
- loss of internet connection
Auditing all the possible points of failure across the experience you’re designing will help avoid unintentional error messages ending up in front of your users.
Write like a humanpermalink
Thankfully, we see far fewer nonsensical error messages slipping through the cracks these days. 5-10 years ago, you could barely move on the internet without running into an Error: Exception Processing Code: 038638638638.
Nevertheless, there is still something about writing error messages that seems to inspire the robot in us. Saying “An error occurred” means nothing to anyone. It’s like saying “Something bad happened” and then walking away.
Instead, imagine sitting next to your user and gently guiding them through a snag. Say what you’ve written out loud and see if sounds like you’d say in a real-life conversation.
| Don’t do this | Do this instead |
|---|---|
| The input was invalid | Please enter the 6 digit code we emailed you |
| WiFi connection not detected | It looks like you’re offline. Please connect to a WiFi network and try again. |
Monzo has a particularly nice example of this. If someone tries to view loan options on their website — something that can only be done in the app — they simply say “You’ll need your phone for that”.
They also provide an more detailed explanation of the issue, and a QR code for quick access.
Monzo’s approach here is so action-focused, in fact, that you’d be forgiven for not recognising it as an error at all.
Steer clear of whimsypermalink
Whilst it’s better to keep error messages conversational, it’s important not to push it too far.
Saying “Hmmm, that doesn’t look quite right”, “Whoops-a-daisy!”, or showing a cute illustration of a sad robot on a 404 page is a fast way to irritate users in an already-frustrating situation.
When an online retailer called me a “silly sausage” recently for missing a dot in my email address, I swiftly abandoned my cart and sought my T-shirt elsewhere. When something goes wrong, I don’t need you to be my fun aunt — I need you to help me fix it.
Errors are moments of friction. Sometimes they’re unavoidable, but respecting our users means prioritising clarity and empathy - now is not the time to “inject personality”.
Whimsy can feel especially dismissive if a user is stressed or trying to complete something important. Imagine being late for a job interview and getting a “Whoopsie!” from the train ticketing app.
Ask yourself:
- would this message still work for someone having a bad day?
- could this language trivialise the issue?
- are we helping users get unstuck, or just showing off?
If in doubt, dial it back.
Use the active voicepermalink
Using the active voice is one of the best things you can do to improve your UX writing in general, and is particularly transformative when it comes to writing error messages.
The active voices tells us who is doing what, while the passive voice is ambiguous.
Take this example:
Your submission could not be processed.
Processed by who? What went wrong? What do I do about it?
Instead, try saying:
We couldn’t process your application because the file type you’ve attached isn’t supported. Please re-attach the file as a jpeg and try again.
The active voice clarifies responsibilities and makes instructions explicit and harder to miss, making it easier to move forward.
Give a clear way forwardpermalink
Errors typically fall into one of two categories:
- errors a user can fix - like form errors or loss of wifi connection
- errors a user cannot fix - like a system failure
In both cases, it’s important to offer a next step to help users move forward with their task.
For errors a user can fix, we should clearly state what they need to do.
| Don’t do this | Do this instead |
|---|---|
| Payment failed | Check that your card details are correct, or try a different payment method |
| Name field cannot be blank | Enter your name |
For errors a user cannot fix, it’s still important to tell them what they should do now. For example, in the case of a 500 error code — that is an internal server error — we can do more than simply explaining that “There is a problem with the service”. Additionally, we can:
- offer an action: “Please try again later”
- give an alternative means of contact: “If you need help now, you can call us on [telephone number]”
- tell them what’s happened to any data they’ve submitted: “We’ve saved your answers and will store them for 30 days”
I’m a big fan of this example from The Wellcome Trust who give website visitors suggested actions to take if their search term doesn’t yield any results.
Use a consistent patternpermalink
Consistent error messages help users scan, understand and act more quickly. They also make our work easier, because we’re not having to design content from scratch every time we need to write an error message.
For known and common errors, like 404 pages or no search results, we can document the error copy as part of our design patterns for those scenarios.
For errors that vary depending on, for instance, the information a user is trying to provide, we can offer patterns for writing specific types of error messages.
Here’s an example:
- if a field is blank, use: “Enter your [whatever is missing]”
- if an entry is too long, use: “[whatever was inputted] must be [character limit] or less”
The GOV.UK Design System does this particularly well, providing both:
- specific error messages for known fields like email addresses
- patterns for writing error messages for generic components like text inputs
Wrapping uppermalink
Error messages are still an overlooked part of our user experiences, but they’re often where trust is won — and lost.
When we handle errors with care, clarity and empathy, we not only help users move forward, we show that we value their time, their goals and their experience.
In the end, if we show up well for our users when things go wrong, we lay the groundwork for better experiences overall.