Should form 'Continue' button be disabled if validation is incomplete?

Question

In forms we often see the 'continue' button inactive until all the required fields are complete:

^{download bmml source – Wireframes created with Balsamiq Mockups}

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?

Answer 1

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.

source:10 Usability Heuristics for User Interface Design

Below is an excellent example of this approach which also incorporates gamification logic and you can test the real thing here alongside other variations:

---

Error prevention

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.

source:10 Usability Heuristics for User Interface Design

---

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:

Match between system and the real world

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:

1. The form has limited number of fields and Users are able to see at glance which fields are missing.
2. There is visual emphasis on required fields and clear feedback when each field is filled (Goals that need to be met to activate button)
3. field labels are short and can be easily scanned, for example name, username, town/city etc which reinforces 1st point.

4. 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)

Answer 2

I would have to say that this behavior hinders user experience.

If you've ever read Don't Make Me Think by Steve Krug then you will quickly realize that this pattern is breaking the rule stated in the title.

One might ask, Why is this disabled?

There is no benefit to make a user jump through this hoop.

Basically what I am implying is that the user is greeted with a form which is not action-able and through discovery, or worse yet reading, they will have to figure out how to properly use the form presented to them.

A workaround for this would be to immediately draw attention to required fields but that would send them into a panic as they wonder why they were greeted with a bunch of red errors even though they haven't even touched the form.

Don't stop the user from performing their intended task of hitting the Submit button, it feels good to know that the form let's you try with minimal repercussion. A gentle error message stating "Please review the form errors highlighted in red" will suffice.

---

Other thoughts:

I am not sure which websites or pages your are frequently seeing this on but a quick glance of the first 10 "Contact Us" website forms found on Google seems to argue against your observation.

My two cents:

If I had to guess then disabling the Submit button has become a default feature of a popular validation plugin and "developers" are simply leaving it as-is.

Answer 3

we often see the 'continue' button inactive

I think this may be false. Read on!

For what it's worth, I'm updating some old research on sign up forms for popular websites at the moment, and have found that quite a small percentage - around 5% or less - disable the Submit button (whether that's the final sign up or a continue type button) until the data is deemed 'valid'.

After studying so many forms, it becomes a noticeable behaviour rather than invisible behaviour, when the submit button is disabled. This is why I think you may feel like you see it more often than you actually do.

There is also the added problem with disabled buttons, that unless the form does a remarkable job of validating the data on-the-fly without distracting the user at the same time, then it prevents the user from being able to see what's wrong with the content.

One site that does this acceptably is for a BBC ID

However, they make it exceptionally clear on-the-fly what is valid and what is not.

Another notable example of a sign up form that disables the button is MailChimp, but they only disable it until the password is acceptable - not the whole form - so you could enter a password and get the button enabled - with no other valid data in the form.

They clearly see the password as something that absolutely has to be right before you can consider submitting the form. The rest of the data is allowed to be validated on submit. They do not disable the submit button for log-in.

The Mailchimp sign up form is, in my opinion, exceptionally good in many ways.

GoDaddy is a third example of a site that disables the submit button. However, here they don't disable the button until the data is all valid - the fields just have to be non-blank - so one letter in each field will do.

Here the disabled button is helping the user to spot missed fields rather than invalid fields.

So in summary:

If you really want to disable the button until all the data is actually valid then the form has to be very short and exceptionally well validated on the fly. A long form will be too unclear as to what is wrong, and the level of validation needed would be overly distracting for all fields.

Doing so would put you in a small minority, especially for full validation - whatever the feeling is that you 'often' see it :)

Answer 4

One should not disable the button

Consider the situation from the user's perspective. Divide users into two groups

• Those that do not currently believe they can proceed, so are not looking for a way to continue
• Those who believe they are ready to proceed, and are looking for a way to do so.

