Error messages are part of your UI

November 10, 2009 · 3 min read

I just placed a needless call to tech support.

I was trying to get Internet access through one of those services that captures you using a proxy and makes you log in. In this case, you could enter a username and password, or just a prepaid code; I had a code. When I entered it, I got:

Your username is invalid.

I was confused: I hadn't entered a username, didn't have one as far as I knew, and didn't think I needed one if I had the code instead. Maybe I needed to register some sort of account? But the only way to register an account was to pay, and I was supposed to get this free using the code.

After a few minutes of exploring options, I called tech support. It was only while waiting on hold that it occurred to me to check whether I had entered the code correctly.

I hadn't. I had transposed two digits. Just as a support person was answering, I got in. "Nevermind," I said sheepishly.

My error was simple: easy to make, easy to check for, easy to correct. Yet I spent minutes trying to diagnose it and wasted a minute or two of some support person's time, because the error message was misleading. It told me my username was invalid, when I didn't have a username and in fact the code was wrong. If it had told me the actual error, I would have found and fixed the problem immediately. In fact, in this case, if it had even given me a generic error message ("Sorry, an error occurred") I would have guessed the error quickly.

Error messages are important. They are often overlooked as a corner case—after all, the software isn't supposed to have errors. But they happen anyway, because of inadvertent bugs, temporary failures in external systems, or—as in this case—user error.

Error messages are part of your user interface, and need to treated as such. They need to be designed.

Here's another example: Suppose your application uses the Twitter API to post tweets on behalf of your users. Something goes wrong while tweeting. If you give a generic error message such as "Error posting to Twitter", the user is left wondering: Was it just a fluke? Is Twitter down? Did I enter the wrong password for my Twitter account? Is this app just not working?

These cases require different actions of the user: try again immediately; try again later; correct the password; contact tech support. A generic error message gives no guidance. Worse, claiming the error is one thing when it's actually another will send the user down the wrong path—as happened to me with the Internet access.

In fact, one good test of an error message is: Does it let the user decide what to do next? Here's an example that fails that test in a different way. Windows, upon waking up from hibernation, can give an error like this:

The last attempt to restart the system from its previous location
failed. Attempt to restart again?

      Delete restoration data and proceed to system boot menu
      Continue with system restart

A friend of mine got this tonight and was not only confused, but worried. What does it mean to restart from the system's previous "location"? More importantly, what exactly is this "restoration data"? Without knowing that, the prospect of deleting it is frightening—for all the user knows, it might mean "wipe my system clean and lose all my files." My friend called two people for help before making any move at all.

It turns out this message basically means: "Windows tried to hibernate, but hit a problem restoring your memory snapshot. Do you want to try again, or should we just dump the snapshot and do a normal boot?" Dumping the snapshot is no big deal (assuming you saved your work before hibernating). But the user doesn't know that, and is paralyzed as a result. Explaining the error and the options clearly would have let the user take action confidently without consulting two friends and eleven Windows user forums.

Error messages are part of your UI, and should follow general UI design principles. They should direct the user what to do next, or present clear, meaningful choices and enough context to make them. The next time you do a UI, include error messages in your design.