Video: ErrorsWe can do our best with asking clear questions using form labels, providing great efforts as using Form Input Fields, and laying things out appropriately, but errors still may happen. When they do, we want to do our best to resolve them as quickly as possible. Let's look at how we do that. Not too long ago I was asked to register for the Fairmont President's Club. This is a club for people who stayed at the hotel more than once. I was given a card number and asked to fill in this form, pretty much no problem. Went through the form, and, can you tell what happened? Somewhere on this form is actually an error message.
Viewers: in countries Watching now:
In this course, interaction designer Luke Wroblewski shows how to create web forms that encourage visitors to enter information and covers ways to capture input without the use of forms. The course covers boosting conversion rates and customer satisfaction, organizing the structure of forms, aligning and grouping form elements, assigning the correct input field types, validating input, and handling data entry errors. The last chapter highlights alternatives to static forms, such as using dynamic inline forms, using web services, and leveraging device capabilities, which can be used to gather additional information or replace a traditional form altogether.
- Understanding why forms matter
- Deciding on the form length and structure
- Adding tabs to a form
- Creating required fields
- Adding input masks
- Creating selection-dependent inputs and actions
- Displaying success and error messages
- Adding inline validation
- Understanding gradual engagement
- Enabling touch and audio input on devices
We can do our best with asking clear questions using form labels, providing great efforts as using Form Input Fields, and laying things out appropriately, but errors still may happen. When they do, we want to do our best to resolve them as quickly as possible. Let's look at how we do that. Not too long ago I was asked to register for the Fairmont President's Club. This is a club for people who stayed at the hotel more than once. I was given a card number and asked to fill in this form, pretty much no problem. Went through the form, and, can you tell what happened? Somewhere on this form is actually an error message.
Down at the bottom of three paragraphs of text, we see some bold text, which tells me, hey, we are sorry, but we can't actually find that card number. Please verify the number and try again. Well, how exactly do I do that? It doesn't really seem like there is an opportunity to do so on this page. This indicates a number of problems with the way that Fairmont has treated errors. Number one, it's difficult to know that an error has actually occurred. There's not a lot of visual contrast of this error message. In fact, it's very below three paragraphs of text and only made bold. Two, the way they tell me to actually correct the issue, is impossible, there is no way to verify the number and try again on this page.
The only choice I am left with this to hit the Back button and try going through the form again. So how can we make the errors on the Fairmont site more effective? For starters, we can put a primary message at the top of the page that indicates an error has happened. When there is an error on the form, it's arguably the most important thing, therefore, let's treat it that way visually, really making it pop with bold fonts and icon and even a red border. Secondarily what we've done is associate that primary message with the error that's causing it, so you can see red font is also used near the Fairmont President's Club input field.
The association between that message and the thing causing the error is a great way to see, well, what's really wrong here. And then the third what we've done is given people ways to resolve the error, both in the message at the top and at the input field causing it, we have text that says, Please try again or contact us. Contact Us is a link that gets you to help to fix the problem. The actual point where we message an error requires a doubling of visual language. That is, we do more than one thing to indicate where an error is. We can do this in a number of different ways, and here are some examples.
The first one uses an icon, bold text, and a red color, and even a gradient to indicate where there is an error. Second one below uses an icon and some additional text. Third one below actually uses a background color, and so on. The idea here behind doubling visual language is that it brings more attention to the areas that have problems. It also helps people who may have colorblindness or who may not see a subtle differentiation in just bold or just color, find where an error is happening. More than one change in visual language creates more contrast helping people find errors quickly and effectively.
Let's look at this technique on a form. If you remember this form from our previous discussion of Primary and Secondary Actions, you'll note that I've made one important change. The Confirm action is now the primary button and the secondary action of Cancel has just been turned into a little link. But let's say someone goes to this form and doesn't fill in a Subtitle, but hits the Confirm button. What do we do? Well, here's the same techniques around error messaging. You'll note at the top we tell you that you need to correct the information, we point you to where the error is actually happening, and again, we double the visual language at the point where the errors occurred, by turning the title red, bolding it and inserting a line of text directly below the input field that tells you how to resolve the error.
This resolution of the error is the third important piece of error messaging. Enter a subtitle or click Cancel. Both ways will get you out of this error state. On forms where there is multiple points of error, we can apply the same technique. So on the eBay, Post to Want It Now form, you can see Title, Description, and Category are missing, and we've applied the same treatment for indicating what's wrong to each field. Each one gets a doubling of visual language, each one gets a set of text that explains how to fix it and everything is wrapped up at the top in an overall error message.
Now some people may react to seeing a form like this and say, hey, that's way too much red text for a simple little form like this. Do you really need to highlight every single input field in the same way? Well, number one, it's unlikely that somebody is going to go to a form not fill anything in and click Submit, this is kind of an artificial state. But number two, especially on longer forms, it really helps to know where the error is. Consider this example on Jotspot. Here, there is an error message at the top that says, this e-mail address is already registered.
Hey, there is not an association with where the input field is, so I need to look a little, but because it's a short form that's not such a big deal. The bigger problem is there is really no way to resolve this error. That is, what if that is my e-mail address, what if I don't know if I've already registered? And assuming I already have registered, how can I resolve this problem? There is no way to get help doing so. In fact, this form only contains one of the three pieces of what I think makes an effective error message. That is, it has a primary message at the top that tells you something is wrong, but it doesn't associate that message with what's wrong, and it certainly doesn't give you a way to resolve the problem.
Especially on longer forms, the idea of associating that primary message with what's wrong is a big deal. That is, the error may actually be off- screen, and if there is multiple errors, we can't just move the page to where the error is, we need to give people an overview of what's wrong. So on this long Balance & Draws form, having that error message at the top really helps, and then doubling the visual language with where the error actually is, allows you to scan through the form by scrolling and finding where the problems lie. Last but not least, we also need to consider how to deal with error messages in dynamic forms.
That is, in places that don't have this page model of Submit and Refresh the entire page. So on Apple's Checkout Registration form they are using an accordion model. Let me illustrate what that means, and then show how an error state can show up there. We are filling in Shipping information, and we click Continue, that section rolls up. Note there wasn't a Page Load and Refresh, everything is happening dynamically. As we go through the payment information and click Continue there, you'll note an error pops up, the little yellow field I am correcting right now. Because we are not leaving the page, we are actually dynamically inserting the error state into the form as people go along.
This way we can manage errors without having people actually leave the page. To wrap up Errors Best Practices, the first big deal is that we need to communicate an error has happened. When something is preventing you from submitting a form, that's a big deal, and usually the most important thing on the page, therefore we should treat it that way visually. Strong prominence, big message at the top, bold, red icon, whatever it takes to grab people's attention and tell them they need to address the challenge. Secondarily, we want to associate that big message with the thing causing it. So some level of visual communication that is similar color, similar type treatment similar icons that lets you know where that error is.
Third, and perhaps most important, is giving people a way to resolve that error, that is, providing actionable remedies that allow them either to get out of that state or fix the problem. And don't forget to double the visual language where you're highlighting errors. This will let people quickly find an error without having to rely on a single bit of color coding.
There are currently no FAQs about Web Form Design Best Practices.