Should I hide continue button until tasks are completed?

Question

In a multi-step wizard, some of the steps present the user with a list of tasks that must be completed before continuing to the next step.

Each task in the list opens a popup where the user completes the task.

I have three possible solutions for the continue button:

a) Show it all the time. If the user clicks it before all tasks are complete the user will be shown information about what must be done before he can continue.

b) Show a disabled button, that is enabled when all tasks are completed. In its disabled state, the button will have some generic message that all tasks must be completed before you can continue.

c) Hide the button and only show it once all tasks are completed.

Answer 1

My web app has the same workflow and we show a disabled version of the Continue button which is enabled when all the form fields have been entered. If the user clicks on the Continue button without entering all the info, a user message is shown in the pop-up, so I think B is the best solution.

Option A can be frustrating for the user because they might click on Continue and get error message. The disabled Continue button provides a conventional visual cue that they need to complete the tasks before they can move on.

Option C can prove confusing to the user because they won't know there's a next step or if they can continue. Also, it's not good practice to hide primary navigation controls Hope this helps!

Answer 2

It is an anti-pattern to visually disable affordances, functionally disable affordances, or hide affordances. PLEASE don’t do it. I will make a case for all three.

Disabling or hiding affordances is one of my biggest pet peeves, especially since it is a case of over-engineering the solution:

• It’s always extra engineering and design effort to hide or disable anything intermittently.
• The client-side data validation is only one of the myriad ways that saving the data (or other end result) could fail, so even if client-side validation passes, and you now “show” and “enable” your button, there could still be an error when the user clicks Continue, and you still need to handle this error in a nice way. For example, server-side validation could fail, there could be a networking or other server failure, there could be an on-device filesystem error, etc.
• Sometimes the client-side validation is incorrect (outdated or buggy) or simply fails to “show” or “enable” the button at the right time. This would completely block a subset of users, and it’s difficult to detect this kind of error — typically you’re waiting for a user to contact support and for that information to flow all the way back to the people who can fix it.

In summary, your extra design & engineering effort is creating more risk than value. Even if you think you can 100% mitigate the risks, it’s still an anti-pattern, as explained below.

————————————————

From most-offensive to least-offensive:

Why shouldn’t you hide affordances?

First of all, why should you hide something? You should hide things for privacy or security purposes. Now why is the affordance there? It serves two purposes: communication about the utility of the application, and a mechanism for the user to communicate their intentions and beliefs to the application. So you shouldn’t hide affordances unless you are trying to make the utility of your application private or secure. Let’s assume at this point that you’re not trying keep private or secure the fact that your application has the capability of Continuing, and so you have made the button permanently visible. At this point let’s note the advantages of an affordance being visible:

• The user can discover it — they can learn about the capabilities of the application.
• Knowing the capabilities of the application provides motivation to use it and complete tasks on the way to accomplishing those capabilities. E.g. they are more motivated to fill out the form because they know that at the end they can “continue”.
• Experienced users know where to find it, and — this is a bit funny — but knowing that you’ve found it, even if for some reason you are not allowed to use it right now, is really important and satisfying to the user experience. If you can’t find it, you wonder if it’s moved, or if your memory is failing you, and you usually end up looking around for a while, and eventually losing trust in the application. Did they delete the feature? Is it broken? Are they going to move it around every few months?

Why shouldn’t you functionally disable affordances?

We touched on this in the previous section. This comes down to the second purpose of an affordance: as a mechanism for the user to communicate their intentions and beliefs to the application. This is a major point of confusion. Most designers and developer take the affordance at face value: a button that says “continue” will continue when you click it, or a button that says “delete” will delete when you click it. This is the ultimate goal, but the button is so much more than that. By clicking a button, the user is communicating one or more of the following:

• they intend to perform an action
  • Capturing the user’s intention is a downright miracle. You should absolutely use this information to your advantage — you have a ready and willing user on your hands. Guide them through the funnel.
• they believe the action will occur when they click it
  • The user just conveyed something to you that they have no other way of conveying other than by clicking the button: they believe they’ve satisfied the criteria for performing this action. If they haven’t, this is the perfect opportunity to guide them, and the best time to communicate with them, because they are actively interacting with the application.
• they believe they’re supposed to click it
  • Maybe they’re a new user with a different past experience, or maybe they’re new to the internet (no joke), or maybe they’re a little fuzzy today (or every day). But for some reason they clicked this button thinking it would do the thing. It won’t... but again, this is the perfect opportunity to coach them to success — obviously they already scrolled through all the other communication in the UI to click this button. The button got their attention, so steer their attention to the thing they should actually be doing (whatever they need to fix).

