On a wizard form I have the navigation, save, and cancel buttons.

Currently I disable the buttons according to the context. The save button is enabled when the user actually can save (ie, last page).

The QA Technician is telling me that the buttons should be hidden. I don't want to do that; because they are right aligned, the "back" and "next" buttons would be changing positions and I can't imagine that as a good thing.

So, should I actually hide those buttons? I've been reading about wizards but haven't found any place mentioning this particular situation.

Edit - Including sample of the page I mention.

Main page, modal window with a wizard

  • Can you save in any page, or just in the last one of the wizard? Nov 30, 2014 at 19:27
  • and what is the business owner telling you? what is "next" after the last page?
    – Aprillion
    Nov 30, 2014 at 19:34
  • 1
    Can you clarify why hiding buttons would cause them to change position?? Nov 30, 2014 at 22:50
  • Related reading: Should disabled options ever be hidden?
    – Matt Obee
    Dec 1, 2014 at 11:58
  • @rewobs, In my case I can save only on the last page. Dec 2, 2014 at 17:01

5 Answers 5


No, they should not be hidden, and not only because of consistency, although that is important, but also because if you hide them, you will hide what system can do from user. User should know Saving is generally available, even though it is disabled at the moment (therefore there are some conditions user must comply with to enable this functionality).

However. Since you mentioned the position of one button will be affected by presence of others, I hope the string of buttons you are talking about doesn't look like one range of operations. Navigation should be separated from operations (Save & Cancel). Otherwise it's really easy to click the wrong button or abort the whole wizard with lots of filled in information when you only wanted to go a step back.

So not only they should always be on the surface, but also they shouldn't be grouped by positioning.

Good example Good example

Bad example Bad example

  • Since I started working as a developer (Windows native applications) I've always tried to follow Microsoft's patterns to achieve consistency. Curiously, the wizards on Windows pretty much follow the pattern on your "bad example". But I agree with you that navigation should be separated from operations. I'll refactor that when I have the chance. Jan 3, 2015 at 15:06

As a user I would prefer the Next button to change to Save on the last screen.

Short of that, I would prefer disabled Save with a tooltip explaining why it's disabled.

Although, it is possible to have < Back and Next > buttons on a separate row, so they don't move when a new button suddenly appears in the next dialog..


Based on the brief, initial details you've shared here, I recommend definitely not hiding those buttons, even if they're not immediately relevant to the user in whatever view from the wizard you're considering.

Whenever we can provide users with contextual, visual queues that do not distract from the overall goal action, but actually enhance it, we should. I think that this case definitely applies here as it will help to orient and prepare the user to finalize the goal action well before the final click is required. After all, the wizard is useless unless users complete it, correct?

That's what I'd share with the QA technician, I guess. Or, you could sarcastically ask them if they're the one's actually hired to design UX, and go the disgruntled designer route! (Always a personal favorite ;) Best of luck!


The question I would ask him is

What are the particular downsides to designing it the way I suggested

The changing of back and next buttons is never really a good thing in a series of steps. The key word is consistency.

Definr defines consistency as:

  1. Logical coherence and accordance.
  2. A harmonious uniformity or agreement among things or parts.

You cannot really be coherent if you move the buttons around. Users have an idea as well where these buttons should be and this idea is based on using a ton of systems over years.

I suggest you look up best practices for Wizards as well before designing it (just in case you haven't).


I'm going to go the other way and say: Hide buttons that are unnecessary. Keep the visual bloat as minimum as possible. To me, a disabled button means that I need to select an option to enable it. An example of this is to check the "I read and accept the EULA" checkbox, which must often be checked before the Next button becomes available. Another example is choosing what you want to install, and when nothing is checked, the Next button will often be disabled.

In this case, the action to enable the button is not available within one screen, but instead the user must travel through multiple screens to enable it. In my opinion, this means the Save button should not be on every page.

The standard option, used in most installation packages or wizards, is to replace the Next button with Install (Or in this case, Save). To to me, that's the best option.

This will also cause less confusion for customers, as they won't have to worry about what Save does and actually means. If the Save button is available (even if disabled!) on every page, the button could have multiple meanings, like "Save progress within this Wizard". Seeing as you don't want that confusion, I see hide it or use the "industry standard" of just having Back and Next, and replacing Next with Save on the last screen. (Just like the first screenshot in Zoe Kulsariyeva's answer by the way)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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