Rethinking form validation
We all know how important form validation is. Users must provide required information, users must provide information in specific format, user must… Right. But imagine the scenario in which user saves a form even if validation fails. That is, when inappropriate formats are provided or required fields are left blank. Sounds ridiculous? To kill validation? Well, no – we just might rethink the validation process.
My team had a debate about this topic when we first read Alan Cooper’s suggestions on data saving. We decided to try it in one of the projects. Developers hated it. Designers endorsed it. Users loved it. Let’s see why.
How should this work?
Here’s the scenario: user, who works in one of the bank branches, fills in the same forms every day. She deals with different forms, from simple to complex, such as leasing requests. If a customer doesn’t provide all the information necessary to approve the leasing request, which happens often, she won’t be able to submit the form and store it in central database. Sounds correct? Let’s try again.
User, who works in one of the bank branches, fills in the same forms every day. She deals with different forms, from simple to complex, such as leasing requests. If a customer doesn’t provide all the information necessary to approve the leasing request, which happens often, she can enter whatever information she has at the moment and store it in the central database. If some of the required fields are missing she is notified with inline validation that she needs to provide it later in order to process the request. If she enters some information in the wrong format she is also notified by inline validation that it should be corrected in order to process the request. But she saves the request. Incomplete, but she can save it.
User becomes more confident because she feels that she can’t make a mistake. No errors, no popups, no interruptions. She can easily save an incomplete leasing request and complete it later. When she opens the request again inline validation will show which “required” information is missing and what data is in the wrong format. Of course, the leasing request can’t be processed without information that is absolutely needed for calculations, so it can be processed once the form is completed.
Is required really required?
I deliberately placed the term required in quotation marks here, because required information isn’t required in the way we perceive it. Information is required for successful leasing request approval but not for storing the same request in the database. Same applies to data format. So, think again why some information is required – to defend database integrity or to support users’ goals.
Don’t take this literally
This can’t be applied to every single form. Of course, this makes sense mostly in so called enterprise web applications. For instance, it wouldn’t make much sense to submit a comment on my blog without providing the comment and name. So I’m not suggesting that you should make the worst example of web form validation ever. You get the point.
One thing is certain – this would be a headache for developers. Not only because they love to defend the database in any possible way, but also because such approach would require much more work on their side. But more important is that there would be fewer headaches for users.