Forms that work: Designing web forms for usability

How should I handle errors in online forms?

Caroline's answer

First of all: why is there an error in the first place? Here are some possible reasons:

  • Typing errors. People sometimes hit the wrong key. Unless the person has a real typing problem, these errors are likely to be confined to the occasional field on the form.
  • Transcription errors. These happen when a person is copying information from one place to another, for example reading a number from a credit card and typing it on-screen. Transcription errors are frequently swaps (the user types 4311 instead of 3411)
  • Category errors. These happen when the categories you offer do not match the answer that the user wants to give you. For example, a USA site may insist that I enter the "state" as part of my address (I don't live in a USA state) or insists that you enter a USA state rather than an Australian one. Category errors can also be out-of-range. For example, a user might truly want to purchase 1,000 of an item where you're only expecting to sell 10 units at a time.
  • Send errors. These happen when the person presses the 'send' or 'submit' button either deliberately or inadvertently when only part-way through the form. Your server gets a page with many blank entries.
  • Privacy errors. These happen when the person considers that the question you have asked is inappropriate in context. They leave the field blank but you want it to be completed.

On the whole, we'd expect typing and transcription errors tobe confined to a small number of fields on the form. It would be best to show the error close to the problem. You'd expect the field to be partly or fully filled by the user, but not to match your expected input.

Send errors are likely to affect many fields across the form. I've not yet seen it done, but I've often wanted to recommend that the programmer looks for this type of across-the-board error and gives an across-the-board error message. It would be polite to suggest to the user that they've sent the form with a lot of blanks, and please to try filling it in. This might be a good case for a separate display of the error because it applies to large parts of the form rather than a single area.

Category errors are tricky. The problem here is that your site's view of your users doesn't align with their own opinions. It's also rather hard for your programmers to distinguish between category, typing and transcription errors. The important point is to ensure that your error messages are assistive ("We regret that we're only able to ship within Australia at the moment") rather than accusatory ("Invalid state"). You have to examine the meaning of each data item, both to your organisation and to your users. I've found that usability testing can be a great help here. It can also be helpful if you offer 'other' categories if at all possible. They should be rare, and you can route these forms for manual assistance rather than automatic processing. If you've got good choices of categories and ranges, then you should get few error messages and, like typing and transcription errors, you can display the occasional one you get near to the problematic field. If you're getting a lot of them, perhaps it would be nicer to treat them as an across-the-board error message in a separate area - maybe offering an alternative route such as manual assistance.

Privacy errors are possibly even trickier than category errors. Depending on the ordering of fields, you may be able to tell that you're getting some privacy errors by the presence of blank or default entries scattered through the form such as sporadic blank entries in mandatory fields. But I would imagine that it's sometimes difficult to tell the difference between send errors and privacy errors. You can sometime tell if a privacy error might be likely by examining the data you're getting: if you find that many of your users are called Mickey Mouse and live in an obscure country, then that's an indicator of privacy errors. You can sometimes help your users through these by explaining why the data that you're asking for is essential to complete the transaction. "Marketing wants it" is unlikely to be sufficient but "we are required by law X in jurisdiction Y" might be successful (if true). Sometimes you can improve the privacy error rate by moving questions so that the reason for asking is apparent from the context - street address is more likely to be entered correctly if you ask for it in the context of 'where do you want this item shipped'. If you suspect that a privacy error might be likely on a field or area of the form, then it may be more convenient to opt for a separate error message so that you have more space for a polite explanation and a link to your privacy and security policy.

What do we mean by displaying a message 'close to the field' or displaying a 'separate' message?

Close to the field means that the user sees what is essentially the same form, with fields in the same order as originally filled in. The cursor appears in the 'error' field (if technically possible) with an error message close to (preferably in front of) it. You may need to increase the vertical gap between fields to accommodate the extra text.

A separate display means that the user sees a new page, popup, sidebar or at the top of the screen. A new page is easier to navigate, and provides more space for your explanation. A popup is easier to examine in context with otehr answers, but can be annoying if the popup is perceived as a diversion or, even worse, an advertisement. A sidebar allows examination of the problem in context, but may not fit conveniently on a narrow screen, and may not be as attention-grabbing. The top supports easy to navigation, but may be perceived as a new page, and may be difficult to examine in context with the fields.

So all methods have their problems and advantages. I'd recommend usability testing with your audience, possibly comparing different approaches.

See also Jakob Nielsen's Alertbox column on error messages.

<<< Back to the list of questions




Log In


Last Modified 2008-09-17