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.
