27

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.

  • 9
    Do you have any mocks showing your effort so far? This forum is most useful when we can see what you’ve come up with, plus any constraints and context you can describe... – Mike M Jun 21 at 11:57
  • To clarify: you are showing these in parallel (outside the wizard's normal serial flow) because the user might need to do them in an order that you don't know yet, but they are short enough that they don't warrant their own intermediate state that can be saved over night? – Simon Richter Jun 24 at 10:47
  • In the Wizarding World, a similar question was entertained: Should the doorways to rooms be absent until the host deems it appropriate for them to appear? It was found to create a great deal of panic, and in one case, a witch unleashed a powerful fireball spell, injuring many. Fortunately no one was killed in the incident. Although some still debate the issue, it seems most agree it's generally a bad idea. – 習約塔 Jun 27 at 20:09
60

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!

  • 26
    Option C could would also be problematic for users who think they have completed all the tasks, but actually have not - there's no way to convey the message of "you're not done yet", which is achieved by both A and B. – Nuclear Wang Jun 21 at 14:51
  • 26
    Rather than a popup when they click, it would be better to just always show the disabled-reason (usually somewhere near the button). It's not common for users to click disabled elements, nor for disabled elements to actually do something. – BlueRaja - Danny Pflughoeft Jun 21 at 19:13
  • @BlueRaja-DannyPflughoeft Seconded. I like to display the reason a button is disabled if you hover it. – Loren Pechtel Jun 23 at 0:14
28

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.

  • 1
    I want to add that another reason that you may want to hide things is that it takes too much space doing nothing in your UI. Of course that doesn't apply here. – Imperishable Night Jun 23 at 18:44
  • 1
    This is worth more than one vote :) You basically explained everything I wanted to explain in my answer if I had the time. Discoverability can also make an application more fun to use and give people confidence using it. Disabling components will only take that down. – jazZRo Jun 24 at 9:21
  • I'm not convinced, first the argument of extra engineering can be easily apply to what you suggest also, you would need every action of the type "apply the action <X> to the selected element" a message saying "please select an element to apply this action on it". Furthermore indicating by disabling a button that the user must for instance fill a form, or select an element is far enough. Having him thinking he can click when it won't do the expected action can could also be considered frustrating (at least for me it would be in some case). So I think it's a matter of opinion here – Walfrat Jul 11 at 11:01
6

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.

  • 2
    "If the tasks are mandatory, and they should only be so for features that enhance the experience" – They should be mandatory when it's not possible to continue without the info. Mere enhancement should be optional. For instance, certain address fields are required because it's impossible to ship items without them. However, something like a phone number merely enhances the experience when there is a delivery problem and the buyer can be notified. – 習約塔 Jun 21 at 19:46
  • You know what I meant. – DarrylGodden Jun 27 at 10:10
5

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
1

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.

1

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.

1

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.