Many save options, limited space

Question

The feature I'm working on has a lot of complexity. We believe our users would want to do the following:

• Save work in progress
• Save and close the item (to return to it later, or hand off to someone else)
• Save and create another item (for users who tee up a lot of items and then hand them off)
• Save and schedule delivery (for when the configuration is done, and ready to ship)

We tried designing a split Save button, but it was a massive flop in user testing for the task of scheduling deliveries - not enough discoverability.

This button exists on a global footer that would save content across several tabs. We likely have room for one more button (Save and Schedule Delivery is top of mind) but I'm wondering if this problem will also surface with the other Save options and we should abandon the split button.

How might we keep these options from taking up a large amount of screen space while also helping the user discover the options?

Answer 1

The reason your split button is causing discoverability issues is because Close, Create Another, and Schedule Delivery really aren’t different ways of saving. They’re different ways of proceeding to the next step in one’s work. Really, you have four separate commands (Save, Close, New, and Schedule) that a user can use in various combinations. So make them four separate ordinary command buttons all visible at once. No more discoverability issues.

[Save] [Create Another] [Schedule Delivery] [Close]

Yes, it takes more space, but you need to use more space because you've discoverability issues. Frankly, in your drawing above, it looks like you have the space to use, but maybe you're not showing additional buttons you need.

Separate commands like this may be preferred if users have a need or desire to schedule delivery or create another config (in a separate window) before they complete a given config. Why force them into a mode?

If the idea is to let users execute each type of “save” with one action, then that’s already defeated by putting it in a split button because that takes two clicks. You’d need four visible buttons anyway, so show them all:

[Save] [Save and Create Another] [Save and Schedule Delivery] [Save and Close]

If users understand that leaving the configuration always results in automatic saving, then you can drop the “Save and,” and the labels are back to:

[Save] [Create Another] [Schedule Delivery] [Close]

Even better, if you can automatically save all the time throughout the app (e.g., whenever the user changes a field value), then all you need is:

[Create Another] [Schedule Delivery] [Close]

Do you need Close? If this is a web or mobile app, probably not. Now we're saving space.

[Create Another] [Schedule Delivery]

But suppose you really need all four commands. If you really need to save space (e.g., for other buttons), then consider separating the “save and proceed to next” commands from “save and continue.”

[Save] [Proceed v]

Where the Proceed menu button opens a menu of Save and Create Another, Save and Schedule Delivery, and Save and Close.

If Close is the most common way to proceed, and users see going to scheduling or a new config as necessarily “closing” the current config, you might be able to get away with a split menu:

[Save] [Save and Close | v]

Where the split arrow opens to show Save and Create Another, and Save and Schedule Delivery menu items.

Answer 2

The answer is in this:

... not enough discoverability

Make it discoverable:

Answer 3

If every action is save plus something else, the application should save automatically like Google docs.

Here's an example of saving automatically and using regular buttons to avoid discoverability issues:

Answer 4

If the intention is to save space, a segmented button with the default action labeled and the other two with icons:

When making the first click or hovering in the desktop version, an animation can reveal the label of the pressed button, passing the one with the visible label to the active state: