Error Message Handling & Feedback

Make no mistake, errors matter. What’s the most famous bad UX out there? An inscrutable error message, that’s what. Gone are the days where you can really get away with scabby error feedback, especially when it comes to enterprise software, where the UX quality standards are catching up with consumer products.

Error handling UX requires special thought, especially in enterprise software because:

• The technical source of the problem can be very complex. For example, it can be related to things like data, permissions, race conditions or processing.
• The solution may be difficult to explain. When explaining how to solve the problem, defaulting to “Contact administrator” is the lowest level of information we can provide.
• Creating a consistent ‘error feedback system’ may require technical collaboration with your developer colleagues. Often, error messages are buried throughout the code, not found in a quick and clean XML file

Things to consider for designing error message UX

Here are some prompts to consider with your team when creating feedback error UX, whether that’s determining when to display an error message, or what form the error feedback will take in the UI.

What is actually happening in this situation?

Make sure you understand the errors yourself so you can craft comprehensive messages for each of them.

What error prevention might be possible in the UI?

Can we proactively communicate things rather than allowing the error to happen in the first place? Some UIs over rely on error messages and end up with a very reactionary and negative tone in the interface.

What UI components are the most appropriate for this situation?

Make sure the UI you use is up for the task. Is it a modal window, toast, banner or inline feedback of other kinds? How much context does the error need? Highly contextual = inline, app-wide = modal, etc. Make sure you don’t overshoot it or underplay the error itself. If the error is blocking, please feel free to make a scene.

UX Patterns you can use for error messages

Use Case: System Error

Things like invalid requests or resources not found can seem intelligible for most technical people, but displaying a system error to a user is a unique opportunity to bring a human touch to a machine communication. These system errors include 404, 403, 500 messages.

💁 UX Tip: Communicate clearly to the user what the error is and what caused it

Here, it’s important to avoid as much jargon as possible. Unless your users are highly technical and it’s relevant to the task they’re working on.

You want to be clear about exactly what went wrong and why. In some cases, this is a good place to educate users if something they did participated in said error. This way, they’ll be more aware in the future and will potentially avoid triggering the same error again.

Error example situations:

• A file fails to upload during an onboarding flow
• Search results timed out (after a search was initiated)
• System could not find images

Use Case: User error

Sometimes, the error is entirely on the user’s side. Maybe their Wi-Fi connection just abruptly dropped, or they’re trying to upload a file with an unsupported format.

In general good error handling is structured like this:

1. Operation was not successful
2. The reason it was not successful
3. What to do next

Error example situations:

• A user tries to move a file somewhere that it is not allowed
• A user can try to delete something they are not allowed to delete
• A user may try to change permissions when they are not allowed

💁 UX Tip: Tell users what they can do to recover from the error

Here, you want to inform them of (precisely) what went wrong and quickly nudge them towards what they can do to fix it.

They should never have to feel stuck in front of a passive error message.

In the example of an unsupported file upload, many things might be at play. Maybe the file is too big, maybe it’s in the wrong format, maybe another file with the same name exists.

Precision is key here. You really want to provide details so users can come out of the error with new knowledge so they don’t reproduce it.

💁 UX Tip: Present all errors and don’t persist error state

Along the lines of the Presumption of Innocence legal principle, your assumption should be that your user’s input is going to be good. Only state it as an error once you’re sure the user has come through with their intention of submitting the content.

An example you’ve probably already encountered as a user yourself is an email field giving you an error as soon as you’ve typed in the first character because the system is not detecting an “@” and a “.com”. Frustrating, right? In that case, the user is still in a partial state and no errors should be triggered until the field is out of focus.

In a form submission (say like a login form or onboarding form), showcase all the errors at once instead of one at a time and then wait for them to submit again and prompt the next error in line. Make sure your system returns all errors from the server (if the error is coming from the server) or if errors are a result of validation on the front-end, like in between input fields. (This is another great example of design and developer collaboration that can lead to a great UX).

Finally, make sure the error state isn’t persistent. If you’ve shown what the error is and they’ve input something new, don’t assume the error is still there.

💁 UX Tip: Investigate how to prevent errors from happening again

In any case, you want to make sure you document these errors and their frequency and see how you can reduce their occurrence or fix them permanently. Getting some statistical visibility will help you identify what tends to trigger system errors.

In the case of user input errors, try to see where you can improve the instructions, maybe by distinctly styling the field type (date format, dropdown selection, text area, etc), or tweaking your placeholders, etc.

In a form submission (say like a login form or onboarding form), showcase all the errors at once instead of one at a time and then wait for them to submit again and prompt the next error in line. Make sure your system returns all errors from the server (if the error is coming from the server) or if errors are a result of validation on the front-end, like in between input fields. (This is another great example of design and developer collaboration that can lead to a great UX).

Wrapping up

Errors are often something we throw together as an afterthought, especially when they are brought on by an edge case. However, they are also a key place where you can accumulate very frustrating UX debt. Nothing can make a user feel more lost and incapable than when they are faced with an error message that makes no sense. This is where good UX writing can really shine, and using the ‘default’ in your system can destroy a user’s experience.

It’s not that we must expect perfection and zero hiccups as we navigate software, it’s about presenting something helpful when things do go wrong and users feeling capable of fixing it and not totally blocked and lost. If we compare an error in the computer to one at a restaurant, when restaurant staff deal with a mistake in a really outstanding way, communicate it to you clearly and solve the problem, it leaves an impression that you’ve been well taken care of. Interfaces can give you the same thing. Errors are an opportunity to wow your users and teach them more about the system they are using.

“Nothing can make a user feel more lost and incapable than when they are faced with an error message that makes no sense.”