I'm currently in the process of developing a Windows Application which produces Word Documents.

In the program there is the ability to save your progress (different to the "Save as a Word Document" option). This option "Save Current Progress" saves your progress, there is no user input, except the action of clicking the button (i.e. they don't have to specify a file location).

When designing the functionality for this button I researched other instances of "Save" buttons in programs. Most of them resemble floppy disks, and on clicking them there is no feedback (except the subtle visual cue of mouseover and click on the button itself). i.e. there is no alert window saying "you have saved" nor does the button change to signify a saved state.

The problem is that in my application this could be confusing. In Microsoft Word (for instance) it is the most natural thing to click the save icon and know it has saved, without any positive feedback. However in my application it confuses users and they say that they "don't know" that what they've done has actually saved anything. The icon is different to the Word one. It resembles a hard drive with an arrow pointing down onto it.

enter image description here

However, surely the thought process should be the same. I'm going to change the functionality so that the icon changes to that of a tick momentarily to give positive reinforcement that the status has saved, but I'm interested as to why the two scenarios differ so much.


As per some of the suggestions here I have created this graphic to switch states when the user saves.

enter image description here

  • 6
    FYI, Word has visual feedback on saving progress. It's not obvious to occasional user though. Pay attention to the right side of the status bar next time you save.
    – dnbrv
    Commented Jan 6, 2012 at 13:22
  • 5
    Yeah I'm aware of this, but its really subtle. Similarly a lot of code editing programs have the name of the file in the title bar with a star (*) next to it if the file has unsaved changes. The star then disappears when you save. However this is also pretty subtle, and I'm not sure if your "generic computer user" will have the technical knowledge to understand these cues. Commented Jan 6, 2012 at 13:29
  • If you are asking if you should provide feedback on the save button, meaning on the button itself, I think that is a different question than the current question title. The pictures in your question indicate you are leaning toward providing feedback on the button and that is what some of the other answers respond to. However, if that is the case, I suggest you change the title of the question to fit.
    – Tom Resing
    Commented Jan 6, 2012 at 18:49
  • Tom, absolutely not. I'm not asking about the actual button itself. What I'm asking (as is clear in the question) is whether the act of "Saving" should be acknowledged at all. It is the prerogative of the answerer how they interpret this, whether it is the case that the feedback should occur on the button itself (which is a nice idea, that's where the user is focussing, and its not intrusive to their experience, as an alert dialogue would be) or whether there is some other feedback to let the user know their action has completed successfully. Commented Jan 8, 2012 at 12:58

6 Answers 6


On clicking the save button in almost any application for the first time, you are asked where to save the file. If your application does not do this, it would be understandable that people are unsure as to whether it has worked or not.

My advice would be to grey out the icon and replace the icon with a spinner while the save operation is taking place. Even if saving is near-instantaneous, do it anyway for a minimum of a second or so.

enter image description here

Once this period is over, replace the icon with a tick, and change the button text to Save Complete for a second or so, before reverting back to the normal button. This provides strong visual feedback that the button is doing its job.

enter image description here

  • 3
    Tellig them that it is happening, and that it is completed OK ( or not ) but doing this unintrusively is the best option. I think MS are actually wrong to not provide this feedback, but people get used to the way that thing work. Commented Jan 6, 2012 at 13:01
  • 3
    The fact that the icon changes momentarily doesn't necessary mean that the user will be aware the save has occurred. I think the fact the button dramatically changes its visual style between states could be problematic, but if you choose this method I'd recommend keeping the 'save complete' state on screen until the document has been changed (and potentially requires saving again). Commented Jan 6, 2012 at 13:10
  • 1
    And if there is an issue, the "saving" state may remain on longer, which gives some indication to the user that the app is trying to save, and hasn't just died. Commented Jan 6, 2012 at 13:21
  • 1
    I would suggest that instead of "Save Complete," just return to a grayed-out "Save Progress" button, which then becomes active again once there are any changes that could be saved.
    – fluffy
    Commented Jan 6, 2012 at 20:21
  • 1
    @ThomasClayson IMO it's less distracting, and it also shows that there is no purpose to attempting to save again. It is a behavior that is well-established by quite a few things; it is at least as old as Emacs and as recent as OSX Lion's "save a version" mechanism. It also helps to tell more OCD users that there is no need to constantly click the "save" button "just to be sure."
    – fluffy
    Commented Jan 8, 2012 at 21:06

As you've stated, it's important that the user is provided with feedback about the success / failure of the save operation.

One way that some business applications achieve this is by disabling the save button when the most recent version of a file has been safely saved to disk.

  1. User clicks save.
  2. File is saved.
  3. Button is dimmed / non-clickable -> this provides a sense of positive reinforcement that the application has performed the operation successfully.
  • 12
    +1 Having the save button dimmed/non-clickable when there are no unsaved changes in a file is my favourite mechanic.
    – Anonymous
    Commented Jan 6, 2012 at 13:09
  • 1
    This is a useful insight, however I steered away from this in my application as I (and I'm aware others) "enjoy" what I've come to know as the lift/elevator theory whereby clicking a button (or pressing the "call lift" button) multiple times somehow reinforces the action (or makes the lift come quicker). Obviously this isn't the case, however it is nice to be in control of the application, rather than the application "locking" certain controls. This was the theory behind not disabling the button. Commented Jan 6, 2012 at 13:10
  • 1
    I think the lift/elevator/traffic light scenario is interesting - but I think by disabling the button you're potentially countering the problem posed. Commented Jan 6, 2012 at 13:16
  • 3
    I don't like disabled buttons. I ealise that this is personal preference, but I want to be able to save my documents again, even if nothing has changed. I want that control over what is happening, even though I know it is illusory. Personally, I would only disable buttons when clicking them twice in a row will have unwanted effects ( like, say, sending an email multiple times, or paying for a purchase ) Commented Jan 6, 2012 at 13:24
  • 1
    @Svish; that's an interesting case - but arguably the program which has the file open should be aware that the file has been updated and respond accordingly. Commented Jan 6, 2012 at 15:55

I have to ask why you think this button is necessary. If this is an incremental save, of a file that the user is working on, then I would think VIM's method is better. I.E. keep a swap version of the file, and silently save to it every few moments. It doesn't bother the user, they don't need to do it manually, and if there is a crash, all edits are saved.

However, this avoids the issue where the user works on a file for a while, and decides to throw away the changes by not saving. When your program closes with edits, you can ask the user if they wish to save or not. Also, provide them with a decent method for managing these backup files, if necessary.

Part of the problem is that many, but not all, users know there is two copies of the file in existence. The one on the hard drive, and the one being edited in memory. But most programs just assume that the hard drive copy is the only copy. This disconnect between user expectations and program functionality is partly why your users are confused. See this post from Joel Spolsky for an example.

So there are two competing user models, and your program has an ambiguous input. Not only does it not show if it worked, but group A(file only exists on drive) doesn't know why you need it, and group B(file is on drive, and in memory) is annoyed that the program doesn't handle this internally.

  • 1
    Hmm, an interesting point. I suppose the point here is that a user might come to the program to edit something and might want to "revert" to the original last-saved state of the form. Take the example of Photoshop for instance. You work from a PSD. This is a file which you open in photoshop, edit and save changes to. It doesn't "auto save" or anything like that. Then you export to jpg (or other). Its not quite the same, but I'm aware that "autosave" might be alarming or confusing for its own reasons. Commented Jan 6, 2012 at 13:51
  • @ThomasClayson Yes, autosave can be alarming. Namely, because most versions overwrite the current file. You want to save "draft" copy or some such, so that if the user quits without deliberately saving, they go back to the old version. A very large number of people use this as poor man's version control. Commented Jan 6, 2012 at 14:08
  • 2
    I like this idea, but personally I have an inherent lack of trust in technology. Being sure that your document is safe provides a very powerful sense of security. If saving 'just happens' .. perhaps feedback is still necessary? Commented Jan 6, 2012 at 14:46
  • 1
    @codeinthehole No, no. There is two separate saves going on. You are always able to do a normal save with feedback. But, behind the scenes the program keeps a rolling backup of your current version. If the system crashes, you can restore from the backup or the original. I suggest you check out how vim works with it's swap files, tilde files, and undo files. Every time my vim instance has crashed, or I lost my remote connection, I could restore to where I was without data loss. Commented Jan 6, 2012 at 14:56
  • @Spencer Rathbun; in that case, I think your solution is an additional feature, rather than an answer to this question. It's a nice point, but maybe not entirely relevant. Even incremental saves sometimes need to be explicit. Commented Jan 6, 2012 at 14:59

There should be an indication of wether or not there are pending changes to save, and a great way to do this is by whether the save button is enabled. After saving successfully, the disable the save button, indicating that saving is not an appropiate action because there is nothing new to save. When the user edits something, then enable the save button, indicating there are unsaved changes.

Indicators that saving is in progress are a good solution to a related but different problem, that saving takes a perceptably long time, so the user should be assured that something is happening.

  • I tend to agree, however the "evidence" points to a different conclusion. When I'm in Microsoft Word, or Excel, or any similar programs there is NO indicator (that I have noticed) that I have started editing, and often I will come back to an open Word Document and think to myself "have I saved this yet?". If this is wrong then why has no-one thought to change this in the many iterations of the Office suite? i.e. why don't people approach new software with the preconceptions based on their use of Microsoft products? This is my dialemma Commented Jan 8, 2012 at 13:03
  • @ThomasClayson That is rather weak evidence, and that line of thinking leads to information cascades. I have used this approach in my own software, both specifically with save buttons and more generally enabling buttons only when they potentially do something useful, and it works well. Seriously, you should aspire to provide a better user experience than Microsoft. As I recall, Word does have a unsaved changes indicator, but is subtle and unassociated with the save button, making it go unnoticed and therefor useless.
    – JGWeissman
    Commented Jan 8, 2012 at 18:10
  • I agree @JGWeissman, however I'm not targeting you or me with this program - I'm targeting users who use Microsoft Word day in day out. The kind of people who use internet explorer because they don't know that you can get different browsers, and even if they did then they don't know why they should bother changing because "everything works in internet explorer". ;) I need to give the most intuitive platform for my users, and I believe that disabling the button will cause unnecessary confusion. There are other ways I can alert the user to unsaved changes. Commented Jan 9, 2012 at 9:15

Yes. You should absolutely provide feedback from a save button.

Word does provide feedback from the save button, but you may never notice it in most normal cases. On a long save operation in Word, you will notice a message in the status bar and the user is prevented from making changes during the save operation. Also, if you haven't saved the document and attempt to close it you will be prompted to save. This is another way of providing feedback on the save operation itself.

Here is an example: Word is Saving Status

  • How did you manage to get that screenshot? My computer saves too quickly to press Print Screen.
    – dnbrv
    Commented Jan 6, 2012 at 19:06
  • 9
    I inserted a movie into the document before saving it.
    – Tom Resing
    Commented Jan 6, 2012 at 23:30
  • I inserted a movie into the document before saving it clever! :) Yeah, I understand you answer but normally this usually happens very quickly and goes largely unnoticed by the "average" user. Contrast this to web apps for instance. If you click save usually you are presented with the same page with a persistant notification (usually in green or yellow) saying "Saved" or "Your email has been sent successfully" or something. The reason for providing the feedback on the button was to lower the intrusion level to make it obvious but not annoying. Commented Jan 8, 2012 at 13:08
  • It is subtle, but often it's the smallest details that make the biggest difference between a good experience and a great one. Microsoft has taken a lot of care to study the user experience in Word, so it makes sense to take cues from them for your windows application. The question I might be asking myself in your shoes is why does this make sense in Word, but not my application? Maybe users trust the save operation in Word more. Word is very inviting to new users in general.
    – Tom Resing
    Commented Jan 8, 2012 at 18:05

I realize you are doing a windows app however things are a changin and you should move toward the UI feedback trends.

For example,

  • the new mac apps are automatically saving as you work
  • google docs automatically saves while you work
  • lots of apps are following suite toward this trend

Since you are building a new app, think in the trends rather than the status quo. Things are evolving toward a better user experience in that regard and you should too if possible, regardless if its in a legacy framework. Windows 8 will be coming out fairly soon so this trend will follow there as well in order to compete.

  • I wish I could do this, this would help everyone. However I feel that this could confuse the intended audience of my application more so than just not providing feedback on a button. Commented Jan 8, 2012 at 13:09
  • Understood, however @ThomasClayson ask yourself if that's what Google Docs is doing or Apple's UI trend. I imagine you have not used those yet so its harder to visualize what I mean exactly. Try it out a bit. It may not be one-size fits all type of thing but I do appreciate not having to explicitly save things and it becomes second nature in work flow, similar to how scrolling with the mouse pad on a laptop with a flick of your finger has become in grained in so many people after being so used to a mouse grab. Commented Jan 8, 2012 at 16:07
  • 1
    I always use google docs, and I work on a Mac 100% of the time. However, my intended users work on Windows computers, use Microsoft Word, Microsoft Outlook, click the "Apply" button then the "Ok" button when using the control panel and all sorts. I'm not trying to be cutting edge and modern (unfortunately) I'm trying to make my application useable and accessible. It needs to have an interface that is simple, useable and intuitive. I don't think that auto save (for the demographic I am targeting) is intuitive unfortunately. Maybe in a decade. Commented Jan 8, 2012 at 16:57
  • In a decade we won't even be using the web like this. Siri is just a hint of it. I think it will be more toward conversation with visual feedback while you converse freely to a machine with elements of minority report thrown in IMO. Commented Jan 22, 2012 at 20: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.