I recently went through a long and complicated discussion of our exit dialog here at my company (GN ReSound). In the process, I realized how complicated Save and Exit Dialogs can be for a user (and designer!). There has been some standardization of this over the past few years. But, it still isn’t a widely discussed topic in interaction design and UX.

The problem with save dialogs occurs when the user attempts to exit an application without saving changes. The alert box (or save dialog) is primarily an error prevention mechanism to obviously alert the user to unsaved changes they will lose upon exit. This usually occurs when the user attempts to click the red X in the top right corner of an application after they have made changes to a file.

A decade ago, these dialogs were consistently confusing for users with unclear labeling of the save dialogs (alert boxes). Many save dialogs would look something like this:

The problems with the above screen are the ambiguous nature of the screen label, the labels for the dialog and buttons along with the dialog itself being simply too long.

Screen/Window Label: Use 1-2 words (nouns) that are descriptive of the alert. In this case, “Unsaved Changes” is a much better label than “Microsoft Word” (as seen below) or “Adobe Fireworks CS6.” The label for the window is usually the first place the user will look. Make sure it says what it is and is clear.

Button Labels: “OK” was a label commonly used in these interfaces for a number of years and it wasn’t always clear as to what “OK” meant. In addition, the Cancel button (above) also does not offer clarity. What is being canceled? This has become standardized today so most users know Cancel will return them to the application and cancel the closing process. However, a better label could be something descriptive such as “Return to Word.” (This makes for longer buttons though.) Each button should succinctly describe the action that will occur when the user clicks it since your user is much more likely to read the button than the dialog. So, “Save,” “Don’t Save” and “Return to ___” is much better than OK, Exit and Cancel. I will note: I am on the fence with Cancel as a label since I think it has steadily become a convention most users recognize.

Dialog: The dialog should be short and succinct. We know through usability research that humans often will not read long dialogs…or short dialogs in many instances. Thus this dialog above should (or could) be shortened to a single sentence such as “Would you like to save changes?” But remember, the user is more likely to read the button labels than the dialog above them.

A better save dialog looks something like this:

One other problem is the action this dialog performs. Ideally, you want to save from this dialog. There are many save dialogs that will return you back to the application in order to save. This was the problem with our save dialog as seen here:

Clicking the Yes button returns you to our software where you have to save manually. Moreover, the dialog in the window was frequently skipped or resulted in a confused user as to what action to take.

Once you fix the labeling and dialog, the key factor to consider is that these are error prevention mechanisms. As such, the designer must consider what the intended action of the user should be and design considering both of these factors. So in looking at the Microsoft example above, there is still room for improvement.

When you are attempting to prevent a user from making an error, you want to design a feature to exploit human behavior. Put simply, you want to make it more difficult for the user to make the error than to perform the intended action. We are a bit lazy as humans and prefer the easy route. So make it easier to save the changes than exit the system and lose changes. The intended action we would expect of a user in most systems is they will want to save changes before exiting. The red X in the corner is a quick method to exit applications only intended for users doing a demo or those who really don’t want to save changes…or those who have saved changes and want to exit quickly.

You can design a dialog with pre-selected options such as this:

The above screen forces the user to confirm they want to leave the system without making changes by adding an extra step to the exit process. This is, of course, inconvenient for the small percentage of our users who may actually wish to leave the system without saving changes. And this was the feedback I received from my stakeholders. But as a designer, you have to consider the intended action of the majority of your users. You must also consider the impact of the design.

I have been working in the healthcare industry for more than a decade at this point and losing changes can be catastrophic. In my current position, losing the changes made to a hearing instrument is one of the top fears of audiologists. So you have to ask yourself, will users resent a design more for an extra click or will they resent it more for losing all of their data?