Confirmations | Developing User Interfaces for Microsoft Windows

If you want users to hate your program, just sprinkle a bunch of unnecessary confirmations throughout it. This will make your users scream. You shouldn't confirm a user action just because the user might make a mistake.

How do you decide when a confirmation is necessary? I recommend using trade-off analysis similar to that used for analyzing the program exit confirmation. If the accumulated cost of the confirmations exceeds the benefits, or if it takes less than about 10 seconds for the user to recover, most likely the confirmation isn't necessary.

You also need to understand that using too many confirmations completely undermines your objective of protecting the user. The natural user response to a flurry of message boxes is to get rid of them as quickly as possible. Most likely, the user will just click the OK or Yes button without even reading the text. Even if one of those confirmations says Click OK to lose all information, most likely the user will click OK without reading the text.

Any action that can be easily undone should not be confirmed. If you have many actions that aren't easy to undo, you should consider putting the burden on your program instead of on the user by providing an undo command. Good examples are the Undo and Redo commands in Microsoft Office and Visual C++, as well as the Recycle Bin in Windows.

TIP
Consider providing an undo command to eliminate confirmations.

Of course, any action that cannot be easily undone should definitely be confirmed. For example, do ask the user to confirm destroying an unsaved document and to confirm before erasing or formatting a hard disk. But your first choice should be to add enough functionality to make the confirmation unnecessary.

One confirmation that I find especially bothersome is when a program asks me if I want to save changes to a document when I didn't make any changes in the first place. If I didn't make any changes, why would I want to save them? The answer to this questions is always no, so why bother asking me? A program should ask the user to save changes only when the user explicitly made a change. This problem occurs in Outlook when you view an attachment to a message using Microsoft Word. Changes created automatically by a program, like changes to pagination created by Word when it loads a document, should not be considered worthy of bothering the user.

TIP
Don't confirm saving changes unless the user actually made changes.

Note that in all other cases the user is far more likely to want to save a document than destroy it but has only a fifty-fifty chance of selecting the right button in the confirmation. If the user accidentally presses the wrong button, it's possible that several hours of work may be lost. If the user chooses not to save the document and the document isn't too large, you might want to do the user a favor and save the document anyway to a temporary folder. This way, if the user made a mistake, nothing is lost and your user is grateful. To implement this feature properly, you will need to make sure that the user is aware of it (ideally with a flash box, as shown below) and periodically delete the old files in the temporary folder so that they don't take up too much space.

By the way, while modal dialog boxes almost always have OK and Cancel buttons, confirmations are almost always better with Yes and No buttons. For example, the world's most confusing message box—