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.
Only a single digit in the ZIP code is wrong yet all the form fields are returned. 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.
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.
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 what Dell’s earlier validation error page could look like 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.
What do you think?
User experience research, delivered twice a month
Join 25,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
Related Articles
More E-Commerce Research
Free Research Content:
- Popular Articles · a listing of our most popular research-based articles on e-commerce UX
- UX Benchmark · benchmark with case studies of 93 major e-commerce sites ranked by e-commerce UX performance
- Page Designs · navigate 8,400+ manually annotated full-page screenshots categorized by page type
Products & Services:
- Baymard Premium · full access to all 582 research-based design guidelines, UX case studies, page designs, and review tool ($720-$3,000 / year, based on plan)
- UX Audit · get an in-depth analysis of your site’s UX, conducted by a Baymard researcher ($1,900-$9,700 based on scope)
Comments
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 info@baymard.com
AlbertApril 10, 2012
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.
Jessica EndersApril 10, 2012
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.
Thanks for sharing,
Jessica
Christian, Baymard InstituteApril 10, 2012
Hi Jessica,
Thank you for your comment.
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.
Jessica EndersApril 14, 2012
Hi Christian
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?
Cheers and thanks,
Jessica
Christian, Baymard InstituteApril 24, 2012
Hi Jessica,
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.
PeterApril 10, 2012
I like the idea of this.
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.
Christian, Baymard InstituteApril 11, 2012
Great point. This do require a more well mapped relationship between the form fields, the error page, and error fields, than usual but it’s certainly possible.
ClintonApril 10, 2012
What about alternative CSS when a validation error is thrown?
so that correct portions of forms are somewhat faded out (similar to fade out when a modal window pops up)
and the incorrect fields get bold, larger and non-faded.
Christian, Baymard InstituteApril 11, 2012
Hi Clinton, that is a great alternative. A simple qualitative test should give an indication if the user will still experience the progress (my only concern).
Thank you for sharing.
Blair KeenApril 11, 2012
Hi Jamie,
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.
Just a thought :)
Blair
Jamie, Baymard InstituteApril 11, 2012
Hi Blair,
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.
Alex MearnsApril 11, 2012
This is a great idea, one I plan to implement.
I will however take the approach of converting all the fields that passed validation to a simple line of text with an edit icon, leaving only the error fields as form inputs.
This as suggested deals with the loss of context.
It will be an interesting MVT.
Ewout WinkelmanApril 12, 2012
I really like your approach on this.
The basic concept is great but, as others have stated, may confuse the user by altering the view dramatically. Your approach can be the middle way on this.
Would love to see this in a working example.
JeffApril 11, 2012
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.
Jamie, Baymard InstituteApril 11, 2012
Hi Jeff,
That’s an interesting analogy. This article was mostly meant as an idea to get people thinking in new ways about validation error pages.
I’d recommend anyone to do proper A/B testing before rolling this solution out to everyone.
Thanks for your comment!
Jessica EndersApril 14, 2012
Hi Jeff
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
JurgenApril 11, 2012
Great idea. But what if the user wants to change something he typed in one of the correctly filled in fields? I suggest we provide him with a ‘show complete form’ link.
Jamie, Baymard InstituteApril 11, 2012
Hi Jurgen,
The idea is to show a summary of the valid data along with an edit link in case the user wants to change something.
Showing some sort of “toggle” link that switches between just error-fields and the entire form could of course also be an option.
JamieApril 11, 2012
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!
Christian, Baymard InstituteApril 11, 2012
Hi Jamie,
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.
INFOUNDMay 1, 2012
Thanks for the great post. I appreciate that vision of avoiding those moment when you have to search through a long form for invalid fields.
chris finiksopoulosMay 8, 2012
How about Ajax and disabling the “continue” button when an error comes up or form is not filled ??
LoopTistSeptember 20, 2012
Just tested a dense form that uses inline validation. you have to successfully complete each field before the UI lets you move on to the next field.
Result: users liked it and felt “taken by the hand” and “guided”. Particularly positive was the response to the “success” icon placed next to correctly filled fields (“encouraging”, and “safe”).
The funny bit: most of the design group didn’t like it, and insisted that this approach is “constricting”, and would cause people to be frustrated because they wouldn’t make "progress’.
Lesson learned: just because you are a designer doesn’t mean you know what’s best for the user.