UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 794 February 29, 2012

Are You Saying “No” When You Could Be Saying “Yes” in Your Web Forms?

Error messages seem like an unimportant and incredibly boring part of crafting a user experience. But the tonality of error messages can swing the experience around from an almost certain abandonment to a conversion.

Some years ago, while checking in at the airport in Stockholm on my way to the U.S., I asked the woman at the counter if it would be possible to get an upgrade to business class. Her response: “I’m sorry, but that’s not possible. You would have to pay extra for that.” Checking in for the return flight, I tried the same thing again, but this time the answer was: “Of course, sir! How would you like to pay for that?”

So even though the seat availability and possibility for an upgrade was the same, I got two completely different answers: one “yes” and one “no.”

The reason this happened is partly due to the general American “yes we can” attitude and sales-oriented business culture. I’m also pretty certain that it didn’t happen by chance. Airlines put great effort into training their staffs to give customers positive service experiences. Part of this training is dedicated to the handling of exceptions—what happens if the customer asks for this, complains about that, refuses to do this, etc.

As a result, over the past few decades, airlines and other large service-oriented organizations have accumulated a huge body of knowledge dedicated to handling customer service exceptions. But then these organizations shifted more and more of their services to digital touchpoints, and all this customer service knowledge went into the trash bin.

Instead of ensuring the transition of great customer experiences from the physical world into digital interfaces, the service pros left it to the IT people to figure out. And those IT people seemed to have spent 99% of their effort on what happens when everything goes as planned. Some intern was given the task of writing error messages in the unlikely event that something would go wrong.

Let’s look at some examples:

If I forget to fill out the departure date field when booking a trip on BA.com, I get this:

Error Message

If I try to log into FedEx.com without providing a username, it tells me:

Error Message

And when I go to Merrill Lynch’s website, I get this message when I arrive:

Error Message

The commonality among these three examples is they start with a very negative word: “Error,” “Incorrect,” and “Incompatible”. This is the equivalent of the “no” I got from the Swedish airline agent when I asked her about upgrading. It’s basically a slap to the user’s face.

How to Write Error Messages that Say “Yes!”

Writing error messages that carry a positive tone isn’t rocket science. Just follow a few simple rules:

  1. First, get rid of tech lingo such as “incompatible.” Most users won’t know what this means. Speak to them in their own language and not the language of your developers. For example, “incompatible” translates to “does not work together” in plain English.
  2. Don’t use negative words like the ones I’ve pointed out.
  3. Clearly identify the error so the user knows what to correct.
  4. Give the user a hint of how the problem can be solved.
  5. Put the blame on yourself, not on the user.

The examples earlier in this article each break most of these rules.

For example, both BA and FedEx failed to accurately tell me what went wrong. They told me that the format and data that I entered was incorrect, but the real problem was that I didn’t enter any data.

Budget.com, on the other hand, does a great job with error messages. I entered “Londdon” as my pickup location and got this error message:

Error Message

First they told me what I did wrong: “You entered Londdon…” Then they put the blame on themselves: “We are not sure what location you are searching for…” Finally, they gave me a list of ideas for what I could try instead.

What BA, FedEx and Merrill Lynch Should Have Done

Now that you’re armed with some new ideas, let’s try rewriting the bad error messages.

BA

“Oops, you didn’t enter a departure date. Please use the calendar to select a date for your departure flight.”

Note: If you want to live by rule #5 (take the blame), then a something like “We couldn't figure out the departure date” would be better than “you didn’t enter a departure date,” but in this case it would be misleading and give the user the idea they actually did input something. In this case I would prefer giving an accurate error description over taking the blame.

FedEx

“Oops, you didn’t enter a username. Please fill in your username, or click here if you’ve forgotten your username.”

Merrill Lynch

“Our site works best with browsers other than the one you’re using. You can download a different web browser here. You can continue using this browser, but be aware that some features might not be available. We apologize for this inconvenience.”

Use a Customer Service Number as a Final Point of Recovery

When we reviewed the error messages of one of my clients, we found there were some errors that could not be recovered from online. The user would have to get in contact with the call center to find a way out.

Most of the messages for these errors made no mention of that. Some did, but the reference to customer service was general and vague: “Please contact our customer service,” for example.

The revised messages we develop had a call-to-action and the call center telephone number explicitly stated in the message: “Sorry, but we’re unable complete this request. Please call 1-800-XXXXXX immediately and we will do our very best to help you.”

Getting Great Error Messages In Place

I believe the shortcomings in this area are largely an effect of the “Digital Divide” between sales/marketing and IT. Sales and marketing have no insight into how, when, or where these messages occur. IT doesn’t understand the importance of shaping them correctly.

