10 Tips on Writing Hero-worthy Error Messages

“Doh! %&^%&^%&!”

Another forehead-smack-worthy curse-laden moment: I’ve filled out a lengthy online form and hit the submit button only to find myself staring back at an empty form peppered with red errors. Has this happened to you? Of course it has.

While considering how much I really need to complete this form, I start making notes on how I’d design it to be a better experience. Seriously, how many date formats am I going to have to try before I get this sucker right? Do I need to phone a friend?

The lack of strong error messaging is a regular issue I encounter as both a user and UX designer. As the bearer of bad news to users, error messaging can be the element that determines whether your app gets a “Sale” or “FAIL.”

Editor’s Note: We’ll be covering UX tips and strategies at The Future of Web Design NYC on Nov 16th – 17th.

1. Error messaging is customer support

Error messaging is a critical component of customer support. Customer support teams are experts at talking to and coaching users towards conversion and success.

While QA hustles to break it down, customer support can work side-by-side to craft sensible messaging around those scenarios. The result? More sales, fewer customer calls and complaints.

Some mistakes (e.g. date formats, passwords, emails, forgotten fields) are both predictable and recurring mistakes that cannot be prevented by better design. Design the outcome to encourage the user to engage with the app’s voice, correct her mistakes, and move onwards.

2. No one ever died of humility

While it can be tempting to assume that the user is at fault when an error is made, it’s also possible that the process wasn’t clear enough in the first place.

Error messaging should be concise, friendly, and knowledgeable, but also employ humility, empathy, and apology. I personally love Firefox’s “well this is embarrassing” statement. I tend to crash my OS frequently, and it’s not FF’s fault, yet every time FF makes the assumption that I’m not at fault.

Error message in Firefox

3. Bake with cookies!

Among the most unforgiving experiences occurs when a user fills out a form and having all her data it wiped out for having forgotten or mis-typed field. If you’re not a banking institution you don’t have the luxury of abusing your user by dumping her data.

Save as much information as is possible and safe for your user (e.g. re-fill everything possible with exceptions for passwords, TOS, etc.), and then clearly mark the areas your users need to correct. Saving user data will reduce user annoyance and the chances that she’ll abandon the process.

4. Don’t cheap out

Don’t cheap out on design when it comes to error messaging. Users who hit error messages are helping your team learn how to optimize your product.

Do use this as an opportunity to build a relationship and engage with humor. You can soften the feeling with typeface and words that don’t alarm, humiliate, or annoy.

Do use resourceful and helpful iconography to reduce the amount of words.

5. Error messages are not features

As great as your app’s error messages may be, they aren’t supposed to become legacy features.

Assign a team member to study the error logs. Learn what happens when your users make mistakes and constantly optimize.

  • What fields were incorrectly filled out?
  • What did the users put in those fields or forget to put in those fields?
  • How many sessions do your users log?
  • What’s the abandonment rate?

Error messaging can be the simple tweak that influences your bottom line (conversion), so it’s worth ongoing evaluation and investment.

6. Everyone loves the funny guy

It’s easy to hide behind a great sense of humor, but it’s also easy to distract your user. Use low-key and relative humor like icanhazcheeseburger.com that doesn’t overshadow the error messaging itself.

icanhazcheezburger Error Message

7. Choose helpful over cute

Error messaging should be more helpful than cute. CushyCMS’s “Wharrgarbl” was only amusing and forgivable the first time I saw it, by the third time I was annoyed and still couldn’t figure out what the source of the problem was.

Unhelpful error messaging in cushycms

8. Go behind the browser

If you are low on resources or without customer support, integrate your error messaging within the user’s browser. This will force the user to stop and read what she’s doing incorrectly. Oddly, I’ve seen users mutter and blame the browser versus themselves or the app.

error messaging in eventbrite

9. Don’t play hide-and-seek

Bring your user directly the area where the problem is. Meetup.com has fantastic messaging, but unfortunately during the sales process, they bring the user back to the top of the page, when the error is well below the fold. This causes the user to pause and think versus correcting and moving forward.