For the former group, disabling the "continue" button is merely a visual artifact seen in the corner of one's vision. It is helpful, but no more helpful than any other graphic depicting the state of the form. For these people, a graphic change (such as an arrow that points to the continue button, or a highlighted continue button) is just as meaningful as a button turning from grey to black.

For the latter group, they believe the form is completed. A disabled button lets them know that they're wrong, but does not assist them in identifying what went wrong. They must now scan the entire form which they think is filled out correctly for whatever notation they missed indicating an incomplete section. This misses out on an opportunity to interact with the user. That interaction can help them find the sections of the form that are not fully filled out. Missing out on this interaction turns the form into a puzzle: "the webadmins know you did something wrong, but you have to find it."

Given that there are other ways of handling the graphical hint that a form is complete (I like highlighted buttons myself), and the continue button provides a way for users to ask for assistance, I see no reason to ever disable the button.

Answer 5

This is a meta answer drawing from the diverse opinions expressed.

If you want to disable the button, you should still check for clicks and give reason why it is disabled. This has two advantages: fewer errors are displayed, and if you for some reason did not previously communicate why the form can not be submitted, you can explicitly do so.

Answer 6

Buttons are meant to be clicked. If user sees a button, he would want to click. Disabled button becoming active only when all the data is filled in that specific form is not a good experience. I would rather tell user ( which i do with the forms i design ) right at the beginning that all the fields are mandatory and you cannot sign up if any of these fields left empty. Your form is not a game where user has to finish the level he is playing to unlock another one. Just a thought :)

Answer 7

A Form's 'Continue' button should be disabled until all required fields have been filled out and have passed validation.

Why? Well it's common sense, really:

Imagine you are a Bank. And you have a simple form setup which allows the transfer of monies from one party to another. You have a 'From which account would you like to transfer money?' field, a 'Recipient' field and an 'Amount to send' field.

If any one of those fields is not filled in, the transfer cannot take place. Therefor, all three fields are mandatory. Without the information from all required fields, there is no way this transfer can take place.

Now, what happens if we make all three fields mandatory, and indicate this to the user, and the user does indeed enter information in all required fields, but they make a mistake in the 'Amount to send' field?

Let's just say that the user entered 0.00.

Well, we can't send $0.00. If the backend is not setup properly to handle cases such as sending zero dollars, what could happen? When the user clicks 'Continue', not only does this cause yourself to lose bandwidth and time, but it also causes your user to lose bandwidth and time. And in Business, time equals money, and if many people are constantly making mistakes, or not entering in details when they should be, you'll effectively be creating way too much overhead for yourself (allowing too many resources to be used) and I bet that this will eventually cause mismatched data at some point.

Also, as a user, not validating a form and allowing me to continue without telling me that something is wrong is very annoying. Especially when the page refreshes and forces me to fill out everything a second time.

Answer 8

I believe there is a middle-ground. A visually disabled button doesn't have to mean that clicking it does "nothing" as suggested. It will logically prevent the user from advancing in the absence of whatever is required to enable that primary action, but there is no reason that clicking it could not present an alert message to the user explaining why it is disabled and how to enable it.

Answer 9

I will keep this short and to the point as most answers are already covering a lot of valid and good areas.

Does it add value?

I am not able to think of a case where the user will/should look at the continue button to know whether he has finished filling in a form. Whenever a user wishes to click the button he believes he has finished the form and directing him to any required actions is necessary at this point. In principle this should already be clear in a well designed form, but the fact that the user believed he was finished proves that this wasn't the case, thus focusing, temporary blinking or in some other way directing the user is a good plan of action.

What about validation that is not synchronous?

One thing that hasn't been covered yet is that a lot of forms are web forms or otherwise internet dependent and not all validation can be instantaneous. To give a typical example a registration form with a username: the username needs to be looked up in the database and if the username is already used the field will require a different username to be inputted. Normally this is an extremely quick look up, but what if the user is for example using mobile internet and just lost his connection or has an incredibly slow connection? With a disabled continue button the user will end up with a filled out form and no button to click on which is comparatively more confusing than clicking a button and waiting for the next page to load which such a user on a poor internet connection will be used to taking a bit longer.

