I developed an LMS web application for which I decided to go with an autosave-based user experience: there are several different editable resources in the application (quizzes, lessons, exams, announcements, and so on) and the general feeling the application gives is a save-button-less flow where:

  • when you create a resource, the resource is immediately created on the server in draft mode
  • any change you make to the resource is automatically saved to the server
  • most resources have nested resources that are also automatically created and saved during editing of the parent (think of a multiple choice question that allows creating its choices inside of an editor; an example of this is Google Forms)
  • you still have a "Publish" button, which essentially just modifies the state of the resource

I'm trying to figure out whether it's bad UX design to have changes made to such resources when editing them auto-saved just like when first creating them.

I have some resources that are modified in a full-page editor, and the whole task you're doing is just editing that item. For these, I believe the "always auto-save" might work well: think Google Docs, which always saved changes, not just when creating them.

However, I also have some resources that are edited in a smaller, dialog-contained editor. For these, I am not too sure about always committing changes automatically. Think of Google Classroom's "classwork" editor:

enter image description here

Here, changes aren't committed until you hit save. I believe this could be safer for the user, who would feel more empowered to experiment, knowing it's as easy as just discarding the most recent changes if they wish.

For example, let's take this lesson editor from my app. When you first create a lesson, autosave is enabled, and the editor looks like this:

enter image description here

However, if you subsequently edit the lesson, the autosave will be turned off and you'll have to manually click a Save button.

enter image description here

For now, one solution I'm adopting is that nested items (for example the attachment in the second screenshot) are created and stored even if you discard the most recent changes. So "saving" only applies changes to the top-level resource.

Do you think it could be disconcerting to the user to have two different experiences when creating vs updating a resource? Also, how would you handle nested resources created, updated, or deleted during such a phase of not-autosaved editing?

I understand the latter is more of an implementation issue, but what I'm finding to be the hardest aspect to deal with is dealing with nested entities when the changes to their parent aren't saved yet: it's much easier to assume the parent exists and is up to date, so any advice as to this aspect is also very welcome.

  • "...discarding the most recent changes if they wish." — When in auto-save mode, am I NOT able to discard/undo the most recent change? Commented Dec 9, 2022 at 11:36
  • How discrete is the non-auto-save, "smaller, dialog-contained editor"? Am I editing one field/value at a time? Commented Dec 9, 2022 at 11:39
  • "When in auto-save mode, am I NOT able to discard/undo the most recent change?" if you make a bunch of changes, you'll have to undo them all one at a time, whereas if you weren't in autosave mode, you'd just click some "Discard changes" button and forget about your recent changes
    – Samuele B.
    Commented Dec 9, 2022 at 11:49
  • I also updated with screenshots of the editor in question
    – Samuele B.
    Commented Dec 9, 2022 at 11:49
  • @SamueleB. How would the user know how many changes they have to remove to get rid of what they incorrectly changed if they're in autosave mode? I would assume "Discard" to discard everything that happened between me opening the page and clicking that button. I'd add a timestamp or number to track so you can just Discard the bulk of recent changes instead of clicking per change. Commented Feb 5 at 13:54

1 Answer 1


Rather than decide when the users can autosave, let them decide for themselves—adding an "Autosave" toggle control:

autosave toggle

I contend the Autosave toggle option ought to initially be set to the OFF position—let the user turn the feature on.

The initial draft button might be:

[Publish Draft]

And when editing the button might be:

[Publish Edits]
  • "The default ought to be OFF" is there a reason for this? In the case of a new item I would want to auto-save the draft by default, but I don't want to auto-save edits to a published item by default. But you can't have one by off by default and one on, since then you suddenly have different behavior just because you clicked "Publish". Commented Feb 5 at 13:17
  • I updated my answer. Does that address your comment? Commented Feb 8 at 17:43

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.