I am re-designing an online platform and we've decided to introduce autosave for settings. I understand it's important to communicate the autosaving feature to the user. This seems to be typically done by notifications/messages at the top of the screen/top bar or at bottom right, sometimes with an undo function.

Our developers are under the impression that it should be done in line with the eg. the checkbox. Maybe with a green checkmark-icon appearing next to it temporily or the checkbox flashing green for a second or a tiny spinner or something similar.

I failed to find any examples of such approach. Are you aware of any? Is it a good idea?

Any advice appreciated. enter image description here

  • 4
    If you're going that route, imo it would be better and less ambiguous to write "Saved" where the green checkbox is. Commented Nov 28, 2022 at 11:25

3 Answers 3


I think your devs might be worrying about a problem that doesn’t exist with users. That’s why you don’t see it being addressed in the UIs for other apps. There should be no need to indicate that autosaving is occurring with the change of each checkbox or radio button. The app should be able to post the change immediately after each click, and the save should be complete in a second or two (if not, you need to up the performance of your servers). Unless the users can simultaneously see the effect of the change somewhere else (e.g., the user changes a setting that, after being saved, affects the appearance on the same page or another open window), the delay between clicking and the actual save completing is irrelevant to them. As far as the users are concerned, they click and it saves. Don’t clutter and confuse the UI with technical backend details the user doesn’t need to know.

As far as communicating autosave in general, that may also be unnecessary, especially if it’s a mobile app, which commonly have autosave, and the users might be expecting that anyway. However, if users aren’t expecting autosave (like in your case, where users used to have to manually save), they may be confused or anxious by their inability to find the Save button. For that, you only have to indicate that the autosave feature exists, not necessarily when it’s occurring. Put static text “All changes autosaved” where the Save button used to be in order to educate users that they don’t have to worry about saving anymore.

Generally don’t add distractions like notifications or animations each time autosave occurs. The user should be able to assume that the saves were completed successfully and promptly. The user doesn’t need to know that autosaving is occurring at a particular instant. It shouldn’t prompt a change in interaction. As far as users are concern, it just happens. Ideally, users’ whole mental model will simplify to see themselves as making direct changes to the system (like flicking a switch on a physical control panel), rather than changing a local copy that later replaces that in the system. Use notifications for only the rare cases when autosave fails and the user has to intervene (e.g., regain a connection to the internet).

When devs come up with a new feature, like autosave, there is a temptation to show it off to the user. Implementing something like autosave is a lot of work, and the devs justifiably want their users to be impressed. Sadly, the users don’t care and won’t be excited to see a “saving” graphic appear beside each checkbox they check. This is a case where a more advance UI is less UI.

The only reason to indicate each autosaving event is if it’s inconsistent due to technical limitations. For example if some controls have autosave (like check boxes) but others can’t (e.g., text boxes). Or, sometimes the user has to manually save because for some reason autosave can’t work. Or, in many situations, autosave has a long delay or is otherwise unreliable, and this affects subsequent user actions or experiences. In these cases, you may need to show exactly when and for what autosaving occurs, perhaps even for each control, as your devs recommend. However, inconsistently performing autosave, like most inconsistencies, is a UX Bad Thing, and indicating each autosave event is only mitigating a bad experience. If you must have such inconsistencies in your autosave, you may want to reconsider if it’s worth having at all even with your mitigations.

  • 1
    This is an online platform and anything involving a network should be considered unreliable. Commented Nov 28, 2022 at 15:09
  • 4
    How unreliable? If one in a 100+ save attempts fail, you're probably still better off only indicating when a save fails, not when it succeeds. If save fails more than 1 per 100, fix or replace the network. That's unacceptable performance by today's standards. If your users must frequently use the app offline due to environmental reasons beyond your control, consider an "offline mode," which may indicate each datum that isn't posted but more likely just indicates that posting has been deferred until a connection is re-established. Commented Nov 28, 2022 at 15:29
  • 1
    @JacobRaihle Thanks for the thorough explanation. We do actually plan both autosave and manual save present on one page. Can you please see this example and tell me if you find it inconsistent? In the content area users can either update checkboxes (which autosave - 'save message' at the top) or click the Edit button, which opens options in the right hand panel. For those changes to update the content area, the "Save changes" button at the bottom of the panel needs to be clicked (those require validation).
    – Joanna
    Commented Nov 28, 2022 at 21:55
  • Thanks for the example. The inconsistency is that some controls require Save while other controls don’t. From the users’ perspective, they are distinguished primarily by whether they are on the left versus right. That’s a very arbitrary distinction for users to recognize. Find a way to check and show validation with each entry, rather than using a Save button. If that cannot be done, then I’m with your devs: you need to show which controls do and don’t need saving so users know when they should or shouldn’t look for a Save button. I’d recommend something obvious like Luke Sawczak suggests. Commented Nov 29, 2022 at 0:29

I think this is what your developer was referring to?

"saving changes" with spinner and "next item" button disabled; it becomes "all changes saved" with checkmark and enabled button

  • I am not sure, it was very specific to selecting check-box or a radio-button. I added an image to my original post. That's what they described. So it would be one icon per check-box.
    – Joanna
    Commented Nov 28, 2022 at 9:11
  • I don't particularly want to. I am just trying to see of there are actually reasons to go in that direction or not. And if not, why.
    – Joanna
    Commented Nov 28, 2022 at 21:58

Basing discussion solely on the assumption, irrespective of where it comes from devs or uxers is the wrong approach, if you test both options with a few users will be better.

Regarding your question, inline messaging for status changes or auto-update is very uncommon but not unheard of. Still, it's certainly not the best approach as it relies on the user noticing the tiny message/icon that suddenly appears next to the checkbox.

It will be best to use snackbar as you mentioned because that grabs the user attention and reassure them that the task was performed.

Inline status update message I can only remember from oneDrive setting (not a good experience though).

  • Thanks for those points! Their idea was actually that the user is looking at the checkbox, so that's where they expect the confirmation and that they wouldn't notice if something flashes at a different part of the page.
    – Joanna
    Commented Nov 28, 2022 at 10:40
  • 2
    Generally, for actions like checkbox and radio buttons user don't wait or keep looking at them but will move on next action (common pattern) but it depends on window size too as if all action could be glanced in a small window, probably they will notice. As snackbar or toast is always shown at a certain position and will always grab user's attention as its sticky that the point of it.
    – Vicktor_IV
    Commented Nov 28, 2022 at 11:17
  • That sounds very logical, thank you.
    – Joanna
    Commented Nov 28, 2022 at 21:40

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.