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 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

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.


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.

The array of different validation stylings prior to our rethink on

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;

  1. Display at the right place: Next to the input in question
  2. Display at the right time of informing about problems/success
  3. Use the right colour: Red for problems green for success
  4. 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


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

Twitters excellent instant validation on right hand side of inputs

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.

Obviously aligning validation to the right of the field can’t be used on mobile anyway

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.

Example of a generic uSwitch form. Note the limited space for validation immediately to the right of inputs

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 google approach of validation b0elow the inputs

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.

Vimeos use of tooltips for validation

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.

Example of Facebook tooltip validation hiding surrounding information. Note how all error messages aren’t displayed at once due to this problem

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.

Example on of above the field validation

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

Example of this potentially confusing position

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.

Our eventual positioning of validation site wide

Display at the right time


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;


Success or error message is displayed after the user has clicked or tabbed out of input field

After example (but with tooltip) From Google


Messages are displayed as the user begins typing (or selecting)

During example on uSwitch

Before and during

Messages are displayed as soon as user focuses on form element and updates whilst they answer

Before and during (But with a more reassuring before message) From Twitter

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.

Example of use of instant validation being used only in definable sections. Most likely at the end of forms

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.

Examples of micro validations that notify the user before submitting but don’t overwhelm

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)


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.

Difference in our positioning and colour of validation messages before and after

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


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.

Examples of unclear and he unhelpful validation messages. From

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.

Example of informative and helpful language being deployed at uSwitch. Requirements are clear and present up front. Help text is always displayed. And error message is concise, exact and avoids negative tone.

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

  1. Use Instant validation only for difficult to answer (and finite) questions
  2. When using instant validation display messages after the user has input answers (with a 10ms delay)
  3. Use red copy and exclamation mark icons for errors
  4. Use green and ticks for success
  5. Always explain the validation error in a written message
  6. For this message use positive and helpful language
  7. Use the holy trinity of colour change, message text, and icons for accessible validation
  8. Display messages directly above the question title
  9. Increase the highlighting erroneous fields by outlining input fields in red
  10. 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.