Finally, Why shouldn’t you visually disable the affordance?

Simply because a disabled affordance is not an affordance. Since you went to the trouble to match the visual style of buttons that don’t do anything, you successfully communicated to the user that it doesn’t do anything. Therefore it won’t catch their attention, they won’t believe they’re supposed to click it, they won’t believe it will do anything, and therefore they don’t believe they have a way of communicating their intentions or beliefs (or confusion) to you. They might look around the page for something else, but what if they keep missing it because of some other UX failure or code failure? It would be so much easier and faster to click the button which they believe they are ready to click, and then you could give them clear guidance about what to do next. In other words, the user is “lost” in the interface rather than “early” to click the button.

Answer 3

If the tasks are mandatory, and they should only be so for features that enhance the experience, like selecting the colour of a jacket before proceeding to purchase, then my advice would be to have the button visible, but disabled.

This combined with good use of tagging fields as optional, and messaging, should allow your users to complete the steps without issue.

Yes, we don't want to annoy people, that doesn't mean to say we shouldn't use controls to ensure that the expected result for the user is correct and they aren't annoyed by getting to the end of a process and having to return to a page to complete an action we hadn't enforced, even though it was required.

Answer 4

Frame challenge: most of the time, multi-step "wizard" workflow that won't let you continue to (or even see) what it's going to ask you next until you finish what it's asking you for right now is user-hostile and is a dark pattern. To the user, it feels like they're being asked to give information before they know whether doing so is going to be beneficial to them, or whether they're going to be able to carry through with the whole operation - it may turn out they don't have additional information they'll need at a later step at hand, or that a later step will tell them they don't qualify to continue.

The right UX, if putting everything on one page is too overwhelming, is a paginated process that:

• lets you move back and forth freely without entering all the information
• makes it clear that you can do so
• makes it clear to you when you've omitted information that will be needed before you can finish the whole process
• makes it clear whether your partial work will or can be saved if you abandon the process or set it aside until later

Answer 5

Where is option D? Show the button in enabled state and also show instructions that make clear that the form must be completed before you can continue. This way you let something to discover. The user could (and should) have read the instructions, but if he doesn’t, he can still click the button and get some feedback what to do next.

I advice not to shout any alerts or error messages, but politely show or flash the instructions again or show additional information what has to be done. For screen readers you might want to use aria-live=“assertive” as it has some priority to know what happens after the click.

Answer 6

I recently worked on a similar multi-step wizard that helped medical practitioners find the right medical licences to apply for.

TL/DR: we went with deactivated button option.

Since we followed a progressive step-by-step approach where the response to each question guided the subsequent questions, the 'Continue' CTA needed to be after each response. Please note that all the questions were mandatory on this flow.

For this we user tested the following two approaches

1. Showing an active 'continue' button that shows the 'active' state - no matter what.
2. Showing a disabled 'continue' button that becomes active when the user has made the single action/selection necessary to proceed.

We did not test the third option of hiding the 'Continue' CTA because we essentially thought this to be a non-intuitive with insufficient reflection of system status.

Our findings were as follows:

1. The second option (deactivate button until it's relevant) provided a visual cue to the users on the actionable areas to focus on.
2. If the users tried to click on the deactivated button (which happened very rarely), they would intuitively go back to the question because of the hint that the deactivated (faded) state provides.
3. Keeping the button always active throughout (option 1) confused the users because they would click on the button without actually answering the related question and the subsequent error message introduced hesitation and slowed them down.

For these reasons, we went with option 2 (deactivated buttons).

Some things to keep in mind when going for option 2 (deactivated button)

1. It is ideal for flows where the inputs are only closed vocabulary selections (radio buttons, check boxes etc) and not text inputs. Because with text inputs, the machine would not know whether the form is truly complete in order to activate the 'Continue' button.
2. The button should be visible when the users are engaging with the question so that the users can see the button's status changing.
3. Also, it is ideal for flows where each stage has just 1 question, to make the interaction of 'Continue' button consistent. (ie: you get the next question only after clicking on continue).

Hope this helps!

Answer 7

I think the second approach is the way to go. The user then already knows where he can continue and that there are more steps coming.

the third approach can work aswell, I would need to see some mockups for this. It can be really elegant, but the danger of confusing the user is there. I think the second one is save, reliable and user friendly.

Answer 8

Pain points of having the Disabled Continue/Next button:

1. Users play guessing game where is the missing field.
2. User will think it’s a bug - thinking they already filled everything.
3. Possible drop conversion rate, they loose confident of.
4. If they fill in and made a mistake, they still need to correct that error back, meaning they need to scroll back to top.