Should form 'Continue' button be disabled if validation is incomplete?
In forms we often see the 'continue' button inactive until all the required fields are complete:
Is this actually a help to the user, or a hindrance?
I imagine the Pro for this is that it's a visual indicator to the user that they haven't finished filling in the form or dealing with errors (because even with inline validation a user won't be informed if they've never actually interacted with a field so won't show any errors for those at that point).
But then the main Con for this (which I've also seen borne out in usability testing) is that users will be confused why they can't click the button.
Is the pattern of disabling the Continue button until validation is complete actually providing a negative user experience?
Personal experience: In 90% of the pages the validation has some annoying bug, where I need to click in all fields again or reload the page just so the dumb button gets enabled! Examples: Login with autofill from browser (JS doesn't recognize autofill and button is disabled until I focus the PW field) Adress validation: Postal-Code is invalid for the current country, I change country, but the postal code field stays red until I click it again... You will probably never get it a 100% right, so don't annoy your users
@Falco: That doesn't mean the principle is wrong, only that the implementation often is.
The problem is that most, if not all, websites that I can think of that let you submit invalid information end up refilling only a subset of the information the user had previously entered, whether the entered information is valid or not. In particular, with regards to having to re-enter the password and the password confirmation fields. THAT IS WAY BEYOND ANNOYING and I believe death by firing squad is too good for the developer who decided that is how things should work. So if you are in that camp then lucky for you that I am not the king because your lifespan would be very short:)
@Dunk I think clearing out the password field is a security feature and is built into the 'password' field type though. It's designed to be cleared out on reload. Not sure the full reasoning for that though, but it's not a conscious decision on the UX designer part for it to work like that, it's down to HTML standards.
@Dunk I agree with JonW I have had a number of conversations around this with our Information Security Officer and Devs and ended up not tackling this particular aspect though I suspect their are ways around it, This post might have an answer
I don't disagree that it shouldn't work that way from the security feature aspect after a submit. Thus, it gets back to the programmer not allowing the operator to submit unless the data is valid. I've had occasions where I submitted 4 or 5 times because the reason for the error wasn't clear enough, having to retype the password twice each time. Now, I don't like if it happens even once. Falco said "don't annoy your users" as a reason for not disabling. I say that enabling users to submit invalid data makes many users WAAAAAAY beyond annoyed. Firing squad becomes a viable option in the moment.
There is no indication in the question that the poster is talking about a web based application, except in the comments where HTML standards are mentioned.
The question arose because of seeing this on web based forms, but the problem itself isn't specific to that. (I doubt the answer would be different for application based situations compared to web based ones).
@Oka:Sure, firing squad is a bit much now that I'm not irritated by the web site. But at the time, it was a righteous and just punishment:)
Type of the information captured and number of fields required
It really depends on the type and scope of the information you are asking for and the number of fields that need to be filled:
I have tested and used this pattern successfully in login and and password creation. I think because the interface is so simple and the number of fields required limited there was no ambiguity with regard to the information needed to activate the continue button.
(In my opinion) users are generally task focused so getting-on with the task comes first before they get to finalising any task by committing to action.
As an example consider the case of a create password page with specific password requirements (the situation I have designed for). In this particular case I have disabled the continue button until all the rules for the password were fulfilled, the caveat being that the user needed to get visual feedback as they typed their new password and saw their input fulfil all password requirements.
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Below is an excellent example of this approach which also incorporates gamification logic and you can test the real thing here alongside other variations:
As a general rule I try to avoid (where possible) error messages which add to user frustration and erodes their confidence. So instead of displaying an error message by keeping a continue button active I would attempt to actively convey hints and information about the required fields when and where possible.
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Inline validation: providing error messages in context
Below is another great example of a simple form with disabled button, Fields are validated inline and the disabled button "shakes" to indicate form incompleteness. Also, with regard to your point:
Even with inline validation a user won't be informed if they've never actually interacted with a field so won't show any errors for those at that point
Any interaction with the form translates to either progress (tick) or (inline error message). The only case where this will not work is when the user clicks on "sign up" without providing any information which is highly unlikely/irrational behaviour and you don't have to cater for it.
If you are dealing with longer and more complex forms, it's worth every effort to structure your form by chunking the information required in a meaningful manner and introducing a staged process/wizard or similar pattern if relevant. This will help optimise your design and to keep it focused on error prevention.
Content of error messages
The other area you may need to consider if "Submit" or "Continue button" are enabled is:
This might be an edge case but its worth mentioning nonetheless ; consider a typical login form with login button enabled and the user clicks on login without providing any details, what would the error message tel the user without breaching system security: The simplest message I have seen, read the following: "Invalid username or password"
This is a clear mismatch between what the user has done and what the system feedback to him. So in this specific case I would opt for disabling login button until required fields are filled.
When could a disabled button be used?
The aim of a disabled button is to preempt and prevent error messages and they can achieve this in an optimal manner when:
- The form has limited number of fields and Users are able to see at glance which fields are missing.
- There is visual emphasis on required fields and clear feedback when each field is filled (Goals that need to be met to activate button)
- field labels are short and can be easily scanned, for example name, username, town/city etc which reinforces 1st point.
All fields are mandatory as it offers a clear path for users to activate button and commit to action*.
*It seems to me that when there are optional fields users might misinterpret what is actually needed to activate the button though I don’t have evidence to support this.
Is the disabled button a hindrance?
It is clearly not. Its a helping hand that embodies an old maxim "Prevention is Better Than Cure" but it does come with caveats and requires weighing some of the factors I have mentioned above and testing it with your target audience to make sure that it does what it is intended to do.
Designing For People not Machines
Error messages punish people for not behaving like machines. It is time we let people behave like people. When a problem arises, we should call it machine error, not human error: the machine was designed wrong, demanding that we conform to its peculiar requirements. It is time to design and build machines that conform to our requirements. Stop confronting us: Collaborate with us.
Source: Don Norman: Designing For People
I guess that the point I am trying to make is that “users” are people just like all of us and we should not underestimate their intelligence and treat them condescendingly:
- They will Read & understand labels if these are clear, legible and concise
- They will check for what is needed from them if the form is well structured and inline with what they want to achieve (task-focused)
@JonW "it depends"...The whole thing was already heavily caveated! Thanks for obliging me to review it ...again:)
The password example is good from a UI perspective, but it's important to note that, by that site's own acknowledgement, "these criteria, to reiterate, are suboptimal". For passwords specifically, arbitrary restrictions on what a password must contain are likely to backfire. (E.g. I can't use correcthorsebatterystaple with those requirements in place.)
@Ajedi32 I happen to be in agreement but in some cases, for example enterprise solutions there is no way around this as you have to deal with a lot of legacy security policies over which you don't have control. Guess you have to make the best out of a bad situation!
I had a scenario where users had to agree to the terms and conditions by checking a check box before continuing. The instruction text was there, but no one bothered to read it and they couldn't understand why the button was disabled. So I switched it to an enabled button with a Yes/No prompt and that was well received. I think the point is that you want to guide users through the process as much as possible.
I agree with most of this -- the important part is to make sure it's CLEAR to the user WHY The continue button is disabled if you're going to do it that way (which I feel is better than waiting until the user clicks it and then generating an error and making them go back).
*"Any interaction with the form traslates to either (tick) or (inline error message). The only case where this will not work is when the user clicks on "sign up" without providing any information which is highly unlikely/irrational behaviour and you dont have to cater for it."* - Note that this falls foul of the point Falco made in a comment above: "Login with autofill from browser (JS doesn't recognize autofill and button is disabled until I focus the PW field)".