Is guiding a user through the flow of page with disabled buttons terrible UX?

Question

I'm working on a backend settings page on which users can add/remove members as well as add/remove/edit services associated with each member. All of the adding/removing/editing is inline.

Depending on the context, one of the following must be emphasised:

1. Adding a member
2. Adding a program
3. Editing a program

After fussing around with the page for a while, I wound up with a solution in which buttons for the non-emphasised functions are disabled until the primary function is completed. Technically, there's no real reason the user couldn't do one of the other functions first; they just wouldn't be able to leave the page until they complete the primary function. I'm effectively railroading the user to avoid user frustration later on, as the page could get relatively complicated, and there is a desire to avoid presenting the user with an error state as far as possible.

Is it better UX to not block the user and just deal with the inevitable error messages as gracefully as possible, or are the disabled (but visible) functions acceptable UX?

Answer 1

Generally, it’s okay to guide a flow with disabling, as long as it's truly absolutely required to do one thing before another (not just good practice or advice). However, it’s even more important to provide the user as much flexibility and fewest modes as you can.

You say the order of the functions is not the issue. Rather, the issue is to ensure the user completes Function X before leaving the page (where “X” is 1, 2, or 3 depending on the context). It’s possible that, unknown to you, it’s very helpful for users to sometimes do Function Y or Z before X. Therefore, focus on the problem: maximizing the chance that users complete X before attempting to leave the page, not forcing the user to do X before Y and Z. The usual techniques can be used in combination:

• If possible, put a workable default in for X, even if it typically needs to be changed most of the time (consider the “New Folder” default and “Old Filename - Copy” used by Windows).

• Clearly mark Function X controls as “* Required”.

• Consider placing focus on the main control for Function X when the page opens.

• Clearly show when Function X is completed (e.g., a filled field is evident)

• Disable the Save or Submit or whatever controls moving forward until the user completes Function X.

• Consider in-line documentation beside the leave-the-page controls reminding the user that Function X is required. This is necessary if it’s isn’t obvious to the user (and if it varies with the context, I bet it isn’t).

If the above proves inadequate in usability testing, or if you can’t disable the leave-the-page controls (e.g., it could be the Back button) then force the user to complete Function X when leaving the page, not before doing Y or Z. For example, when the user attempts to navigate:

• Open a modal dialog box or equivalent to take the input to complete Function X.

• Redirect the user to a page that takes the input to do Function X.

• Jump to and highlight the portion of the current page dedicated for doing Function X.

In any case, the user should have the ability to:

• Complete Function X.

• Go back and modify Function Y and Z input.

• Cancel work on the page altogether.

• If possible, save the work so far and return later (after they figured out what they want or need for Function X).

If all else fails, then use an error message, but you’re correct that that is the technique of last resort.

Answer 2

Don't block the user.

Layout the form vertically with the stuff that doesn't depend on anything else at the top and most users will fill everything in from top to bottom. Provide inline feedback as they edit their input so it's instantly clear when they need to change their input (or lack thereof)

If a situation arises where hand holding is necessary then I wouldn't even let the user see anything but the task at hand before showing them more.

Try and eliminate asking the user anything you don't absolutely require.

Answer 3

Enforcing a flow as opposed to dealing with an error than can be avoided is desirable.

Just make sure it is obvious why the disabled options are disabled (i.e. what needs to be done to enable them).

If it makes sense in your context you may consider hiding the unneeded options until the proper time. However going this route would produce other considerations to ensure good UX.

Answer 4

It depends.

If the program is for a tech savvy user, or a user that knows the effect of their actions, do not block anything. The user will want a free experience, that allows them to do whatever they want, error or not, because they already know what they want to do, and why they are doing it.

But, if the user is more basic, disable options that would cause errors, because they do not know what would happen if the did in fact clcick a disabled buton, and an error with technical gibberish came up.

As with most UX questions, it is normally based on your target audience.

---

Good Luck!