At this point in the riddle, you hear “what am I?” Yep, you guessed it – error messages. (This diatribe can be applied to warnings and informational messages too)
Error messages are a legitimate and primary facet to a user interface. We as product designers conceive of a products to solve a problem or perform a service to users. We strive to make our product feel intuitive and natural. We always end up asking our users to assume a manner of interaction with our program. But no matter how well we do, we designers never get a perfect score, for we do not live in the user’s world.
Expectations that our users have of our product may not be met, and the reasons may be numerous. Maybe we weren’t as good at conceptualizing as we thought. Maybe what we wanted to build was too expensive in effort or time. Maybe someone in the decision chain is deciding things they ought to delegate. Whatever the reason, when the user deviates enough from the Chosen Path, an error message is likely to ensue.
The primary down side of error messages is that they interrupt the flow of work that the user is orchestrating. The user’s momentum is broken and they are reminded that the product they are working with cannot read their mind, and that it may not fit very well into their problem space. The user’s focus moves from the getting real work done to focusing on the error. This often results in annoyance or even anxiety.
To help convey the user’s anxiety level to developers, I describe an informal Angst Temperature Scale. In this scale, the lowest, cooler end represents a user’s lack of anxiety when they are moving along smoothly through your product. If any warning message shows up, the scale goes to pale yellow. If any error message shows up, the scale shows intense yellow. If the user sees a sloppy, unhelpful, or confusing error, the scale temperature is orange. The first intrusion into red occurs when a product has a silent error, which often is accompanied by puzzling application behavior. The anxiety scale tops out at a sizzling red when a product has a crash, usually accompanied by loss of data.
So what is going on in a user’s head when they see an error message? The answer is captured in two simple questions: “what just happened to me” and “what can be done about this by me.” I like to call this Me-centricity. It is a concept that developers either fail to recognize or under-appreciate. After all, developers historically write the error messages for self-consumption, right? So how do we correct this sorry state?
Recognize that error messages play to many consumers. Each has its own needs, own expectations, and own world view. These players are developers, technical writers, technical support, training, and everyone else! (You’ve got to love the irony in this taxonomy.) Each needs something different from an error message.
Before we get much farther into how to correct things, let me digress into some real-world, commercial examples of message (with a commentary in parenthesis):
- Changes are not saved! (It would be really nice to know why)
- You changes have been saved! (A misspelling and why put this message up at all?)
- Your project name has been saved! (Hmmm, I wonder what happened to the rest of the project?)
- 16 >= 16 (I’m not making this up – this is a real error message)
- Confirm to cancel, continue? (This is my all time favorite)
That last one is a real winner. I think it really is a diabolical way to paralyze your user into a permanent state of indecision.
So let’s take a look at critiquing this error message from an application called Navigator. This message is so typical of what a developer might produce without careful consideration.
The following Navigator file had an unexpected version: myproject.npj
This error message is marginal at best. It raises more questions than it answers. A user might be asking these questions:
- What does a file represent in Navigator?
- What was the found version? Expected version?
- Why would I hit this problem?
- How do I get past this problem?
A totally cool, enlightened developer might produce instead the following error message. Note that the underlined items represent hyperlinks to more information for the user.
The Navigator project below cannot be opened because it is incompatible with the current version of Navigator.
Myproject.npj
Details – the project was created by Navigator 2.4 (with project version 1.1) while the current version of Navigator is 3.0 (with project version 1.2). A list of Navigator releases and corresponding project versions can be found here.
If you need more information, contact technical support at support@hyperformix.com or send this file as an attachment.
This version of the error message is far superior to the original by almost any measure you choose, except the effort to create it. But what rules do we follow in creating better error messages?
Let me introduce you to the Jedi Master’s Guide to Error Messages. This is mostly a common sense set of rules to follow:
- Watch out for typos – it looks really sloppy. You don’t want your user thinking that they were the first ones to ever see this message on display.
- Use clear language. There is nothing worse than a confusing error message. Well, I guess there are worse things, but not many.
- Avoid slang. Nuff said.
- Do not mix languages.
- Do not introduce new concepts. Do not refer to concepts in your messages that are not supported in the user interface.
- Do not introduce new terminology. This one is frequently violated. Use the same terminology that is used in your user interface. This needs to be consistent with help too. There is nothing worse than multiple names for the same thing.
- All messages must have a unique identifier. This helps users quickly look up an explanation in the help.
- Easy access to support information. This might take the form of hyperlinks.
- Support “sendability”. Screen dumps can work after a fashion, but it’d be more convenient if users can copy the text of an error message as text and forward it in email.
- Let users drill down to details. In other words, the first part of the error message should be clear and simple. It is targeted at the end user. Let more sophisticated users read more or actually expand more detail if they actually need to.
So what is actually impeding the creation of more usable error messages? There are two things to consider. The first is a lack of technical support. The second is a development process issue. On the technical side of things:
- Developers typically use simple functions to show simple strings.
- The use of property files (a common technique for handling internationalization issues) favors simple string messages.
- There is very little if any support for hyperlinks in error messages. Some of this could be addressed by moving to a richer expression, such as HTML.
- There is no email support. So users are rarely presented with options like directly contacting technical support.
On the process side of things, there usually is none. That is, there is rarely anything in the development process to support better usability of messages. Often the other stakeholders (other developers, technical support, training, etc.) do not even review the messages or do so in an ad hoc fashion.
I’d like to close with one final thought. When was the last time you saw a usability study that focused on error messages?