Of course the above can be somewhat prevented if fields that are awaiting validation very clearly show this, but it's not typically done and if all fields are checked live on server side as is increasingly common then this might be just confusing the user: "Why is there a thingy spinning next to my full name?". So, if you wish to do this the only solution I was able to think of was putting a spinner in the disabled submit button whilst validation is running. The only danger of that is that the user might think he submitted the form already by mistake as a disabled button often is associated with a clicked/pushed state.

Answer 10

While designing some webpages, I came to this site to see what others had to say to make some decisions. I've concluded that the best answer is "it depends."

I thought about my own experiences with enabled buttons that do nothing but tell me what I did wrong and, sometimes on a poorly designed webpage, clear everything! I especially find myself annoyed when I'm on a long form and the error is at the top of the page...which I don't see until clicking on the Submit button several times and then scrolling up to the top to see the problem. Plus, not every website makes it clear what's required until the Submit button is clicked. Don't catch me on a bad day with a website that tells me after the fact that I have to enter something!

I think Webpages should be absolutely clear what is required on a form BEFORE I hit a button so that, if I hit the Submit button before entering a required field, I am thinking, duh, I can't believe I missed that, I knew it was required! On the other hand, I have to agree with Jase that I certainly don't want a Submit button enabled on my bank's website until I've entered all the required fields! I use my bank's website more than any other site and the disabled button has never caused me any confusion.

So, my conclusion? If you have an extensive form with multiple fields, some are required, some are optional, clearly mark all the required fields, enable the Submit button and, when the form is submitted with invalid or missing required data, highlight the problem fields and list messages with the errors. If you have a form where all the fields appear on the same page...along with the Submit button, disable the button and clearly indicate what the user needs to do to enable the button. The Submit button can also be enabled; however, either way should work just fine and provide a good user experience....herein lies the beauty of web design...it's up to you! Finally, know which way is more difficult to code as this may also help you make a decision one way or the other when either seems fine...keeping the costs down for the client should always be a consideration.

Oh...and how often does the typical user "disable" their HTML? I'm thinking that is not common and the average user (non-IT) does not even know how to do it so I don't think that is a good enough reason to take it into consideration when designing a user friendly website. If the user is smart enough to disable their HTML, then they should know they have to enable it for the website to be fully functional!! Happy designing! :)

Answer 11

Yes the "Continue" button should be disabled until all required fields are filled out with at least some text (this assumes that the required fields are designated as such to the user in some way). The affordance here is that the system cannot even attempt to continue until it has the required input from the user.

Once the required fields have been filled out, the "Continue" button should immediately be enabled indicating the system has what it needs to attempt to continue.

From there, clicking on the "Continue" button will run the full validation and may return validation messages to the user.

Answer 12

I think it's bad to disable it when it comes to native HTML form constraint validation. It takes away all usability out of form validation leaving you with just the validation.

Taken this simple form for example, when you fill something in to field a and press enter, nothing happens. You don't get any visible feedback. You don't know what is required by just looking at the visual UI.

<form>
  <input type="text" name="a" required>
  <input type="text" name="b" required>
  <input type="submit" disabled>
</form>

Where as if you would have the button enabled

<form>
  <input type="text" name="a" required value="sometext">
  <input type="text" name="b" required>
  <input type="submit">
</form>

Now if you where to press enter after having entered something on field a you get a popup and the input field also gets focused

---

Having a perfectly structured form validation without disabling the continue button

• You wouldn't need any javascript
• The page would not reload (thus saving bandwidth)
• You get good detailed feedback in your own language for what is wrong (talking numbers with step, min max added to it - you get something like: "enter a valid number, the two closest, valid numbers are x, y")
• The erroneously filled field also gets focused
• Doesn't make a user confused as to why they can't click it, in fact it's the opposite you now know what is wrong with the form