- WHO WE ARE
- WHAT WE DO
- WHO WE SERVE
- JOIN US
- CONTACT US
So you made a mistake. Or wait, did the website you were using make a mistake?
Either way, errors can cause great frustration for users–users don’t like them and they will bounce away from their intended path. To err is human, To err is also the computer.
A poorly designed error message will confuse users, make them furious, and may cause something really, really, bad (or at least make them feel they’ve caused something really bad).
As good as Apple is about user interfaces, the original Mac OS team chose a picture of a bomb to put on their error message.
Mac OS system error alert from the System 7 era. These were a common sight and Mac users of the era commonly kept a paper clip nearby in order to restart the computer.
The Bomb was designed by Susan Kare and was displayed inside the System Error alert box. The notice appeared when the “classic” Macintosh OS (pre-Mac OS X) had a crash, which the system decided was unrecoverable. Since the “classic” Mac OS offered little memory protection, an application crash would often take down the entire system.
It’s not the most friendly thing to see, especially after having just lost two hours of work because you hadn’t been saving every five minutes!
Error prevention, detection, and recovery is an important part of the user experience of digital products. As UX professionals, it’s generally our goal to build products that people can use. At the core of the user-centered design is the understanding that users are our biggest resource constraint—and the hardest thing to change.
The first time I saw this error as a child, I sat by the window, hoping the police didn’t show up.
So what practices, do UX developers and designers implement to ensure they don’t fall victim to an error fail?
Use plain language to explain what has gone wrong instead of obscure codes or abbreviations such as “an error of type 2 has occurred”.
Think about when you send an email. What happens when you state in an email that you’ll include an attachment, but forget to do so? Finally, a job for that annoying paperclip: “You seem to want to attach a file to this message, but you have not done so. Would you like to attach one now?”
When error messages are done properly, they are visible and highly noticeable, both in terms of the message itself and how it indicates which dialogue element users must repair.
Sometimes, when a user makes a mistake in a Web form, they will get the same error message no matter which fields went wrong. Often, a small error message appeared on the top of the page, but since users look at the page’s actionable part first (i.e., the area with the form fields), they don’t typically notice the error. A related design flaw indicates an error state solely by turning the field label red.
This violates a simple rule of accessibility: to make the system feedback visible to the color-blind users. Redundant cues need to be accessible to those users.
When writing error messages, the message copy needs to be customized to address the actual error. It can be confusing if the message is too generic and doesn’t offer any clarity as to what exactly went wrong.
A good example:
Dropbox is very detailed in their error alert for an incorrect email address, by requesting the missing character.
Whenever possible, allow users to correct errors by editing their original action instead of having to do everything over again. For example, when presenting search results, show a search box with the user’s original query terms to facilitate revisions. If no hits were found, let users search a wider scope with a single click.
Another solution is to reduce the work of correcting the error. If possible, guess the correct action and let users pick it from a small list of fixes. For example, instead of just saying “city and zip code don’t match,” let users click on a button for the city that matches the zip code they entered.
Let’s face it, users don’t read software/website documentation before using it. Users only read system documentation when they are in trouble. And when that happens, most likely, they will abandon the software/website whenever they can. However, people are particularly attentive when they want to recover from an error. If used correctly, error messages can be used as an educational resource to educate about the application’s hidden features. It could also be a good idea to add relevant links to additional background material or tutorials. But be cautious here, don’t overdo it. Keep the message brief and to the point.
Oftentimes, error messages can get very technical (read: intimidating) to a user. Moreover, some errors place blame on the user. As an important element of UX of interaction design, it’s important to write error messages in an understanding and friendly tone. It’s also important to keep the tone of voice consistent throughout the whole system.
What are some of the most frustrating errors you encounter? Let us know in a comment below.
Never miss a thing by signing up for our newsletter. We periodically send out important news, blogs, and other announcements. Don’t worry, we promise not to spam you.