I am designing a web-app with a lot of forms and i was wondering how to improve the filling. The classical pattern is : fill, fill, fill, Save

Have you experimented a form which auto-save each field once you unfocused it ? In that case the Save button is no longer needed but maybe the user is reassured by it.


download bmml source – Wireframes created with Balsamiq Mockups

  • 56
    I don't have any evidence to offer but I would suggest that feedback is key here: if your users don't see that items are being saved then they will look for a save button. If, in this instance, they don't find a save button they will worry about loosing the data they just input. If you can find a a way to signal that the data is begin saved you won't need a button. Commented Jun 19, 2017 at 8:28
  • 12
    The problem that I see with auto-save is that the user might not have finished their filling. They might feel surprised if their data is saved without their "approval" => Save button. But I like your way of thinking. We can make better forms Commented Jun 19, 2017 at 8:51
  • 7
    The text-editor "atom" has an auto-saving "configuration" screen. It works, but always make me stop a second and rethink if the changes were saved or not. Commented Jun 19, 2017 at 12:38
  • Not an exact duplicate but related discussion in this question: How to communicate the message that the edit is auto-saved.
    – Matt Obee
    Commented Jun 19, 2017 at 14:34
  • 11
    Your rightmost graphic boasts no button needed. But... If, as you posited, saving a field should occur when the user unfocuses it, then how do they save the final field? By clicking/tabbing out of it into an earlier field? That seems very undiscoverable and unfriendly to me. It almost seems like you would need another control after the last field, to save it... like some kind of Save button... :S Commented Jun 20, 2017 at 17:27

9 Answers 9


As a user I don't like this idea at all.

There are 2 scenarios:

  1. Creating an entity
  2. Editing an entity

If I am in the create mode for say... a contact... as soon as I type "Dave" in a first name field it would have to create an entity... if I decide nah... I'm not going to add Dave after all, normally I just leave the screen and all is fine but in this case you're got a partial, and undesired entry in the system that the user didn't want.

If I am in the edit mode, I may start making some changes... then whoops wait... I entered the wrong data (or entered it in the wrong field)... no problem, just discard my changes and reload the form!... wait no, can't do that as it has overridden automatically.

The great thing about a Save button is that the user is giving explicit instructions to you to save the data up until that point the user expects that they haven't committed to anything.

  • 56
    This is why systems with continuous auto-save also often have extensive history and undo capabilities.
    – Barmar
    Commented Jun 19, 2017 at 20:20
  • 30
    I agree with @Barmar... the typical flow here would be autosaved, autosaved, autosaved, SUBMIT. Values entered may be autosaved for convenience, but aren't actually used to create entities until the user is finished editing them and makes a conscious choice to submit. Mistakes at this point are no different than if the user manually saved on the first type of form.
    – flith
    Commented Jun 20, 2017 at 6:16
  • 22
    Worth noting the answer submission form on StackExchange already works this way. Text you enter into the form is autosaved, but that doesn't mean the answer is automatically submitted until you explicitly click submit.
    – Ajedi32
    Commented Jun 20, 2017 at 13:11
  • 2
    @flith Actually, I'm thinking of Apple OS X. Recent versions have changed many applications to remove the "Save" command, instead saving continuously with history that can be browsed to revert to previous versions. There's also system and application preferences, which often take effect immediately with no "Save" button.
    – Barmar
    Commented Jun 20, 2017 at 15:51
  • 3
    @plainclothes there may be some scenarios where it is ok, but for the vast majority it presents more challenges than solutions. Ultimately you want a UI that is extremely clear for the user with no ambiguity.
    – scunliffe
    Commented Jun 20, 2017 at 16:44

I posted an answer here that I think addresses this concern in some detail.

Auto-save is a great feature where the user's work may take some time (like long forms and document editing). You spare them the mental overhead of remembering to save as they go.

Don't send the wrong message

If your system is saving incrementally as work is completed, but you also provide a Save button, the user is left to wonder what that auto-save is really doing.

Is it really saved?
Do I need to click this button too?
If I click Save will I leave the form?

Why put your users through such anxiety? Make up your mind and decide on the right pattern: manual or automatic save.

Clear visual cues

Because forms are often manually saved (for better or worse) you need to make it very clear to your users if you decide to go against that. Here are some visual cues I've used and have performed well.

Auto-save visual indictors

Provide a way out

Users occasionally (often?) change their minds. If you've been saving their work along the way, you need to provide an easy way to reverse that work. There are several features that make this work well, especially in data-critical applications.

  • Field-level undo
  • Cancel and discard all changes
  • Change log with ability to revert (for admins)
  • 1
    I like this answer - you have a clear and concise reason as to why you should've have both an explicit save button and automatic saving, which can be confusing. I also like the visuals you have - they remind me of what Google Docs/Sheets/Slides/Mail do, which, as a user, is effective. Commented Jun 21, 2017 at 3:13
  • By the way, what tool did you use to mock up the image you provided, or is that from a real website? Commented Jun 21, 2017 at 3:14
  • @homersimpson From a Sketch spec file for a real app 😉 Commented Jun 21, 2017 at 3:15
  • Perhaps instead a Save button at the end, there should be two buttons... [Confirm Changes] and [Discard Changes]? Commented Dec 1, 2017 at 14:13

I feel there needs to be a single point where I can confirm ALL my input has correctly saved. Your auto-save example does not have that - imagine a longer, more complicated form, and you put some invalid value in one of the fields, you correct it, there is a small delay between typing and saving, etc... Maybe the connection is unreliable and saves randomly fail, etc... How do I know for certain everything is correctly saved?

