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 Error feedback 🤓
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, like error message windows (modals), toasts, banners, form 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
Here are some prompts to consider with your team when creating error feedback.
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 prevention might be possible?
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 component is the most appropriate for this situation?
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.
UX Patterns you can use
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.
💁 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.
☝️ 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:
- Operation was not successful
- The reason it was not successful
- What to do next
💁 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, 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.
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.
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.
Sign up to stay in the loop
Receive an email when we publish a new article on design.
“Nothing can make a user feel more lost and incapable than when they are faced with an error message that makes no sense.”