I'm developing a web app that puts great focus on simplicity and "just-use" mentality. The basic idea is to write notes. When planning the concept, we where very positive towards the idea of autosaving, so the user never needs to think about saving or worrying about lost content. Just type until you want to create a new note, then start typing again.

However, some use tests indicates that the autosave pattern is not very appreciated at first. All our test people started to type, then looked for the "save" button. So we put some more effort into directing the user into understanding that "you dont need to save, that is done for you, all the time". That worked, but then the user asked, "OK you autosave, but where is my text?" and "how can I be sure that the content is saved?"

My question is, is there a natural "good feeling" about autosave, but when actually using a text editor, we all want to "make sure" the content is safe?

Are there any studies around this subject or can anyone here share some valuable experiences when dealing with save patterns in application designs?

  • Microsoft OneNote does constant autosaves and doesn't have a save button at all. It can take a little while to get used to, but it works.
    – ChrisF
    Commented Dec 1, 2010 at 20:02
  • 1
    There is also an active discussion of this topic at ux.stackexchange.com/q/9619/7053 Commented Aug 4, 2011 at 16:28

7 Answers 7


Google does this quite a bit actually. They have auto-save functionality in Google Docs, Gmail, and Blogger.

In each case the app automatically saves your content and provides a little note somewhere that says something like, "Your draft was saved at 3:04 PM." But they also have a "Save" button. I liked their approach so much that I copied it almost exactly for a recent large website re-write.

Their approach works well because it meets the classic usability rule of doing what the user expects. The user expects a save button so you should probably give it to them. Of course, if there's nothing to save (because nothing has changed since the last save) you can disable the save button and position text stating when the content was last saved just as Google does.

  • +1 because I agree. Having a button and an automatic save with the last saved [date] and time is as close to perfect as I can imagine. Commented Dec 7, 2010 at 9:49
  • Another UX convention is to notify the user of all actions taken. No hidden actions are taken without the user noticing it. Tell him you're saving his work. Commented Jun 13, 2013 at 0:31
  • We have this conversation because our browsers and operating systems are still in the stone age. I have a dream that someday I can open a form in a browser, type some text into a field, and then unplug my computer and destroy it. When I buy a new one and plug it in, the computer will automatically reopen the form in the browser with all my text. And the web app won't need to have done anything. It will be a standard feature built into the browser. Why not? The app developer shouldn't be required to code around deficiencies in the browser and operating system. We need Global single level store. Commented Aug 12, 2015 at 14:47

We are using this approach for in a rather complex application targeted at engineers and technicians, now on the market for over 10 years. Here's our experience:

Especially in the beginning, this took users quite sometime to get used to. Making it worse, we don't provide a comprehensive "undo" or history. That might have been a real problem if we hadn't started out in a unoccupied niche, giving our early users a clear advantage.

Interestingly, it was power users that first recognized they like working that way after having to use it for a while.

In the recent years, I'd subjectively say it got better even for new users: We've roughed out the grave problems users did stumble over, and more starting users seem to be used to other apps without manual save.

Still: Files + Undo.

  • Give the users files they can back up, send to other users, and do whatever they want to do with. We did get burned by not fully considering the variety of problems user can solve for themselves by pushing around files.
  • Provide comprehensive, item-level Undo, or even a history. We swing by without mostly for technical reasons, but it is the easiest way to reinstantiate trust in users that are surprised their changes are already saved.
  • -


This comes down to influencing a change in user expectations and behavior; and building trust between the user and the system.

The problem is: we have a history with the save button, and have come to rely on it to ensure that the system is doing what it should be doing anyway. Paraphrasing Alan Cooper - the save model is an unnecessary part of the user experience. It forces the user to be aware of how the system operates. It's a dichotomy he refers to implementation model vs user model.

SO - the key to success is a transparent, gradual, careful removal of the training wheels. If you make drastic and unexpected changes to the save model, people will be apprehensive. This can be seen in the response to Apple dropping the save as from OSX. It was met with confusion and distrust because the system failed to tell its user why this was happening and how it would improve their lives.

Google, on the other hand, did a much better job with their save model. It made users fully aware that it was handling the save process for them, and kept them aware of the status of the save process.

Your system should initiate an informal and unobtrusive conversation between the system and the user when the save action happens. Let them know what it is doing, why it is doing it, and what they can expect. Use a few inline, transient messages:


download bmml source – Wireframes created with Balsamiq Mockups


Use one of this:

1) Use Save/Cancel buttons and really save or cancel data when user click on them (explicitly saving data on user's demand)

2) Use autosave feature and disable the button Save when you have done saving successfully, use Cancel to remove previous saved data.

Why you cannot remove Save button in the second case: these is a big difficult (performance issues, unpredictable user's actions) when you cannot guaranty that all changed data really saved.

In both cases check that data has been changed and has not been saved.

(see google, word autosave features)

  • What about instant autosave (open socket / local storage)? The save button will never be enabled... Commented Dec 1, 2010 at 21:04
  • @David, any way you should control state of data. what if user want to reject all previous changes? In general I meant distributed system (n-tier), but any way edit control and file or object or any other local storage the same.
    – igor
    Commented Dec 1, 2010 at 21:34

I think autosave can be very useful. As it is a web app however, and dealing with a line of communication that can be interupted, you might provide feedback as to whether the data has been saved. (A confirmation from the server.) If you provide any clue (like an asterix, a text saying 'saving changes' or anything) when changes have been made that are being submitted, people will feel more confident trusting the autosave. So they need to have some visual clue as soon as they start typing that the app is noting the change, then some clue that the proces has been completed. (It's also an excellent place to pop up a message when someone inadvertantly unplugs the internet cable.)


I couldn't find much through a quick search but I'd think that Google must have some research on the autosave feature of Google Docs. In particular, not only does it autosave frequently and provide roll-back to iterations, but it does this while multiple users edit and their changes are colour-coded live for other collaborators to see.

The model is a bit weird for some people, but the experience is pretty good and maybe this is a model you can explore a bit, even if it's not an app with collaborative capabilities.


I came here to read some other opinions on the topic. My personal opinion is that autosave is fine ONLY & ONLY IF it is backed up with undo feature. I remember once I had very negative experience in Google maps when I accidentally moved a pointer from one position to another. I tried to find undo button and at that moment app reports "Your changes were saved successfully". I did not want it to happen. It took some time to revert pointer back to original position. It was very unpleasant experience as there was not option set pointer to certain coordinates.

From the other side it was one off. I believe without autosave I would have more cases when for some reason I would lose some data and I think I would be more unhappy.

The only problem is that undo/redo requires some efforts & time.

Now let's look into "undo". What should happen if autosave saved changes automatically. User wants to do "undo" and he loses internet connection. Is it a bad luck? Or app should be able to revert back all undesired changes after it gets connection back? It is getting very complex if it is a browser app(Angularjs) and browser was closed. Yeah, we can keep track in local storage but it is getting complex not only for implementation but it is getting complex for the user.

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.