Conversion tip: Don’t let bad error messages cost you sales

Writing error messages is not sexy. In fact, it’s incredibly tedious and boring. But don’t confuse tedious and boring with unimportant. Often, the quality of an error message can be the difference between a sale and an abandonment. And a poorly written error message is a needless and shameful way to lose a sale. The good news is that improving error messages has a high ROI as the cost of the investment is very low.

It’s important to remember that our sites are really self service software applications, and they’re very likely not as intuitive as we think they are. Referencing back to one of my previous posts, “Is elitism the source of poor usability,” we have to remember that our customers probably aren’t as tech savvy as we are, and they are definitely not anywhere near as familiar with our sites as we are. So, it’s important that we’re very clear in our messaging when something goes wrong.

So what does it take to write a quality error message?

  1. Be specific
    It’s so important that we tell our customers exactly what went wrong. Our developers have to write code for every possible instance, but all too often we resort to generic and vague language in our error messages. Here are a couple of examples:

    As a customer, I’m not sure what I’m not sure what happened or what I should do about it. I might try once again, but if I got this message a second time I would be gone.

    This either/or scenario is really an example of a lazy error message. Which is it? Is the address improperly formatted or does it contain invalid characters? We need to tell customers specifically what is wrong and tell them how to fix it.

    Here’s a much better example:

  2. Use clear language
    It’s very important to avoid anything that even remotely resembles tech jargon. Try instead to use short words that are part of everyday language.First, a bad example:

    Huh? Customers understand “password” but “authentication credentials” are certainly unclear and sound kind of scary, frankly.This one is much better:

    This is both specific and written in clear and simple language.

  3. Strong visibility
    Error messages need to be extremely prominent. Use color and other symbols, such as exclamation points, to help the error message stand out. It’s also helpful to separate the error messages from the rest of the page with white space. Include the message prominently at the top of the page and also at the specific field, if it’s a form error.Here’s a good top of page error:

    I would like to see more white space around the error message, but otherwise this is really good.And I really like this way to highlight a particular field where the error has occurred. It may not be pretty, but then it probably shouldn’t be. It should stand out, and this does. Even better, we get a very specific message telling us exactly what’s wrong with the field.

  4. Be polite
    Whenever an error occurs during our customer’s experience with our site, we’re in danger of losing her if we don’t handle it well. So, let’s be as courteous as possible. The cost of courtesy is zero, and it allows us to come across as friendly as possible.Here’s one that is both specific and polite:

    Here’s one that goes the extra mile to suggest calling Customer Service if there is still a problem. This is a very nice touch that will go a long way towards saving the sale.

  5. Provide examples for how the information should be entered correctly
    It’s very important they we’re not only specific in defining the problem that occurred but also specific in explaining how to correct the problem. If the customer has entered his email incorrectly, we cannot assume that he knows what he did wrong or how to enter it correctly.Here’s an error message that explains the format pretty well:

    However, the customer may not understand what “domain” means. It may be be better to also use a real example with a well-known domain like “” Even better, incorporate the information the customer entered, if possible.For example, the error might say something like:

    You entered “kevin” for your email address, which is not a complete address. Please enter an “@” symbol followed by an email provider after your email name. For example, “”

Even better, be proactive. Stop the error before it occurs.

I really love how handles their form fields. Upon entry to a form field, a dialogue box dynamically appears next to the field with some helpful information. The movement that occurs upon entry really draws your attention to the helpful information, which I find considerably more effective than help text persistently present under or next to a field. It’s far easier to ignore static text than something that appears when you enter the field.

Additionally, the folks at have included some great help text that provides important information. In this example, they’re letting us know the address must match the billing address on our credit card. Excellent!

And here, we get some specific information about the value of our password and the basic requirements for the password. And we get some nice politeness to close it out.

Save those sales. Give error messaging your full attention.

Error messages should get just as much attention as any other site functionality in the requirements processes for our sites. We should give error messaging as much attention as we give to marketing copy. It may not be sexy, but it’s critically important if we want to avoid needlessly losing sales.

