Designing the Not-So-Happy Path
How to craft the right error messages when things go wrong
When designing a feature/product, we often start with the happy path, a scenario where everything goes as expected (i.e. no errors). This is usually a good starting point, since it allows stakeholders to focus on the goal of the said feature/product. However, it is critical not to stop here. Let’s face it, errors happen all the time, whether they are caused by the user or the system.
We at Salesforce are acutely aware of this, given that enterprise users interact with products like ours day in and day out. Additionally, many enterprise products (including Salesforce) are highly customizable, which means that not all implementations are equally well-done. This makes error recovery even more important.
Poorly-designed error messages are roadblocks which lead to an aggravating user experience. To address this, your design should: 1) mitigate and accommodate those errors, and: 2) help users recover and inform them on how to proceed next. Below I will discuss some design guidelines for better error messages and include examples from Salesforce products.
“The very worst error messages are those that don’t exist”
— Jakob Nielsen
Prevent errors if possible
User errors happen, but there are ways to avoid them via design constraints. For instance, when a user is scheduling an event with a start and end date, the end date simply cannot occur before the start date.
When this happens, it’s safe to assume that the user doesn’t intend to enter such an impossible value. To address this, we designed the fields so that such selection results in the start date being retroactively changed to be the same as the end date. As a result, the dates remain valid and the user won’t see an error message.
Validate user input in real-time
Input validation informs the user of what went wrong, which helps them recover and fix those errors. Live validation is especially useful for certain inputs that have less predictable parameters.
Consider a password creation flow, for example. When a new user creates an account, they may be prompted to create a password as well. Typically, they are prompted to enter the password twice to ensure that the value is what they intended. However, since password inputs are masked for security reasons, it’s more difficult for the user to compare the values they have entered in both fields. Password requirements also vary from one product to the next, so a user is less likely to have a clear idea on what they need to enter to satisfy those requirements.
To make this experience smoother, we use live validation to guide the user as they are filling out the fields. This enables the user to fix the problem as soon as possible, rather than discovering it after attempting to save their data.
Create shortcuts to the problematic areas
Although live input validation is ideal, there may be times when this is not possible (due to technical constraints, for instance). In such a scenario, all the validations will happen simultaneously after the user submits their data, and only then will the user discover the error messages. This can be a jarring and unpleasant experience, especially if the user is dealing with multiple error messages in a long form.
Form errors are a common occurrence in enterprise applications, given that users add, edit, and delete information all the time. One way to address this is to build shortcuts within the experience so the user could get to the errors more efficiently.
You’ll notice that the problematic field(s) is listed in the error panel, which also serves as a shortcut link to the associated field. When the user clicks on this link, the focus switches to the field in question and they can immediately change the value to fix the error.
Preserve user’s inputs
Inputting data can be tedious, and it’s even worse when the data that has been entered suddenly disappears due to an error. This is not uncommon with users who work on their mobile device, since they may not always have a reliable network connection. There is always a risk of losing their work if the connection happens to be bad/unavailable when they hit “submit.”
Making a user enter the same data twice is highly counterproductive, but this can be prevented by preserving the user’s input as much as possible.
(Image: Lheyla Escobar)
In Salesforce1 (Salesforce’s mobile app), we tackle this issue by adopting an “offline-first” approach, i.e. storing changes locally and syncing them to the system as soon as there is a stable connection. Rather than showing an “offline” error message, we preserve the user’s inputs automatically and resolve this error in the background to avoid future agitations.
Consider the context of the error message
Error messages should not be uniform throughout your product; users encounter them in varying circumstances and levels of severity and impact. Let’s take a look at two different contexts below.
In the first example, the user filled out a form field incorrectly. This error is specific and localized, and thus, the error message is displayed on field-level, directly next to the area that is problematic.
In the second example, the user’s browser is outdated and thus cannot run the app properly. This error is global and relevant to the user no matter where they are in the app. As such, the error message is persistently displayed above everything.
The error messages appear and behave differently in these examples because the contexts are different. Although UI consistency is important, don’t prioritize it over clarity.
Error messages should not be uniform throughout your product … Don’t prioritize consistency over clarity.
Make it accessible
Speaking of clarity, designers sometimes assume that using a different color (typically red) to show error message is clear enough. It is not. Using color as the only visual means of conveying information means excluding people who are color blind (1 in 12 men, 1 in 200 women), have low vision (1 in 30 people), or are blind (1 in 188 people).
The short form above is one example where the design only uses color to identify errors. Notice how difficult it is to spot the problematic field when colors are absent.
On the other hand, spotting the erroneous field is much easier when there are additional visual indicators. In the example above, the input field’s border is thicker and the error text is displayed right below it.
There are many potential design solutions to improve the visual accessibility of your error messages. One basic rule to remember is to not use colors as the sole indicator.
Write clearly and constructively
Errors are frustrating. Cryptic errors are even more so. Compare, for example, Error ID: 969220651–11493 to An internal server error has occurred. The system code may be useful for technical troubleshooting, but by itself it’s confusing to the user. If this code needs to be shown, don’t neglect to include a human-readable error message.
Effective error messages should also inform the user as to how to fix the issue. If the user fills out a form field incorrectly, for instance, provide a correct example on which they can model their answer on: Phone number can only contain numbers, e.g. 555–666–7777.
In addition, consider the voice and tone of the error message. Humorous/sassy messages are fine in certain cases, but when it involves catastrophic situations (such as data loss), they come across as flippant and disrespectful of the users. Be careful not to blame the users if the issue is with the system. Saying You seem to be having trouble blames the user, whereas I seem to be having trouble acknowledges that the user didn’t do anything wrong. The difference of the pronoun matters.
Use images (sparingly) to soften the message
Images/illustrations can be useful in error states because they help reduce negative impressions on the user. An error message paired with a piece of imagery is not only more pleasing visually, but it also gives your product some warmth and personality.
Be careful not to go overboard with imagery, however. Simpler error messages such as “page not found” may work well with images, but such design is probably redundant for individual form field error messages. Sometimes, short and simple text is sufficient.
“People err. That is a fact of life. People are not precision machinery designed for accuracy.”
— Donald Norman
Errors are a natural part of using a product, but they are often under-designed, resulting in frustration at moments when users can afford it the least. Although we can’t eliminate errors entirely, we can anticipate them and craft the right error experiences when things go wrong.
To err is human; to craft better error messages, design.
Thank you Ian Schoen and Kathy Baxter for all of your feedback!
Follow us at @SalesforceUX.
Want to work with us? Contact uxcareers@salesforce.com
Check out the Salesforce Lightning Design System
