Handling User Error with Care: Getting Users Back on Track

Dealing with user errors is a hidden source of friction. UX consultant John Hyde discusses best practice including a financial website that boosted conversions by 17% with these guidelines.

Designers talk about the “happy path” through a website: a series of interactions where smiling users enter correct and complete data and press the right buttons in the right order.

The first time I measured the happiness generated by a happy path I was surprised. My programmer logged details of a simple lead-generation form:

  • 31% made an error on their first go
  • 7 of these got back on track
  • 24 left the website without converting—some after many attempts

This means that 24% of the people who tried to convert were let down by how the website dealt with their mistakes.

What is best practice for dealing with user errors ?

  1. Make it clear that something is wrong.
  2. Show the user which field (or fields) are wrong in form errors.
  3. Display error messages that help users get back on track.
  4. Save what the user has entered—both good and bad so they do not have to repeat data entry.

This mortgage site shows the way. Red and Yellow are now standard colors for showing errors. From 6 feet away you can clearly see that there is an error and where it is.


Red text under the bad fields is a good example to follow.


This shoe website has another good way to show error messages. The message is right there with the problem.

Inline validation and error messages


Inline validation is when the site validates a field when the user leaves the field and before pressing the ‘submit‘ button. In other words, a user knows if the data entered is acceptable instantaneously. This technique is very good for fields like User Names where the site visitor wants to know right away if a selected username is taken or still available (rather than submitting the form several times looking for the right username).

Inline validation is well covered by Yahoo’s Luke Wroblewski on A List Apart.

But there are some problems with inline validation:

  • Inline validation can be expensive in programming effort—you still need server side validation as well.
  • Big libraries can make pages slow to load which can hurt conversion rates.

If you have the budget (or you’re a savvy developer) then try inline validation—but do an A/B split test to see if it’s helping or hurting. I’ve had mixed results with inline validation even for just simple checks like mandatory fields.

How to word your error messages

For an existing site ‘mixing with your customers‘ will get you a long way. Get your programmer to log user errors in forms, including the bad data they have entered. You will find:

  • A small number of problem fields. Sometimes it may just be one problem field.
  • Errors follow patterns

Each common error pattern needs its own custom error message. I’ll say that again: each common error pattern needs its own custom error message. Doing this is low-cost and you will get very insightful information that can drastically improve results.

For a brand new website, previous experience will help you to guess the kinds of errors that users will make. After going live you must revisit this and see if there are new kinds of errors.


The custom error message should be:

  • Tactful and blame-free – ‘Oops’ is good
  • Clear about just what is wrong
  • Helping the user to get it right

This power company gets it right—very clear where to get the correct customer number:


Let’s look at the email address: this is often a problem field. Here is how NOT to do it:


We can all see what is wrong – but the site dumps a big list of everything that could be wrong
How about “Your email address needs an ‘@’ sign“.

Other errors will need custom messages:

  bob.green@superduper    =>  "Email address is incomplete - check the ending"
  bob./green@superduper.com => "Email address has an unusual character ( / )"  

Do this with the common errors and only then use a “one size” error message for the oddballs.

This is another reason for not using ‘expression matching’ for validating fields. The user input will only ever pass or fail the test and you then have no idea why it failed so you are stuck with dumping a manual page on the user. A more targeted message could nudge her back on to the happy path.

Empty fields

A common error is when a mandatory field is empty. This is often an email field or a phone number field. The site visitor has not forgotten this field, they are often reluctant to share this personal information and wants to try and move forward anonymously. Having no data is different from invalid data and it needs a different error message.

My tip in this scenario is to explain why the information is going to help the user:

  • “We need a phone number in case our driver is running late”
  • “Enter your email address so we can help if you forget your password”
  • “Enter your postcode to help fast delivery of your order”

Results up by 17%

The financial services website followed these guidelines. The before numbers were:

  • 100 submitters
  • 31 first-time errors
  • 7 recovered
  • 24 didn’t recover

Before: 76% success rate (= 100% – 24%)
After: 89% success rate. By following these guidelines, inquiries are up by 17%.

The key part of getting the user back on the happy path was specific and helpful error messages.

Further Reading:

About the Author

John Hyde

John Hyde works closely with clients to get better results. He uses analytics, A/B split testing, and usability to improve - and improve again. Check his own about Site Doublers page.


  • Paul Olyslager Reply

    Inline validation can only work if the problem at hand gets the focus. Imagine you have a long form to fill in (you even need to scroll) and submit without your postal code… the focus needs to be on the postal code textfield. It happens too much that the page refreshes (going back to the top) after submitting, not knowing where it went wrong.

  • Rose Matthews Reply

    But you haven’t taken it far enough… all the above are commonsense principles which should absolutely be applied as a minimum. They’re caretaking. What do you do to break from the norm and provide a REALLY good user experience?

  • Dave Sparks Reply

    A good work through the basics. Inline validation needs to work well and quickly. Personally I’ve sometimes skipped past some validation that took ages without noticing and carried on down the form.

  • Jeffrey Barke Reply

    While this is a useful introduction to handling user-based data entry errors, why don’t you apply any of these principles to your own comment form?

    If you submit a comment with empty required fields, you end up on an page that only has the following content: “Error: please fill the required fields (name, email).” Seems like kind of a FAIL to me.

    • Matthew Kammerer Reply

      Great suggestion. Even though this is a guest post we can still model our own site after this. Thanks for pointing it out :).

    • Andrew Maier Reply

      Jeff, thanks for pointing that out. I’ve actually thought for a while now that the default WordPress error behavior was disorienting at best. I’ll make sure to add this to the list of bugs we’ll be addressing over the next couple of weeks. Thanks for reading!

  • Henk Wijnholds Reply

    Hi John, There can’t be written enough about these kind of best practices, so good stuff.

    For those who want to read indepth about this I suggest: ‘Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points’ by Matthew Linderman and Jason Fried.

    In this article you write about the ‘ability’ for people to fill the form. A great follow-up would be the ‘motivation’ side because I think this axis sometimes can have a much larger impact.

  • John Hyde Reply

    Thanks for the comments.

    Henk is on the money: if people are not motivated to submit the form then it doesn’t matter how good or bad the form is – because they will never find out.

    The secret is for the other elements of the site – words, pictures, colours, layout, interactive bits – to motivate and re-assure ths visitor. Then if the form works well the visitor will convert.

  • Brian Lang Reply

    You have to remember to take into account color blind users and not rely solely on color as indicators for fields with errors. Go ahead and use color, but make sure you use an icon that indicates the field is bad as well.

  • minorthreat Reply

    Color blindness isn’t really going to be a factor, considering it’s an inability to perceive differences *between some colors*, like green and brown or brown and red. This usually only applies to certain shades as well. Using a different color to show something has changed would only be a problem if you change the shade.

Leave a Comment on This Article