Error messages: a guide for the perplexed

A good, thoughtful error message might be the only thing stopping a frustrated user from leaving your site. Read on to see how you can keep the user.

Hopefully, you’ve used good microcopy and your processes are simple and can’t be misunderstood. You chunk the date field so that the user doesn’t enter the wrong separator. You provide the format for the phone and passport fields. You do whatever it takes so that the user won’t see an error message; but maybe the user wasn’t concentrating 100%, or she had thick-finger syndrome (hitting 2 keys instead of 1). Whatever the reason, you need to invest in your error messages.

  • The first rule is to explain simply and clearly what the problem is.

  • The second rule is make sure they know what to do – the message must be clear and practical, and help them get out of the situation and continue the process.

  • The third rule is don’t make the user feel guilty. It's not their fault.

  • And finally, empathise with the user. They were trying to do something and they have been stopped by an error. They are probably frustrated and if the above rules are not met, might abandon the process. If there’s no solution, provide the user with an alternative action.

The tone of error messages

As you may remember, your product should have its own voice through which its personality shines. This is usually pretty constant. What changes is the tone. The tone of your voice depends on who you are talking to and the emotional state they are in. So when you are writing error messages, you need to show you understand the problem and how the user feels and that you can provide tools to help them. Don’t try to be clever here. Use humour sparingly and only if you really know your users.

Let’s look at some common error messages.

Date field

Europeans and Americans have different date formats, but your users are from all over the world. Someone will always be on automatic pilot and use the format they are used to.

The example on the left (adapted from a real site) has some sort of humour and makes the point, but the message could be interpreted as “you’re dumb”. The example on the right is simple but still conversational.

Password field

First off, many mobile apps have only one field without the need to confirm (you need a good forgot password functionality). But say you are aiming at the PC users and do ask them to confirm the password (and the user doesn’t see plain text - only asterisks), then you could leave it at “The passwords are not identical” (as sites usually do), or provide a hint to a common mistake people make. In fact it might be better to include it in the explanation above the field.

Here the user used only 6 characters. I know that you told them they need to use 7 up-front, but make it clear. This also covers the case if not enough numerals or letters were used even though the length is okay.

Email address field

In this password recovery example, the user has entered an email address that is not recognised by the system. Be helpful – offer them some options, such as maybe they used another email address when they signed up, or maybe they never registered and can sign up now using that email. By the way, this of course also works when a user tries to sign in with the wrong email address.

And if the worst happens and the process can’t continue, tell your user about the problem Give them some idea of how they can correct it, and if all else fails, tell them who to turn to.

This is from a site I often quote, because it is so good - www.claires.co.uk. They tell you what you should check, provide an alternative action, and if all else fails provide the phone number of customer service and an email link, making it clear that they’re always happy to help you.

I create microcopy for English-language apps and websites.

Let me help you create that perfect app.

Recent Posts
    Archive