The different types of “Saving” options — and how to choose the right one

@adamshriki

Our capabilities to perform complex operations with the help of digital products give us the feeling of having superpowers.

But as noted before, with great power comes great responsibility (🕷), so dealing with a large amount of information also requires a transparent, efficient, and user-friendly experience.

That’s why the operation of storing information in various systems is essential and we, as UX designers, need to take it very seriously.

In this article, I review the different options for saving information in complex systems and how to choose the best choice for the user.

View save

Positioned at the top-right corner of the view, affects the entire view

The Save button is positioned at the top-right corner of the view, and is in disabled mode by default.
Once a change has been made to view, it switches to enabled mode and a ‘Discard changes’ button is added next to it.
Moving to a different app page when the Save button is enabled will cause a confirmation dialog to prevent the user from losing data.

When to use:

• When we want to allow the user to have multiple changes without interruption
• When the changes have an impact on the way the product is used, for the user who made the change and especially others
• When the changes are sensitive and need an added friction i.e., a confirmation dialog

Single view tab save

Positioned at the top-right corner of the view, affects each tab separately

The Save button is positioned at the top-right corner of the view, in disabled mode by default.
Once a change has been made to the tab content, it switches to enabled mode and a ‘Discard changes’ button is added next to it.
Moving to a different app page or tab when the save button is enabled will cause a confirmation dialog to prevent the user from losing data.

When to use:

• When we want to make sure the user is very aware of the changes made in the current tab
• To reduce the cognitive load of the user with multiple tabs, by saving one at a time
• When we want to allow the user to have various changes in the tab without interruption
• When the changes have an impact on the way the product is used, for the user who made the change and especially others
• When the changes are sensitive and need an added friction, i.e., a confirmation dialog

Multiple view tabs save

Positioned at the top-right corner of view, affects all tabs together

The save button is positioned at the top-right corner of the view, in disabled mode by default.
Once a change has been made to the content of the tabs, it switches to enabled mode and a “Discard changes” button is added next to it.
Moving to a different app page when the Save button is enabled will cause a confirmation dialog to prevent the user from losing data.

When to use:

• When the changes in the tabs are related to one another and affect each other
• When we want to allow the user to have multiple changes in different tabs without interruption
• When the changes have an impact on the way the product is used, for the user who made the change and especially others
• When the changes are sensitive and need an added friction, i.e. a confirmation dialog

Creation save

Positioned at the top-right corner of the view, affects the entire process of creation

The Save button is positioned at the top-right corner of the view, in enabled mode by default and with a ‘Cancel’ button next to it.
Clicking the Cancel button or moving to a different app page when the Save button is enabled will cause a confirmation dialog to show up and prevent the user from losing data.

When to use:

• When creating a new object in the system that shows as a view

Microcopy Tip — help your users understand what they’re creating by having a more coherent button like ‘Create product’ instead of ‘Save’.

Side panel save (creation)

Positioned at the bottom-right corner of the side panel, affects the process currently happening in the side panel

The Save button is positioned at the bottom-right corner of the side panel, in enabled mode by default and with a ‘Cancel’ button next to it.
Clicking the Cancel button, moving to a different app page, or clicking the scrim when the Save button is enabled will cause a confirmation dialog to show up and prevent the user from losing data.

When to use:

• When creating a new object in the system through the side panel

Side panel save (edit)

Positioned at the bottom-right corner of the side panel, affects the process currently happening in the side panel

The save button is positioned at the bottom-right corner of the side panel, in disabled mode by default and with a ‘Discard changes’ button next to it.
Clicking the Discard changes button shows a confirmation element to prevent losing data.

Reduce unnecessarily high friction elements such as a confirmation dialog by having an inline confirmation element.

Moving to a different app page or clicking the scrim when the Save button is enabled will cause a confirmation dialog to show up and prevent the user from losing data.

When to use:

• When editing a new object in the system through the side panel

Autosave

In this example, changing the switcher doesn’t require clicking any Save button; it saves automatically

This is when the changes are saved automatically, as the user makes the changes without confirming the saving process.
Snackbar (or an inline element) should be shown at the end of the saving process, only if there’s new information for the user to be aware of due to the saving action and not the saving itself.

Usability Tip — autosave is relevant for the entire view, which means you shouldn’t mix autosave elements with save-is-required elements on the same page, as this might be confusing.

When to use:

• When the changes have no impact on the way the product is used, for the user who made the change and especially others
• When the changes aren’t sensitive and don’t need an added friction

Confirmation / save dialog

Positioned at the bottom-right corner of the dialog, acts as confirmation and as Save

This is both a confirmation and Save button, positioned at the bottom-right corner of the confirmation dialog.

When to use:

• When we can combine a confirmation dialog and save
• When the change the user has made is immediate

List item save & discard

Save and Discard buttons float at the right side of the list-item, and are shown only when in row edit mode.

These are Save & Discard buttons that float on the right side of the list-item, only shown when in ‘row edit’ mode.
Moving to a different app page when the Save button is shown will cause a confirmation dialog to prevent the user from losing data.

When to use:

• When we want to allow the user to edit and save the row solely
• When we want to enable the user to discard changes, unlike auto-save

As we can see, the process of saving data in complex systems is much more than just a ‘Save’ button and we, as UX designers, need to choose the best saving option to make our products friendly & useful.

Have any more Saving options you want to share? Please DM me, and I’ll add it.

Thanks for reading, and stay save 😉