x

Love our Articles?

Sign up and we’ll send you new ones every month.

Written By:
Fanny Vassilatos
Ceara Crawshaw

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. 

Definition of Feedback Error UX 🤓

Error feedback is the UI communication layer that includes any state, message (or combination) in a digital experience which warns users (prior to an action being executed) or notifies them of a problem in the system. Components in a UI are varied making error heuristics a very interesting world. Components might include error message windows (modals), toasts, banners, form fields and inputs or any others can incapsulate error feedback. Error feedback can even be mapped across multiple screens (in a flow), this magnitude of error handling usually happens in enterprise software due to its complexity.

Errors require 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 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 errors

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.

Scenario examples:

  • A file fails to upload during an onboarding flow
  • Search results timed out (after a search was initiated)
  • System could not find images
Counter-example of an error message modal where the copy is written in very technical language and the button is labelled "ok" Good example of an error message modal where the message explains what's going wrong in human words "Error. Notes that have been pinned cannot be accessed through search. Navigate to pinned items to access this note. See error log"

☝️ Quick note

Sometimes errors literally come directly from a server and will be riddled with gibberish (and you can’t change the message itself). To mitigate this situation, see if you can surround that error with human words, so that both technical and non-technical people can understand. That way, you can sustain the technical message but layer context around it.

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

Scenario examples:

  • 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
Counter example of an error message where the copy is written in Windings (illegible) and the button says "Ignore" Good example of an error message with a title "Upload failed", an explanation "There is already a file named Main-Banner.png in the Media Library." and call to actions "Replace or Cancel"action

💁 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.

Counter-example of 3 red error banners stating "Something went wrong" Good example of custom error messages in 3 stacked red banners: "background-XL-hi-res.jpg exceeds the size limit of 5 MB. Replace or Cancel", "motion-avatar.mov exceeds the size limit of 5 MB. Replace or Cancel", "Main-Banner.png exceeds the size limit of 5 MB. Replace or Cancel"

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.

Counter-example recording of an interaction on an "Email Address" text field where someone is typing and as soon as the letter "a" is input, an error message is shown stating "Must be a valid email address"

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).

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.

🎥 Error message UX discussion (video)

We spoke about design rationale in detail on our youtube channel, check it out!

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. 

If you want to dig in deeper, see how to build an error interaction from 1 to 3 (⭐️   to ⭐️ ⭐️ ⭐️ ) stars in our Design SOS course. We build up an interaction bit by bit to ultimately give users a sense of clarity layering on thought and consideration to do so! If you’re curious, check out the Design SOS page.

How does this fit in with the development workflow?

If you’ve been struggling to implement complex features, (like filtering) that your users find intuitive to use, we have put together a course (UX Skills for Developers) that will help improve your implementation and overall usability.

🧠 Want more enterprise-focused UX guidance?

You’ll probably enjoy our pattern analysis on enterprise data tables.

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