1

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.

Split save button with Save, Save and Close, Save and Create Another, and Save and Schedule Delivery.

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?

2
  • 1
    split buttons aren't intuitive for many users, and I think being at the bottom of the layout with a down arrow probably adds some friction. What about replacing the arrow with 3 vertical dots? I think it's more indicative of a menu item. Otherwise maybe you could replace "Save" with "Save Options"
    – Devin
    Jun 21 at 20:01
  • To be honest I've seen this pattern being used many times, but for simple save options only. And I wouldn't say split buttons are horrible per se, just maybe not the most optimal for your case which has a lot more complexity to the selection.
    – Big_Chair
    2 days ago

4 Answers 4

4

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.

1
  • Thanks. I'd love autosave but that's not an option for us. We are going with [Close] [Save] and [Schedule Delivery], and close provides options about what to do next (Save and Create Another). I'll mark this as the answer since it's close to what we're going to do.
    – Izquierdo
    2 days ago
3

The answer is in this:

... not enough discoverability

Make it discoverable:

enter image description here

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:

enter image description here

1

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

enter image description here

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:

enter image description here

1
  • I like how consistently creative your answers always are... maybe someone can contribute them to Material!
    – Izquierdo
    2 days ago

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.