Articles Comments

GUI Journal » GUI Design » GUI Design: Error Messages

GUI Design: Error Messages

I’ve blogged about error messages before. The basic rules for error messages are the same as for everything else in a GUI. Remember that users are simply trying to get something done, so don’t slow them down in any way unless it’s absolutely necessary. Error messages may be necessary on occasion, but designers and developers should always start with these two goals in mind:

  1. Remove the need for an error message whenever possible by not allowing users to make the mistake in the first place.
  2. Make each message clear and as easy to resolve as possible. (This includes keeping the message visible while it is being resolved and not requiring anything like a mouse click to dismiss the message.)

Thinking carefully about these goals should result in a design that will be much better for your users.

EXAMPLE: BOTH GOOD & BAD

I was recently using a web application that gave payment options for entering a Bank Account or a Credit Card. I chose the option to “Add Credit Card” and was presented with the form shown in Figure 1.

Figure 1. "Add Credit Card" Form from Web Application

I entered some of the values and selected Save. The form then redrew with inline messages, including a summary at the top and specific messages at appropriate locations on the form. The reasons this is great include:

  1. The user is not required to dismiss an error dialog before attempting to correct the errors.
  2. Multiple errors are shown at once.
  3. The messages are clear.

For this particular form however, not all of the messages are very helpful. Figure 2 shows a portion of a screen of the same form after certain text has been entered into the Create account nickname input field.

Figure 2. Error Message for Invalid Nickname

Note the error message after the text “My account nickname to remind ” has been entered. The input field only accepted the number of characters shown. After Save is selected the error message appears which describes the valid characters for this entry. Close examination shows that each of the characters is valid, and so the user is left to wonder what the problem is.

The first time I used this form, the error message was actually different. Figure 3 is a mock-up of the error message on the form as I found it originally. (I wrote down the message, but unfortunately I failed to take a screen shot when I had the chance.)

Figure 3. Cryptic Error Message

The message Enter amount less than 20 is a little confusing. At first I wasn’t sure which input field it was complaining about. It took me a moment to realize that what it meant was that I had entered more than 20 characters into the field for the nickname. Once I reduced the number of characters to 20, then the error went away.

I made a note of the error when I first found it, intending to return and blog about it later. That’s when I found that the message had changed to what is shown in Figure 2. I’m not sure which message is less helpful.

The silliest part about it is the fact that the number of characters allowed by the input field is restricted to 30. If it were simply restricted to 20, then that message would never be needed. That means that the error shown in Figure 2 could be used only when invalid characters were entered.

Incidentally, I checked out the form for entering Bank Account information. Figure 4 is a screen shot of the Add Bank Account form.

Figure 4. "Add Bank Account" Form

This form is very similar to the other, providing helpful, inline messages. Note that the messages for too many characters in the nickname is much better here than the other form.

But the issues are the same! Why doesn’t the form simply remove the possibility for the error by restricting the number of characters entered. Another question is why these two forms aren’t using the same error messages for the same error.

So much was done so well here, it’s unfortunate that some of the details are a little sloppy.

 

KEY DESIGN POINTS

  1. Error messages need to mean something to the average user; don’t use tech talk.
  2. Error messages should be inline; don’t require a click to dismiss.
  3. Help users avoid an error in the first place, such as simply not allowing an input field to accept too many characters rather than telling them they have too many.

Written by

Carl Andersen currently works for Micro Focus International as a Senior Development Manager. Carl has led teams at NetIQ, Novell, and WordPerfect and been the principal designer of multiple GUIs which have received analyst acclaim.

Filed under: GUI Design · Tags: , , , , ,

Leave a Reply

*


five − 3 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>