Forms are the gateway to an online business wrestling some of your personal information from you. For this to happen smoothly, this data has to be formatted in a way that allows the company to provide you with the good or service you want. Asking for a delivery to an address written only in numbers probably won’t work. Entering an email address without a domain will not allow you to be contacted.
It is in the interests of an online company for users to submit a form correctly, ideally getting everything right first time. To ensure that data is provided in a way the online business can use and understand, the form usually validates your data. This validation can happen in two ways:
Server-side validation - the data is sent to a server, which validates the data and sends a response. Languages used might be C# or .NET.
Client side validation is usually quicker, since data is not being sent anywhere. It can be used as a way to ensure data is at least correctly formatted before sending this away for further validation and checks.
For example if you were checking your eligibility for a credit card in a form, the client side validation would warn you if your email address was incorrectly formatted (test@test would be marked as innvalid) and the server side validation might inform you that you already have that email address registered with the checking service.
The simplest way to think about inline validation is that it happens as the user goes, delivering feedback as soon as a mistake is made, rather than in a group at the point where a user tries to submit the form.
Without inlinne validation in place, a user can make their way through a form, making errors aplenty without realising until they try to submit a form:
In the above example, the email addresses are neither valid nor match, but a user only know abou this when they try to progress to the next step. Given that they may have made many errors during their first attempt, they may receive many error messages at the same time, and potentially be overwhelmed.
Now over a decade old, this classic List Apart article by Luke W was a major influence on people’s attitudes towards inline validation. In the study conducted, they found that when completing a form with inline validation, participants saw
In May 2017, we asked 117 consumers the following two questions:
In short, inline validation is an effort on behalf of the form to help users correct information as they go, ideally so that when the point comes to submit the form, they are more likely to submit it on the first attempt. The more failed attempts a user makes to submit the form, the more likely they are to give up.
Sounds like a good move then, but there’s plenty of nuance in how to do inline validation well, and when it can be used at all.
Inline validation can be used effectively to help users correct certain types of errors, but not all. You cannot for example stop customers entering a perfectly formatted, but incorrect email address or phone number. However it can be used to to help
When it is less likely to be used:
Where is shouldn’t be used
Should you offer just the stick, or the carrot too? Inline validation can be used both to flag errors, and gives a digital thumbs up when data looks formatted correctly.
When a user makes a mistake in a field, and then a message is shown to them:
When a user successfully completes a field then they are notified visually, and when they make a mistake in the field then a message is shown to them
Whilst the above seems like a nice, positive reinforcement, it does carry with it risks. For example if my email address is firstname.lastname@example.org but I enter email@example.com by accident, a green tick appearing would give me the impression that my email address is ‘correct’. It is not - it is merely formatted correctly, but is not my email address. I might be less tempted to check over my entry if I’ve already been visually prompted that all looks well.
Sticking to the errors-only approach doesn’t fall into this trap - red flags are only raised in cases of formatting issues, but there’s not visual cue that my entries are ‘correct’.
It’s not an issue with a clear winner - in cases like this we’d always recommend testing different approaches and letting the data lead your decision making.
The most common and consistent way to display error messages is at the point that a user focusses out of an input into the next one. Before this point, you cannot be sure that a user has finished entering their data. If you try to correct too early, you may end up falsely telling a user they have made a mistake.
So you’ve displayed an inline error message - what next? A user notices their mistake, and refocusses back into the field in order to correct it. You have two options in terms of what to do next:
Each of these approaches have pros and cons:
Which approach works for you will no doubt be as a result of testing, and examination of the data.
Inline validation can help users correct incorrectly formatted data as they progress through the form, hopefully resulting in less attempts to submit the form for a final time. However it should not be used as a bandage, as your ultimate goal should be to try and help users avoid mistakes in the first place, especially if their ‘mistakes’ are simply a result of your form being unnecessarily inflexible in the data it accepts.
For instance, having inline validation on a phone number field is great, but if you are displaying a lot of errors telling users their number is invalid when a user tries to add spaces between numbers, maybe inline validation is not the answer. You should instead look to allow user to enter their data how they want to, and do the hard work yourself in accepting in.
Once you’ve chosen to add inline validation, it does not end there. You should be looking to continuously optimise and improve the delivery and content of these messages. Error messages in themselves are difficult to get right, regardless of the time at which they are displayed.