This morning, just as I was turning out of my driveway to begin my commute to work, the most amazing thing happened. I looked up at the sky to see the clouds spelling out this message: “The front burner of your gas stove is still on. To avoid harm, please return to your kitchen immediately and turn off the flow of gas before proceeding to the office.”
Of course, I'm lying. But wouldn't it be great?
Unfortunately, at most moments in our lives, we are on our own—unassisted by auto-reminders, error messages, clear instructions or safety nets. We misplace sunglasses. We leave gas tank caps rolling aimlessly about gas station parking lots. We leave our stoves on.
When we're on the World Wide Web, however, the safety net is vast and reassuring. It's one of the many beauties of the Internet and its applications. To selfishly distort Isaac Newton's third law of motion: for each erroneous action that is taken on a Web site, there should be an equal but opposite error message that puts us back on the path of success.
Why, then, is the average user's performance on the Web still riddled with frustration and, well, unresolved and repeated errors?
Not every element of every Web site design can cater to every user. Each user is different. Therefore, a site that seems to be quite usable to one user may produce occasional erroneous actions for another user. To some degree this is OK, as long as a Web site provides the right assistance to keep the more error-prone user moving forward.
Error messages are essentially the driver's side air bags of a Web site, the reserve ripcord that alleviates a user's virtual, downward spiral. An effective error message should quickly save the user after the primary design and content of an application fail to guide the user down the path of success.
It's important to understand, though, that effective error messages don't just benefit the users of a Web site. Effective error messages ultimately benefit the creators of a Web site by retaining users' interest and attention by creating a less frustrating online experience and building site loyalty, which helps to guide users toward the final goal intended by the site's creators.
Error Messages: Bumps in the Road, Not Roadblocks
Six basic guidelines for writing error messages will keep the user focused on completing a task.
1. Placement and Format
The obvious placement and simple format of an error message is the key to ensuring that a user sees an error message before even beginning to react to it. Don't waste the user's time by forcing him/her to investigate what went wrong. The placement and format of error messages should not be subtle, understated or so “over-designed” that they are easily mistaken for another page widget that the user will most likely overlook.
Once a user makes a critical error, the error message should not only be obvious on the page but also unavoidable. The most effective placement is within a JavaScript pop-up, which the user must acknowledge and close before it's possible to proceed. If you use Microsoft programs at all, you are probably familiar with the standard gray JavaScript boxes that pop up in the middle of your screen any time you make a potentially erroneous decision.
The format of the error message can impact whether a user sees the message, even if the placement is good. Some Web sites use red font for error messages, but if the Web site already uses red prominently in its color scheme, or if the user is one of millions of colorblind individuals, red font may not be that obvious to the user. For maximum readability, stick with basic sans-serif fonts in dark, basic colors (such as black), and use a 10-point (or larger) font size.
2. Voice
The voice of an error message has the power to lose or retain a user. It's a critical moment when a user's actions produce an error message on a Web site, and can quite possibly result in Web site abandonment if the user becomes disgusted with the experience.
It may sound silly, but the error message should speak to the user like a favorite schoolteacher, or a patient parent. The clearest way to present guidelines for error message voice is in a list of “dos” and “don'ts.”
Do…
- Use a warm, personal tone. An easy way to enhance this effect is to include personal pronouns such as “you” and “your.”
- Take the blame. Besides, it's really your problem if you anger and lose a user, not the user's problem. There are millions of other Web sites that are willing to bend over backwards to please the user if you won't.
Don't…
- Do not shout at the user. Shouting may be perceived when an error message contains exclamation points, long strings of capital letters, and bright red or yellow icons such as stop signs or yield signs.
- Do not use urgent or excited terminology such as “fatal,” “critical,” “severe,” “failed,” or “terminate.” Calm language is more likely to produce a calm reaction.
- Do not use techie jargon, code, or abbreviations. Humans are reading the error message, so use language a human will understand.
3. the Basic Formula
An error message should answer three questions, in this order:
- What's the problem?
- How do I fix the problem?
- How do I avoid the problem in the future?
The answer to these three questions is enough information to inform and encourage the user to complete the task. It also subtly ensures users that they are dealing with a competent, trustworthy Web site.
4. Length
The length of an error message depends entirely on the level of complication of a particular erroneous action. The key is to be concise but comprehensive. Limiting the length of an error message should not be your first priority.
5. an Example
By using the guidelines previously mentioned, the following example illustrates the difference between an ineffective and an effective error message:
- Ineffective error message: Your credit card has failed authorization.
- Effective error message: We are currently having trouble obtaining credit authorization. Please try again, or enter billing information for a different credit card.
6. Test!
You cannot determine the true effectiveness of error messages unless you test them on real users. Additionally, by testing error messages, you can be certain that all the necessary messages were deployed and deployed accurately.
And Finally…
The error messages on your Web site may not make or break your bottom line. With a little attention, though, error messages can create a resilient, trust-building safety net underneath your Web site's applications.
Now if you'll excuse me, I have to go turn off my stove.