I think you should consider how Google Docs and Office 365 does it. In the toolbar they have labels which shows the status (e.g. "Saved 2 minutes ago", "Saving...", "Not saved - no connection to server lost, trying to reconnect" (or something like that).

For your form, you could put this at the bottom of the form near where you would have put the Save button. The information could be:

  • "Saving changes..."
  • "All values have been saved automatically X minutes ago"
  • "Some values have not been saved because they have not been properly filled, please check the form."
  • "Some values have not been saved because (error)"

I think this should be at least as prominent as a Save button would have been - maybe a large green tick, bright read X if it failed, some spinner graphic if it's progressing (next to the text description)


I've tried it in an auto save form but found that having a button at the bottom of a form was logical and expected for most users. In my case it would be a 'publish and close' button. Users might feel insecure about their content being saved without approval. That's why it is a good idea to have the save button. It gives users a feeling of control over their content.

It's like the "I'm feeling lucky button" from Google. People expect it to be there even though it does not show different results than when you use the 'normal search button'. In fact, if you have javascript enabled you don't even get the chance to press it because Google shows results when you start typing.

See this question for more on that.

Sometimes things exist not because they still make sense, but because their presence is an affordance -- i.e. it works not because it's good, but because the visitor understands what it is, what it does, and how to use it, because they've been inculcated over years with this knowledge.

  • 8
    The "I'm feeling lucky" button on Google does have a specific purpose: it opens the first result of your search without showing a results page first. Commented Jun 19, 2017 at 8:29
  • 3
    @AndrewMartin - yes, except that if you have javascript enabled you never have the opportunity to press it because as soon as you start typing your query the results page appears anyway.
    – Jules
    Commented Jun 19, 2017 at 10:57
  • @Jules - The "I'm feeling lucky" button isn't tied just to the search. If you click on it without typing anything in the search bar, it take you to the Google Doodles page. Commented Jun 19, 2017 at 11:38
  • 1
    If by "Google shows result" you meant the "search result", not the "search suggestions", then it can be deactivated in Search settings as "Google Instant predictions". However, yes, the default value is set to show Instant results. Just a note on "I'm feeling lucky button"~
    – Andrew T.
    Commented Jun 19, 2017 at 13:32

Forms without a save button have become more common recently based on my personal experience.

I have observed more companies using such forms that don't have save buttons. One area that this seems common is with 'settings'.

Initially I found these forms very confusing - basically "where's the save button" anxiety. Initially I would go to other tabs, log out, log in, make sure the data stayed Over time, now I've experienced this a bunch of time, I've got used to it and am no longer confused.
Similarly for the ajax feedback messages for changes as they are made - initially I needed and wanted this feedback. Over time I've got used to newer forms not giving me that feedback. I still prefer the feedback myself but I have got used to forms where I don't get it

This is one example of an interesting category - user input that doesn't work well for folks because of their existing mental model but once they get used to it their mental model changes and the change becomes acceptable - even desirable !

  • I have experience some similar forms too and I agree with Michael here that it is something you have to become used to, however if combined with a confirmation message upon browsing away when the data is not yet autosaved then I think it seems okay to me. Commented Jun 21, 2017 at 22:24

If you really think auto-save is the way to go, I would say do not put a save button. But make sure you indicate in some way that the data is saved.

As scunliffe pointed out, for the use case that you showed, automatic saving is a bad idea. If someone backs out, a partial will be saved, potentially forever. To avoid this, you could ask the user whether or not to save the partial before they exit the page, but in my opinion that would degrade the user experience more than having a save button.


Besides of user experience issues shown in other answers, you must consider performance and security issues here:

  1. Every time your auto save event trigs, your form executes the save to database command. Now if you have 10 fields in your form, then you should expect your server to run this command at least 10 times more than having a Save button. Since you have a web page, you have the potential to reach for millions of users making this not a trivial thing.
  2. Since your page is always requesting for send/receive little packages of data, user’s system may allocate an unnecessary amount of data communication resources to you page/form.
  3. Since you almost gave away the control to save to database event, you could not, at least in an easy way, check if the sender is a human or an automated peace of code. Therefore, your page may be in higher risk of denial of service attacks.
  4. As pointed by scunliffe you database may have thousands of partial scrap data, reducing data quality and database overall performance.

At last but not least: “... up until that point the user expects that they haven't committed to anything.” (scunlife)


Use both. Except auto save should not directly go to new/edited entry, but to its draft version. If user closes form for whatever reason (or in case of crash) and then decides that he wants those changes after all - you pull out saved draft and let user continue from where he left.

Buttons below the form should let user finalize the changes - i.e. commit to base, publish, send, whatever, and revert to last committed version where applicable.

This might be different in some scenarios, but often incomplete data isn't useful and can even be confusing, especially if user publishes it in some way for other people to see as opposed to editing some personal database, so it's better to still have some way for editor to signal "it's ready for consumption" instead of pushing every little thing to outside world automatically.

That's, IMO, is most intuitive approach. That's how GMail works with autosaving your drafts all the time, but sending only when you directly instruct it to. Even the comment form where I write this answer right now works this way - whatever I type is continuously saved as draft and never lost, but I need to explicitly push "post your answer" when I'm done.

  • +1 for draft. If a person moves and I use an autosave form to reflect that, I might first replace "Main Street" with "Evergreen Terrace" and then "Ogdenville" with "Springfield". With direct autosave to live data, there is a time window where other users see and use "Evergreen Terrace in Ogdenville" Commented Jun 20, 2017 at 9:17

Yes, Please! I work with a program that autosaves when I press enter. Even knowing this, I often will reopen the page to check that it saved what I entered/changed. This creates more work. The lack of a clear, concise answer and not wanting to screw it up makes me do so. If they would put a saved up or offer a button it would make me happy. So there ya go, a real life example of why you should.

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.