I'm currently working on a product that has an account configuration page which allows the user to create an API key and set a group of default settings for it. When developers submit a request through the API they have the option to specify an override for any of these values, but if they don't then the default is used.

To (presumptuously) make life easy on my users I'm allowing each setting to save immediately. They're all numeric fields or drop-downs, so it's pretty easy. The problem I see with this is two fold:

  1. Should I include a "Save" button even though the items save on-change, if so, do I put it with each element?
  2. How do I tell the user that the form is automatically saving changes as soon as the user makes them?

My thought to #1 is to say "Yes, dummy." and use that save button for #2. I can put a save-button next to each element (or "update", what-have-you) and swap it out for a "saving" animation progress bar or spinner. (Not sure which, but I assume the spinner would be more effective.) When the item is saved indicate a checkmark, and bring the save-button back. This also solves #2, as the save button would indicate it's saving.

However, I worry that making the "Save" / "Update" button disappear when it's saving would be detrimental to user experience. I want them to spend literally as little time as possible on this page. They should be able to come in, change the settings, and leave. I want minimal cognitive load (there are other "help" pages to give them more information), and I want them to be able to easily and clearly see the changes.

I'm up for any suggestions/ideas/answers. I can't post a direct mock for IP reasons, but I can probably contrive an example mock to demonstrate if necessary.


2 Answers 2


I would say do not include a save button. Save buttons make me think that saving is not instant. Instead:

When a field is changed, run a spinner next to it (for some time, even if saving is instant) followed by a green checkmark. This would give the user the idea that some work has been done (saving), and successfully completed.

If you want to make it more explicit that it was saved, rather than, say, validated, you could instead put a small text box denoting "Saved!". If you did this, you wouldn't need a minimum time for the spinner.

You may want to reinforce automatic saving with a warning at the top of the form ("Changes saved automatically.").


The other option could be to use a pattern like JIRA, where you provide a tick box to save your work but if you click off the updates are also saved. This gives an obvious affordance to save for any users who would not 'get' the (arguably?) hidden affordance of an automatic save.

That said, I would say it depends on the type of users of your application and how often they use it (e.g. are they highly technical? If they are setting API keys I would assume so, in which case are perhaps more familiar with in line edit pattern?) and what patterns are used elsewhere, as consistency for what the user expects of your specific app will play a big part.

I am currently facing a similar problem, and we have settled on a combination of indicating a save as suggested, but also with a pattern like JIRA where you can invoke that state by selecting an (in field) tick icon. We made that decision because the pattern in the vast majority of our web estate uses an explicit save button; in anew application, it made more sense given the feature set to use in line editing (for reasons I won't go into) but we wanted to persist the pattern of allowing users to explicitly save to be as consistent as possible with elsewhere. Of course, hopefully we will be able to test this to see if it is as effective ;)

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.