<?xml version="1.0" encoding="utf-8"?>

Users often need to change their details, either to update their email address, fix a typo in their name, or add a payment method. It's important to let them know what's going on at any point in their interaction with the system while they do so. Showing system feedback informs users that their work is saved and makes them feel in control. Seeing that changes have been accepted also gives them a sense of accomplishment.

Methods you use to inform users about what's happening in the system can depend on the stage of the process. The action button states, loaders, toast notifications, and banners are the most common ways to do that.

Exercise #1

Show the action to save changes

Show the action to save changes Bad Practice
Show the action to save changes Best Practice

Buttons are the most common tool to confirm and save changes. Make sure they're highly visible.

Where should the Save Changes button be placed? As users scan the content, their eyes move from the top half of the screen toward the bottom. When the content ends, they look for a call to action — so place the CTA button at the end of the content.

For browsers, make sure that the button is above the fold. Another option is to place the button right below the end of all the editable content. In apps, you can make the button stick to the bottom of the screen so that it's always visible.[1]

Exercise #2

Switch to active state once a change is made

Switch to active state once a change is made Bad Practice
Switch to active state once a change is made Best Practice

Users who understand what's going on in the system feel more confident and trust it more.[2] This is especially important while they're making changes.

The state of the Save Changes button is a good way to communicate system feedback. Display the button as disabled before changes are applied. When information is modified, change the button state to active in order to bring it to users' attention. This will communicate to them that changes have been made and are waiting to be saved.

Exercise #3

Action changes to loading state when pressed

Action changes to loading state when pressed

Keep users in the loop about what's going on in the system. After users change their information and press the Save Changes button, show that saving is in progress. This communicates that the interaction was successful, and users didn't waste their time.

A common way to show that changes are being saved is by using a loader — either as a CTA button state or a full-screen one. If the process takes a while, add a message stating so or some tips and fun facts to make the wait less boring.

Exercise #4

Notify that changes have been saved

Notify that changes have been saved Bad Practice
Notify that changes have been saved Best Practice

Once the system has saved the changes, the page will reload or update. Informing users about this ensures that they know their work wasn't lost. Use a success toast notification or banner that disappears after a while to inform users that changes have been saved. These can include an Undo functionality which is great for reversible actions or actions with minor consequences.[3]

Success messages should be visible but not intrusive. In the message, be sure to include a short description of what has happened.

Exercise #5

Add two-step verification when changing sensitive information

Add two-step verification when changing sensitive information Bad Practice
Add two-step verification when changing sensitive information Best Practice

If your product requires users to share sensitive information — like their credit card details — it most likely already has two-factor authentication. It's a security process in which users need to verify themselves twice, most commonly with:

  • A login and password
  • A security token (e.g., one-time passwords)
  • A biometric factor (a fingerprint or facial scan)[4]

Consider adding two-factor verification when changing important information, such as an email address, billing info, etc. This will ensure that users can avoid any unauthorized or accidental changes.

Exercise #6

When to autosave

When to autosave

Autosave is increasingly common in applications, and when implemented well, it enhances the user experience. It works best for settings that are easy to revert, like toggles and checkboxes, allowing users to adjust a single setting without reviewing everything. This approach feels natural — we expect a setting to take effect instantly, just like flipping a light switch. However, even with autosave, always provide a Save Changes button so users have the option to confirm updates manually.

When considering autosave, also analyze the platform your target audience uses. For example, macOS users are used to autosaving while Windows users aren't.

Exercise #7

Canceling or reverting changes

Canceling or reverting changes Bad Practice
Canceling or reverting changes Best Practice

Allow users to leave without making changes. Most users expect the changes not to be saved when they close the window or press the Back button, so avoid tying autosaving to these functions.

You can use a confirmation dialogue when users modify important information such as an email address or phone number without saving it. Make sure that the dialogue is short and straightforward. The headline should ask, or inform, about one main action we'd like to reconfirm. Avoid generic headlines for confirmation dialogues like "Warning" or "Are you sure."

Use unambiguous CTA buttons. The word Cancel isn't great when related to deleting or removing, as it's not clear what is canceled — the action or the cancellation of the action. Better options include Back, Stay, No, Leave, Quit, or any other action word that is instinctively clear in context.

Complete this lesson and move one step closer to your course certificate