So in order to get it straight, sales and marketing must start taking an interest in the issue. A good starting point is for them to “take their own medicine.” I usually tell all my clients to fill out all their own forms on a regular basis with all kinds of stupid inputs just to see what happens. Put yourself in the shoes of your visitor and ask, “Would this seem friendly and relevant to me at this point?”

As well, IT must let sales and marketing into the game and understand that they can have very valuable input into crafting a positive customer experience.

So get together, and get on the road to giving your users positive and useful messages when something goes wrong. Because things do go wrong, no matter how hard you and your users try.

ABOUT THE AUTHOR(S)

User Profile

John Ekman is the founder and CEO of Conversionista! He is regarded as a Swedish authority on Conversion Rate Optimization. According to John, a Conversionista is someone deeply and crazily passionate about improving Conversion Rates. John has a long history in the optimization of online businesses going back to 1996. John will be presenting a session on “What Have E-tailers Learned from Retailers? Absolutely Nothing!” at Conversion Conference West 2012, March 5-6, in San Francisco, California.

Add new comment

Comments

24
28

Do not use "oops" in error messages, that sounds stupid.

67
66

How ridiculous and insulting! "First, get rid of tech lingo such as “incompatible.” Most users won’t know what this means. Speak to them in their own language and not the language of your developers." This is in no way 'lingo' it's an everyday word in the English language. If a user doesn't know what incompatible means then should I also be leaving out words like "inconvenience" and "departure"? Maybe instead of departure we could say "when plane go up-up!!". Your suggestion of “does not work together” is the way you would speak to a child.

70
76

The irony is that if you try to submit a comment on this article without supplying your email address, the error is: "The e-mail address you specified is not valid."

70
89

Great article and I would love to see such a fundamental change. However, if you still leave the error text up to the tech guys, you will end up with something like, "I'm sorry. This must be my fault for assuming you had a better than 3rd grade education. Let me spell this s--- out to you."

53
77

it's rare to find articles pointing out the importance of tone of voice in user interface texts for creating good user experiences, so thank you for that.

it would've been a better article if you had bothered to find out how, when and by whom user interface texts are written. you would've then avoided publicizing your total ignorance and naive advice.

78
79

Good advice but few things are debatable. With current short attention span, lot of time red "Error" with the field highlighted works better! I agree to be more humane and positive in approach, but then again it is cultural thing. Lot of comments/arguments that may be offensive in US, may be just perfect elsewhere!

77
73

“Oops, you didn’t enter a username. Please fill in your username, or click here if you’ve forgotten your username.”

It is not good UX to say 'click here.'

69
74

Great contribution to the ongoing campaign to get our clients to understand that forms aren't just about data - they are about the conversation you're having with your customers, and the relationship within which that conversation takes place.

One small nitpick: I've found that saying 'oops' to people in error messages doesn't go down well with them, especially if it's really 'oops, we forgot you don't live in the our country so we wouldn't let you enter your actual address' or 'oops, we asked an impertinent question' or 'oops, we didn't realise that some names have apostrophes in them'.

74
72

A compelling argument. However one thing you ignores, most users don't read the error messages. Especially if they long. Full sentences for an error message will Never be read.

The best approach is to avoid the possibly of an error occurring, either by limiting choices (if you pick a date from a calendar then it can't be invalid) or making an educated guess based on the input (90% of people who typed Londdon meant London).

It is important for the UX people to be aware of error messages. You are right that it usually is an afterthought that the software devs end up taking care of.

65
79

Excellent article. Handling errors in the right way is an important aspect from usability. And still it's not always easy. Your article tells us how to accomplish that successfully. You made a good point that sales and marketing must start taking an interest in the issue. There goes always something wrong, so better be prepared and provide good and friendly error message.

71
65

Great article!

Over the years of creating UIs I've always struggled to find a perfect way to handle errors. I think this article lays down a good framework for how to accomplish it.

As a designer or developer, being friendly in your error messages isn't too hard.

However, as a developer, being clear isn't always as easy as it sounds. Sometimes from the programming perspective it can be hard or just tedious to programatically predict what the cause of an error would be at the point in code that the data is invalid. Sometimes trying to be clever can actually result in being inaccurate, if you word an error at some point assuming cause A, failing to predict cause B will result in the same error. Failing to predict an error path happens a lot in the programming process, so I think in general programmers get in the habit of simply stating the invalid state, and not try to guess the cause.

That said, there's still plenty of situations where simply wording the problem more clearly is not hard and a great tip.

One other thing, though, is the display of negativity vs positivity: users are used to negative feedback when their input is incompatible and it will draw them to the error quickly and clearly. Wording an error too positively might actually give the user the impression it's not required, ie an opt-in pitch or something. The more a user has to think in some situations, the more they can be pushed away. So I do think there is a balance between being friendly in your errors, and clearly displaying that there is an error that must be corrected by the user in order to progress, and how to correct it.