error messaging in meetup.com

10. Don’t design single-size error messaging

One size error messaging is a bad idea. If a user has failed to put a size or choose a color of a purchase she wants to make on zappos.com, the error message should point out that specific issue versus being popped into the “Item Out of Stock” skin used elsewhere across the site (@zappos – please fix!).

error messaging on zappos.com

Error messaging occurs when a user makes a mistake (dumb user) and it’s an element of your app’s design that can keep the party going or literally result in a lost sale.

If there were one thing I’d like you to take away from this article it would be that you go back to your team and talk about and revise your error messaging, and then let me know what the results are. My prediction is that writing hero-worthy error messages will result in improvement and lift across your sign-up, sales, and data gathering processes.

Free Workshops

Watch one of our expert, full-length teaching videos. Choose from HTML, CSS or WordPress.

Start Learning

Treehouse

Our mission is to bring affordable Technology education to people everywhere, in order to help them achieve their dreams and change the world.

Comments

35 comments on “10 Tips on Writing Hero-worthy Error Messages

  1. Some great points, especially number 3 – the worst offenders of cookie negligence are forms with CAPTCHAs that make you fill out a new one every time they get reloaded because your username wasn’t available.

    btw, 2809 unread emails? How do you sleep at night?!

    • Simon,

      If I said those unread messages were all from my mom would you believe me?

      :)CB

  2. Nice article, although I don’t quite understand what you mean with #8

    If you’re suggesting using pop-up alert boxes to display errors, I disagree. Apart from the annoyance of having to click ‘OK’ to make the message go away, once you’ve done this it’s easy to forget what the message said, and then you can’t go back and read it. So it could cause accessibility problems for users with short-term memory issues (or anyone whose phone rings at the wrong moment.

    Make your error messages obvious and helpful, and you won’t need to annoy your users with alert boxes.

    • Hey Joel,

      Really good point. I am often annoyed by anything that pops out of a page. In this case though, I’m really recommending that if you don’t have a customer support team or the bandwidth to craft unique messaging that you leverage the browser for simple (sometimes soulless) messaging.

      Using the browser’s alert boxes 1.) makes it look like it’s coming from the browser v. your app (this is good) 2.) prevents the user from moving forward or looking around without a clue. It’s familiar messaging she’s already used to seeing.

      Cheers!
      CB

      • Hmmm, I’m still not sold on this…

        > “if you don’t have a customer support team or the bandwidth to craft unique messaging”

        Or if you’re too lazy to build a website properly, perhaps ;-)

        If you have a script which checks input on the client-side anyway (to make an alert box pop up) it hardly takes any more bandwidth to make your script insert the error message on the page as HTML instead. And if you’re not going to craft unique messages, surely you’re contradicting points #1, #2 and #9 in this article?

        > “2.) prevents the user from moving forward or looking around without a clue”

        It’s easy enough to prevent the user moving forward without alert boxes. Just use JavaScript to interrupt the form before it gets submitted, and add the error message to the page instead of triggering an alert. And if your error message is designed properly, there should be no chance of the user “looking around without a clue”

        The other 9 points in this article are great tips for building professional forms to give your users a helpful, professional experience; I’d argue that pop-up alert boxes do the opposite of this, and make your website feel like it’s 1998 all over again.

    • Hey Joel,

      I think you’ve made all great counterpoints here:) I’ve worked on sites with small budgets, huge goals, and tech teams spread impressively thin (e.g. huffingtonpost.com in early 2008).

      I wouldn’t say we were “lazy” by integrating error messaging into the browser. Rather, we made some tough, but strategic decisions to do so. Is it the ideal? Nope. It was a way to create a site standard and keep track of lots of moving pieces and goals for various stakeholders.

      In a perfect world things might have been different . . . But, your points are well-made. Eventbrite has great newsletters and “how tos,” so I’d prefer to see them come out from behind the browser myself.

      Thanks Joel:)

  3. You sure know what you’re talking about.
    Well written article,alhough I don’t follow for the full 100% on all points.
    But that’s what makes it interesting.

    • Kurt,

      I think Joel (from above) made great counterpoints:) I think the most important lesson for me in thinking through error messaging is that it really is an often overlooked area of customer support that can move the needle quickly and significantly on your app’s bottom line.

      That said, this is not a definitive guide or list, so I’d love you to add some of your thoughts, so I can keep thinking this through too.

      In other news I couldn’t tweet this today, because my account was spammed last week and so now I get Twitter’s error message, “We’ve temporarily locked your account because of too many failed attempts to sign in. Please chilax for a few, then try again.”

      Cheers!
      CB

  4. Great article, and some really useful insights.

    I thought about point 9 in particular. Seems to me to be a holdover from the common rule of thumb that *form* errors should be at the top of the form. Even that’s not entirely true, but when you’re dragged back up to the top of a page so that you can’t even see the context of the error, that’s even more annoying.

    Strikes me that the effort was to make the error message easily and neatly incorporate with their existing styling (which it does), rather than realising that the point of the error message was to help the user.

  5. Although it doesn’t seem it, error messages are actually very important and a crucial part of web development. Making sure the end user realizes an error happened and offering them steps with how to correct it is key.

  6. sjkl kl qdflk jkqlskdf lkqjdjfs kl lkj qsdfkl klq jsdflk lklj qsdf
    qsdflk lk lkq jflk lkq sdfdlk lqk qlk lk lklk lk llkqdsflk lkqs dflks k lkq dsflk f

    qlkfk qslfkj zerpokljs dqfjlep q lqdskfjljopaezrlkjqdfj lqlfl qksjdfoiare lj kl qll qlkj lkqsdfjlk lkq lkqsj qslkjlk qlkqsfj qsdl

    qs

  7. Excellent article. Customised and clear error msgs are a very significant detail in ensuring that whole immersive experience of viewing a website. Hmm…one could say they are like ‘drop-shadows’ – when used cleverly, it really adds to the dynamism of the website in question.

  8. A new way of showing error messages I’m experimenting with is through asking the wrong fields again on an other page.
    For example; If your customer should fill in his address and forgot his zip code you ask on the next page to fill in the zip code, with an elegant error message. This points out to the user what’s wrong. Also the data filled in in the huge form isn’t lost. I really hate it when you have to scroll down a form again to find that one and only field you forgot to fill in. If you’d show only the wrong field(s) on a next page the user also understands you can’t go on without filling all the stuff in.

    • That’s a pretty cool idea Robert and I have seen it on a couple of other sites. One thing to be wary of though is that you must have a ‘back’ button to allow the user to make changes if they still want to.

      For example – if you accidentally put your (non mandatory) telephone number in the zip code box and submit, when you arrive on the secondary page you are presented with the zip code box with your telephone number in it and are asked to change to a valid input. It is then the realisation sinks in that you maight have totally screwed the form up (but still enterede valid data values) – you search for the back button and it isn’t there…

  9. A good article. I favour capturing the errors server side, returning to the page anchored at the error messages and offering the message at that point. This helps overcome some accessibility issues for devices that still don’t support javascript fully.

    I particularly like Robert van Hoesel’s idea of filtering the errors out on large forms, rather than having the user skip through the form to locate the errors – however I may worry about the missing fields not being presented in context, especially if they are similarly labelled.

    Sometimes reading the the form where you have made one mistake – can allow you a second chance to correct something that has been misspelled elsewhere (especially if you have a habit of quickly typing in your address etc..)

  10. What about writing all the errors at the top of the page with a link “Click here to fix this issue?”. Is it user friendly?

  11. Excellent post! I’m currently looking at ways to improve functionality/ease-of-use for web applications that we give to customers. Sometimes, these end up being used by the general public and I felt like the old, “Oops! You broke it. We’ll take a look and try to fix it.” messages weren’t really doing much good.

    Taking a look at the error reports, a lot of times they are just from the user spamming the refresh button hoping their square peg would go in the round hole. Hopefully we’ll be able to show them the square hole or the round peg, depending on the situation.