Idea: Error-Fields Only

Update 1. June 2012: After the publication of this article we’ve written a followup article at Smashing Magazine further exploring the “Error-Fields Only” concept, that you might want to read instead as it is more thorough.

Validation error pages are dreadful. You just filled out 20 form fields yet you still get the same bloated page thrown back in your face because a single field failed the validation.

When getting the exact same page (but now with an error message) the user will feel that little or no progress has been made – despite actually having typed 90% of the form fields correctly. Image credit: BlueNile.

I clearly recall the sighs of despair during our last usability study each time a test subject encountered a validation error. This frustration was in part caused by the fact that they were returned to the same page they came from with all form fields still there (valid or not), making it more difficult to find the erroneous fields. Perhaps most critically, seeing the same page made it seem like no progress had been made despite having just filled in numerous form fields.

The Traditional Way

Let’s take a look at a traditional validation error page:

Dell’s current error page during checkout – a decent implementation with both a general error message at the top and a tailored error message near the erroneous form field. Image credit: Dell.com

In the traditional setup, when everything is implemented perfectly, you get the whole page with all 20 form fields and an error message at the top stating that a few fields are causing trouble (ideally with anchor links to those fields). When you then scroll down and eventually find the error-fields among all the valid fields, there’s ideally a tailored message describing the problem and how to resolve it. The user can then fix the problem, scroll up and down the form to make sure all errors are now fixed, and finally, scroll down the form one last time to click that “Continue” button once again. Clearly this is a poor experience, diminishing the user’s sense of accomplishment and making it unnecessarily cumbersome to resolve the errors.

Error-Fields Only

What if we removed all those fields that are valid? What if we only showed the fields that failed validation? So instead of reloading the entire page and showing all 20 fields of the form when there’s only a problem with the “Phone” and “E-mail” fields, you simply show a page with just those two fields (and their corresponding error descriptions of course).

With this Error-Fields Only method the picture is quite different. The user now gets a new page or an overlay with just a couple of error-fields. A summary of the valid data could also be displayed for confirmation purposes.

A simple mock of how the same validation error page could look when utilizing the Error-Fields Only method.

This approach makes the error validation page much more digestible and makes it abundantly clear which fields are causing trouble – something that’s particularly helpful in long forms.

Now the user simply has to fix the fields shown to him and hit “Continue”. There’s no scrolling, no process of identifying erroneous fields from valid fields, no repetition of the same page – instead there’s just a small simple page explaining exactly what to fix and how to proceed.

Comments (23 so far)

Not such a bad idea indeed! Either way I feel you cannot simply hide the rest of the fields, because one may be wanting to correct something there. So list the info from these fields as well, as text, along with a link to edit the correct information.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

The motivation behind this solution is a good one. But perhaps it’s the not quite the right solution? My concern is the loss of context. The new “error-only” page looks different to the page they were just on, so might it not confuse, and take the user a while to work out what’s going on? Also, the context of the surrounding questions might be important.

You could (and I do):
- make the error fields much more visible by shading the background red (when there is one field per “row”, this means shading the row, which stands out nicely);
- use anchor links in the error summary to make it easy to jump to the first field; and
- use an icon, such as an exclamation mark, to help indicate the error fields.
See http://formulate.com.au/articles/well-designed-error-messages/ for an example.

One thing I haven’t done but would like to is have a link next to each error field which jumps the user to the next error to be fixed.

The point you make about feeling like there’s no progress is a good one, though, and not solved by any of the above. Might ponder that one a bit more.

I agree that the error pages seen in all three images above could use quite a bit of fine tuning. The mockup (3. image) in the article was made by patching different parts of Dell’s checkout together and is meant purely for illustrating the concept.

In regards to loss of context this can be an issue depending on your site and context. But with a well designed implementation of the Error-Fields Only method some of the issues with lack of context could be alleviated.
E.g. the valid inputs (displayed with text and an edit link) could be in the same position as in the original form – in the mockup image it isn’t (here all of it is below the error field). Also, the error instructions provided could hint at the context, along with better implemented checkout step indicators, etc.

Thanks for your response. Totally understand about the limitations of the illustrating.

It strikes me that the suggestions you make in your response to me seem like workarounds that may cancel out the overall improvement. For example, on a form that’s a couple of screenfuls long, having the error fields in the same position, floating in whitespace, is going to seem rather strange (I would think). And hinting at the context is nice in principle but a) we know most people don’t read instructions and b) in practice it will mean a lot of work to write instructions for every type of error.

(BTW, if it’s not clear, I’m concerned with forms that are more than just a few fields. They are the more challenging case, design-wise.)

As Jamie mentioned below, this idea is presented as such, and it’s clear it should be tested before ever being implemented. But I’d be interested to know whether — in your expert opinion, and based on the usability tests you’ve seen — the issue of a sense of progress is significant enough that even if the page is well-designed — so that error fields are clearly visible — we should be thinking about alternative approaches?

