Form validation best practices
A case study of how to get it right
Ever completed a long payment form online just to be rewarded with 76 error messages once you’ve pressed submit, annoying isn’t it, especially when it isn’t clear what errors you’ve committed, and where!
We recently had a chance to re-look at this problem at uSwitch.com as part of our ongoing rebranding process, and as expected finding a unified system for form validation proved both problematic but rewarding. Through this article I will try to explain the specific problems we had and our approach to solving them, which in turn laid out a specific set of 10 rules that we used at uSwitch.com.
Firstly, what is form validation
Form validation is the process used by form dialogs to alert users of errors in their submissions. In recent times the usage of positive messaging in validation has grown which has helped to gamify the process of form inputs. In general terms their are two variants of validation implementation;
- Instant validation which occurs as the user is typing or selecting form elements
- Same page reload validation which is used once a form has been submitted, before reloading the page with errors displayed.
Our problem
We had a variety of form types and inputs across the site; checkboxes, radio buttons, multi-selects, password inputs et al which required different messaging regarding their validation, but, as we tried to unify the once divergent appearance of the site under one uSwitch branded banner we needed an all encompassing solution that worked on mobile, to desktop, in a variety of different situations.
Process
As with all successful projects we started with research, internally and externally. With a quick audit of our site we realised we had compiled an elaborate array of validation elements, none of which were truly consistent, and some of which failed miserably in their primary task.
Along with this internal review, we scoured the web for resources on the best UX practices for form validation (there weren’t many) and came across a few sources which were extremely interesting (and more eloquently written). Most notably Marcin Treder’s brilliant article which is best summarised by his four key points of good form validation.
Which, abridged are;
- Display at the right place: Next to the input in question
- Display at the right time of informing about problems/success
- Use the right colour: Red for problems green for success
- Use clear language: Have a conversation with the user
It was with these four points in mind that we tested our solutions. At uSwitch we also needed these points to not interfere with our current form and page stylings so we added one more point. Universal integration: Form validation should be consistent and non obtrusive in styling, location and tone relevant to its application. For instance, red error messaging would never draw attention on a site which primarily used a red BG colour. As a structure for this article I will summarise the reasoning behind these four points using various sources before explaining how we applied them within uSwitch.
Display at the right place
Explanation
Firstly lets start with displaying validation at the right place, as you could see in the image above we were previously displaying error messages in every available option, above question, below inputs, immediately to the side of elements, in pop ups, in help text etc. etc. The one thing they did have in common is their proximity to input fields in question, which is essential.
“Always display validation within the context of the action”
Grouping validation messages at the top or bottom of a page away from the inputs in question separates the link between inputs and errors and should be avoided at all costs. If a user can’t see an error message or likewise find the inputs they will very rapidly get frustrated and bounce (I know I would).
So, validation messaging should be as close as possible to the action, but which position works best…
To the side of the input
This works extremely well on desktop and for instant validation, as the user types, the form appears to be having conversation with you. It also benefits by not pushing other page elements around. Keeping your beautiful page layout in tact and avoiding the annoyance of jumping inputs. This system works extremely well for positive validations as it doesn’t distract from the main focus of the page, the inputs themselves. Twitter has used this extremely well for several years on its desktop site.
The downsides are that when used for same page reloads, there is a potential for the messages to be skipped over, especially long forms due to users scanning pages in an F shaped pattern. On mobile, this approach can rarely be used, resulting in messaging defaulting to above or below the question anyway, as seen on Twitters mobile site. With inline elements, where submit buttons are immediately to the right of inputs, this approach can’t be used either.
Application at uSwitch
For us at uSwitch we had a particular complication in that most of our form elements have help text tool tips already in place on the right hand side of fields, in a lot of cases there are also additional sidebar elements, leaving little space for additional messaging. As part of our approach of universal integration, we didn’t want to have to rethink these features.
Why didn’t we display validation messages within the help box tool tip elements? Because it is generally a bad idea to combine two interactions or messages into one element, suddenly changing expectations of elements is a jarring experience and should only be done if the two are congruent. In this case they weren’t, our help text usually consists of reasons why we need the information or hints about where you could source it, whilst validation messaging should be centred around why exactly your inputs were erroneous.
Below inputs
For instant validation, this is the natural location for most conversational messaging that couldn’t be displayed in the favourable position of the side. This is due to it being the focus of the users attention directly after inputting a field as they scroll down the page.
The down side of this styling is that in long forms, where same page reload validation is required, users scrolling down the page only view errors after scanning over the question and input. After seeing this message users have to go back and reread the question and answer again in attempt to correct it. It might not be the worst of usability sins but can be frustrating when questions are particular complex or long.
Within tool tips
Another common style of displaying validation is in the process of encapsulated flags, tool tips.
Although this is often cited as being a bad approach due to lack of accessibility by screen readers, there are ways around this. Instead the main concern with this approach is that it requires a lot of bespoke work in each application due to its talent of concealing important information surrounding the input. Whether it is above, below or to the side, concealing the question, hints or help boxes (or even the input itself) is a big usability no-no.
Above the label
This works best on long forms where the validation is on same page reload. After page reload, the user should be back at the top of the form where scrolling down first reveals the error message then the question and erroneous field input in turn. This allows the user to mentally focus on the error in hand before attempting to address it. For this same reason this positioning is far superior in the accessibility stakes, screen reader users will first come across the problem then have an attempt to address said problem. Another benefit is that it’s unlikely that the message will be cut off by the browser window when power uses tab through the form.
The downside of this approach is that it is possible to be overlooked in instant validation purposes, specifically on mobile, as the user is already moving onto the next question through scrolling or clicking it is possible they won’t see the message that appears above the fields they’ve just read and answered. It also pushes down content below throwing users off their location in instant validation application.
Below the label above the input
This has the benefit of being closer to the erroneous action, but fails due it being generally quite confusing as it splits the question from the input. If an error list is extremely long, say for creating a new password, the question can get visually lost within the clutter.
The best position for validation
Validation is best positioned immediately next to the action in hand. Instant validation is best positioned to the right hand side of the input, or failing that immediately below. This works best in principle for creating the conversation between user and for that manages to gamify the often tedious process of form inputs. For same page reload on long forms, form field validation is best displayed above the question label so users don’t repeat themselves, and miss messages.
uSwitch application
For uSwitch we needed to ensure one system worked in every situation as part of our mission for universal integration. For this reason we decided error messages should be above the question labels in all situations. We have a prevalence for long forms and same page reload validation on the site where this location makes more sense. The risk of frustrating users with a hidden instant validation error message is a lot lower than a hidden same page reload error message and therefore we had to design for these inputs first.
Display at the right time
Explanation
As previously mentioned the most commonly used moments to display validation are, instantly, and once a page has been submitted. Ideally…
The right time to inform about the success/failure of provided data is right after the user has submitted the information
Which points to the use of instant validation wherever possible, this is simply because users can assess their errors as they arrive instead of being overwhelmed at the end. And don’t just take my word for it, a study by Luke Wroblewski saw that using instant validation as opposed to page reload caused;
- a 22% increase in success rates,
- a 22% decrease in errors made,
- a 31% increase in satisfaction rating,
- a 42% decrease in completion times, and
- a 47% decrease in the number of eye fixations.
Great, so the correct time to display validation messaging is instantly! Well, of course it’s a lot more nuanced than that. There are obvious limitations where instant validation can be used and in some cases it counter intuitative to use it.
Instant validation should only be used for complicated questions.
For easy to answer question, such as; what is you name, what is your gender etc, instant validation can do more harm than good as it is generally confusing; ‘what is this green tick telling me, I know my own name?!’
All inputs that have a finite answer or limitations, have the possibility of instant validation. But, adding validation to questions that a user would normally fly through (and we have no idea of whether its correct or not) validation can slow down users and can come across as a pointless gimmick. Instant validation is also not possible on inputs that have a default, such as radio buttons or some select drop downs.
So if some fields have instant validation and some don’t within the same form, what happens? Confusion! Consistency is extremely appointment in usability and validation is no exception, if success messages appear beside some fields but not others, users may assume there was something erroneous with their input, slowing down completion rate and confidence.
So you can’t use instant validation in all situations but in those you do, when exactly should you display messaging? In Luke Wroblewski’s article he highlights that there are three different possible times for displaying instant validation;
After
Success or error message is displayed after the user has clicked or tabbed out of input field
During
Messages are displayed as the user begins typing (or selecting)
Before and during
Messages are displayed as soon as user focuses on form element and updates whilst they answer
In his article Luke found that the after method helps users to complete forms more quickly. This is due to users in the other two buckets typing one character at a time to check it was correct or getting frustrated when an error message was displayed before they had completed their input eg. ‘Why are you telling me my pet name is incorrect! Of course it’s incorrect I have only entered one letter!!”
uSwitch application
Due to the benefits of instant validation in success rate and completion times, we decided to use instant validation wherever possible that didn’t seem forced. With a strict policy of usage on ‘complicated’ questions with validation requirements (eg. Password and username). On forms where a few fields can be instantly validated but the rest can’t we considered it best to only use in clearly definable sections to avoid the confusion of some elements not displaying any validation.
This was a contradiction of our pledge for consistency but we deemed the benefits of instant validation on said questions greater than the confusion this inconsistency may lead to.
In terms of timing we took the approach of only revealing validation messages after input. When this was deployed in instant validation usages however, it was obvious that this would be as equally frustrating and negated its effectiveness (users who experimented with several usernames for example would have to tab out of the field to validate its availability) for this reason we decided to deploy a lag of 10ms to any input answers so users could validate within the field. This inherently caused problems however…
Due to our prior decision to universally show validation messages above field titles site wide, and it’s irritating side effect of pushing content below further down the page, this lag effect caused an extremely unwanted pogo-ing problem. As the user is still within the field whilst the error message kicks in, their subject field invariably gets pushed down (sometimes out of sight) before they start typing again at which point it jumps backup. For this reason it was clear we needed a different type of validation for users who were still within their input fields. This is what we coined micro-validations.
Micro validations are simple subtle hints of success or error that relied on the same 10ms lag principle but displayed without affecting other elements on the page. These can be expressed through icon use, colour changes, or microcopy.
For our particular application we settled on a miniature icon in the top right corner of the field input.
Why here? Similar to our reasons for choosing our main validation messaging, we are particularly tight on space in some areas of the site (and always on mobile) to add an element that reordered or diverged other elements on the page would be counter intuitive for the whole reasoning of micro validations, not to mention problems with colour contrast on our array of usages.
Why not within the form input field itself? A tempting solution but due to native UI on some mobile devices this could cause problems. Example image
Why not just rely on a colour change? It is always best to use both colour changes and physical shape changes to ascribe differences because of colour accessibility.
Use the right colour (and the right icons)
Explanation
Generally speaking it is best to stick to the use of red for errors and green for success. There are several usability articles that suggest orange or yellow should be used for error messaging as not to appear too alarmist. I would be wary of using such colours though, as these often fail in colour accessibility tests and aren’t always identifiable as errors, but more often than not across the web this colour is used for warnings.
The pretence of not using red as it is the colour most associated with danger, and could scare off your weak hearted customers, has always seems stretched. For one, there is a lot of contradictory evidence that colours are too associated with personal experiences to be bucketed into generic, population wide emotions. And on the other it is the system used by every other site, UI and traffic system in the world. As Jakob Nielsen puts it “Users spend 99% of their time on other sites” so always try to follow web conventions.
Uswitch application
In our particular case we have a problem with multiple background colours of form inputs, so just using a red type colour would also fail accessibility visibility (plus look terrible on our lovely blue!).
For this reason we decided to enclose our errors within a bounding box with an opaque background colour that could be repurposed in every situation.
We also found that just using red font to indicate an error (or green for success) wasn’t enough. Not just for the accessibility of colour blind users but also because it still could easily be missed. For this reason we also applied red strokes to all erroneous fields and decided to use icons for success and errors. Running with the industry standards we kept this as exclamation marks for errors and ticks for success. When it came to positioning of the icons themselves the thought process was they should act as calling cards to the alert message and so were best placed directly before the messaging (but we also utilised them in top right of fields as mentioned above for instant validation).
Use clear language
Explanation
In this brilliant post on validation language the author stipulates that we should always try to reassure the user, not blame them for their mistakes. It is all too common, as known by Jakob Nielson, that users blame themselves for problems in web design. Compounding that further with aggressive and unhelpful language only pushes them off your site. Instead, if there are particular requirements for a field, always stipulate them clearly upfront and save everyone the hassle of reminding them through validation.
When the time comes for validation messaging, although nice and conversational, it is often distracting and time consuming to have copy for successful inputs. Instead, focus on concise, directional, friendly copy for you error messages. Avoid long list summaries of errors at the top of your page, instead state there are errors on the page for the users to find by your obvious signposting.
uSwitch application
With our extensive help text, validation messaging on uSwitch was limited to ensuring the exact requirements were obvious. See below examples of requirements being clearly explained up front and validation messages that exactly describe what was not accepted.
Universal integration
As you have seen there are the best practices… then there are best practices that apply for you. Every site and application is different and the best way isn’t always possible with limited time, stakeholder interest, and resources. For this reason we had to sacrifice a lot of best practices for the greater good of easy to apply site wide application. This may lead to the question of why sacrifice some best practices just to fulfil one best practice of visible consistency across the site (most of which wont be seen by users). And it is a valued point that we at uSwitch have pondered over multiple time over and deserves a whole other article dedicated to it. The main reasoning though for universal application is ease in the long run. Better to have easily maintained rules that work for the user but aren’t geospecific than a scattergun of interconfusable, but locally superior, interactions that can be forgotten, outdated and worst of all…. Off brand.
So with all the above being so and hard to read, it wouldn’t do justice if we didn’t summarise our findings into an easily digestible 10 point list
The 10 rules of form validation
- Use Instant validation only for difficult to answer (and finite) questions
- When using instant validation display messages after the user has input answers (with a 10ms delay)
- Use red copy and exclamation mark icons for errors
- Use green and ticks for success
- Always explain the validation error in a written message
- For this message use positive and helpful language
- Use the holy trinity of colour change, message text, and icons for accessible validation
- Display messages directly above the question title
- Increase the highlighting erroneous fields by outlining input fields in red
- Ensure your validations work in every application and are always colour contrast accessible (use coloured backgrounds)
For form designs that try to follow the above guidelines, follow me on dribbble.
For more of my musings, follow me on twitter.