What do you think? How much time to you put into error messaging? Do you have examples of particularly good error messaging? Would you add anything to the list of quality error message attributes?


  • By eCommerceCircle, October 20, 2009 @ 3:23 pm

    This post reminds me of all the ‘Errord’ posts on The Daily WTF?! —
    Good post.

  • By Scott Silverman,, October 20, 2009 @ 3:24 pm

    This post reminds me of our friend Alan Rimm-Kaufman. At a workshop many years ago, I remember him poking fun at big bold 404 error messages on Web pages. He commented that if someone in your store looked in the wrong place for a sweater, you wouldn’t yell ERROR at them.

  • By LC in SB, October 20, 2009 @ 4:47 pm

    I wish my bank would read this article, then I might actually enjoy online banking.

  • By Abigail Plumb-Larrick, October 20, 2009 @ 8:32 pm

    As a user interface designer, I write a lot of error messages. Ideally, each error message is pleasant, clear and actionable — although in practice, it’s not always possible to get all three characteristics in there. For example, if the user has entered 1-212-GOT-MILK as a phone number, a great error message might be “Please enter numbers only.” An OK error message would be “Please enter a valid phone number.” A really lousy error message would be “Phone number invalid”.
    While we design useful error messages, however, we also need to be focusing on eliminating the conditions that allow errors to occur. For example, rather than setting up error validation around typed-in dates (11/23/09? 23/11/09?), use a calendar picker, so users have to choose a recognizable date. For US or Canada phone numbers, accept 10 digits or 1+10 digits, with all characters stripped out, so users don’t have to worry about whether (212) or 212- is correct.
    Just two more ways to get out of your customer’s way!

  • By Jason Stewart, October 21, 2009 @ 9:42 am

    Great post Kevin. As a usability auditor I am often exposed to the darkest corners of web applications and thus see some of the strangest and least helpful errors in existance (some of which you pointed out above)! Great to see a call out to developers to provide more helpful and meaningful error messages, or just to avoid those situations all together.
    I do have to say, however, that I disagree to some degree with your first point about the specificity of certain types of error messages, especially those relating to the entry of sensitive information. If I were someone with less than honest intentions, these very specific error messages could really just help me guess someone’s personal information (passwords especially). The Best Practice you mention in that first point is, I think, actually too informative, especially if I were someone who is somewhat familiar with the person into whose account I’m trying to breakin. “Ah yes, the password I’ve tried has too many letters… must not be Joe’s regular password of MountaintopsAregreat!1234, but maybe the name of his first kid, or that strange word he has taped under his keyboard”.
    I think Google’s approach to login error messaging is a good one: “The username or password you entered is incorrect”. Or Facebook’s: “Incorrect Email/Password Combination”. These give you just enough information to know where you need to focus your re-entry efforts, but not enough for those with less than good intentions to start narrowing down the possibilities. Would you agree?

  • By Kevin Ertell, October 22, 2009 @ 8:24 am

    Wow! I wasn’t aware of this site, but I’m adding it to my bookmarks. There’s some pretty funny stuff in there, but also lots of good examples of how silly we can look if we’re not careful. Thanks for the link.

  • By Kevin Ertell, October 22, 2009 @ 8:28 am

    Thanks for your comment, Scott. I think I remember that comparison from Alan. There’s nothing like making using an in-store metaphor to point out the absurdity of some of the things we do on our sites sometimes. Alan was really amazing, and one of the best user experience people I’ve ever known.

  • By Kevin Ertell, October 22, 2009 @ 8:28 am

    Thanks LC. Feel free to send them the link to this post! πŸ™‚

  • By Kevin Ertell, October 22, 2009 @ 8:30 am

    Thanks for your comments, Abigail. I really appreciate you making the points about the calendar picker and the character stripping. Those are great examples of how to be proactive in preventing errors in the first place, which is definitely the best path to take. Thanks again.

  • By Kevin Ertell, October 22, 2009 @ 8:39 am

    Thanks for your comment, Jason. You make an excellent point about specificity in context. The example I used about a password containing an incorrect number of characters actually came after CREATING a password as opposed to entering a password to log in. I completely agree with you that we should not provide any hints about the problem with a password when it has been incorrectly entered during a log in process. However, I’m still of the opinion that we should be telling people the minimum requirements necessary for creating a password with as much specificity as possible. Otherwise, we can really get customer caught in a frustrating loop trying to enter a password that works. Perhaps the site in the above example could improve their security by setting minimum standards for their passwords but not maximum. What are your thoughts?

  • By Eoin Γ“ Riain, October 22, 2009 @ 11:51 am

    A thing that really annoys me is non-recognition of accents or spaces in names. My name is has an accented upper case “O” (Γ“)followed by a space and lots of sites either say rude and sometimes indecipheral things about it. I imagine that people with apostrophies may have the same problem, (and God help those who have umlauts or other un-English symbols in their names. Or sometimes (especially Air Lines) they mutalate the name so that on occasion the security staff have difficulty in reconciling the ticket with my passport.

  • By Kevin Ertell, October 22, 2009 @ 3:38 pm

    Thanks for your comment, Eoin, and excellent point about accented characters. I’m really glad the accent on your name showed up correctly on my blog! πŸ™‚
    I appreciate you bringing the point up, because we Americans can sometimes forget it’s the WORLD WIDE web and languages and character sets other than those from traditional American English are perfectly valid.

  • By Jason Stewart, October 23, 2009 @ 1:22 pm

    Completely agree with your clarifying point Kevin!

Other Links to this Post

  1. My Favorite Sites of the Year | Retail: Shaken Not Stirred — January 6, 2010 @ 8:03 pm

  2. Don’t Spook The Customers: Halloween’s a good time for a user interface review : Segment Target Personalize — January 8, 2010 @ 1:18 pm

  3. Booking engine update January 2010 « Hurtigruten Web team Blog — January 22, 2010 @ 9:38 am

RSS feed for comments on this post. TrackBack URI

Leave a comment

Retail: Shaken Not Stirred by Kevin Ertell

Home | About