The suggestion with placing the text input where the form fields used to be (to keep the users contextual understanding of the page) really depends on each specific implementation. On the Dell page it might be doable with a collapsing animation or similar. But as you point out, the longer the form the more the entire concept of error-fields only is lost.

In regards to writing form error instructions for each error type; yes it can be a lot of work, but if your form is important then it should be worthwhile. A user that gets an error is more inclined to abandon than one that haven’t (obviously). But I the usability test we’ve conducted we consistently observed that a user that get’s concessive errors in the same form will almost always abandon (often assuming “the site is having a technical error” or similar). Helping to avoid multiple errors with tailor-made error descriptions should be worth while. The number of user that will ever see them might be low compared to the work it might be, but each user will benefit tremendously from error-specific error messages rather than generic error messages.

Thank you very much for your inputs (as always when we post on web forms). Hopefully Jamie and I will get a chance to do a followup on this topic sometime soon to cover some of the thoughts mentioned here in the comments.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

One issue I can see at the moment is if the input that has an error, relies on some other element in the form. For example a form that asks for country and then asks for the address, in this instance the difference between Post codes and Zip codes may cause an error and a simple change of the country would fix it.

This could be resolved by either, providing additional elements on the new page that relate to the input in question but that would require some sort of field mapping or providing a way to get back to the original input form to allow changes.

You’ve posed an interesting alternative. The big question though, is have you tested your theory? You’ve described how users behaved during testing when faced with long forms with validation errors, but you haven’t described how this behaviour differed with your alternative.

I would be concerned that by removing fields you’re changing the layout (signs and signals) that orientate the user with where they are and where they have been. Put plainly – I would be interested to test whether users think the screen they see with only their errors is a new page or just a simplified version of the one they were already on. i.e. do they think they have progressed, or do they realise that they are still where they were before?

Also, I would be interested to test how secure users feel about ‘partially submitting’ form entries. What I mean is, by removing elements that have passed validation you are removing users’ ability to review the entire form before finally submitting it. Or are you suggesting that once they have corrected the validation errors that you now re-display the entire form in it’s ‘pre-submission completed and error free’ state?

Overall – a nice alternative but one that I would be inclined to test rigorously with both User Research and a/b testing.

We didn’t test the solution ourselves (not yet, anyways), and it would absolutely need thorough testing before deploying site-wide.

The title of this article was deliberately prefixed with “Idea” to indicate that this was merely a thought that might be interest to test. With regards to valid entries, the idea was to show this valid data below the form along with an edit link.

However, maybe a better approach would be to reload the entire form and then put green checkmarks next to all the valid entries – this way you solve the issue of the user feeling a lack of progress without running the risk of confusing the user with a new / partial page.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

The “loss of context” problem is not really a problem per se, unless the user expects to see what they had just typed.

When you are at the airline ticket counter, they ask you for your seat preference, and you give them a non-existent seat number, they don’t ask you all over again for your name, DOB, address, passport number and so on, nor do they present that information to you. Both the customer and the person at the counter automatically assume that the information already provided is acceptable, barring any further questions.

Perhaps we can move away from thinking about filling out forms, and thinking more about the user experience, how they prefer to provide information and confirm it. For this reason, I thought this article was an interesting approach.

The analogy you give is about a “field” (preferred seat) that is unrelated to the surrounding “fields” (name, DOB, address etc). In this sort of situation, you don’t need the other fields to answer the error one.

In many forms, however, the fields are related. For example, suppose on an insurance form I’m asking whether the car has any modifications, and if the answer is yes, I show a new question asking what those modifications are. If the conditional question is missed, and I show only that on an error-only form, it’s likely to be harder for the user to answer than if it were shown in context.

This is not to say I think Jamie’s idea is a bad one. I also think you’re absolutely right to focus on how users prefer to provide information and confirm it. Just wanted to clarify that loss of context could be a real issue, especially in forms that are more than just registration or login.

Cheers
Jessica

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

I am along the same thinking others with the loss of context with this idea. If you are able implement in-line validation as the user progresses through the form, the user is able to correct errors immediately. Luke Wroblewski has done lots of research and documentation about in-line form validation. If you haven’t yet, you should check it out!

I love that you’re thinking about new ways to handle the situation, though! It sparks additional ideas. Thanks so much for sharing your thoughts!

Yes inline validation is also a very good error handling method. Especially for inputs that can be validated independently (typically shorter simpler forms, such as account sing-up for a webservice or similar). Luke (and others’) findings is well worth a read.

However, some inputs are more complex and can require dependencies on other inputs, external (or internal) server lookups, etc. Here live inline validation isn’t necessarily a perfect fit. Address and credit card validators comes to mind. Here live inline validation would first indicate to the user that a specific field is correct, and then later on still give an error when the dataset is validated as a whole. We might do a followup on this explaining it further.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.