Dialog boxes are used to ask the user for input or information. They should not be used frequently – only for operations that are important enough to warrant their own windows. Here are a few dialog box guidelines.
The classic dialog box flaw is to use Yes and No for the buttons. This forces the user to read the whole dialog box very carefully to know what he or she is agreeing or disagreeing to. Consider the following examples, from Windows XP and Mac OS X, respectively.
The first example gives the user no indication whatsoever of what this dialog is. Without the dialog box text, it is impossible to know what is going on. Meanwhile the second example is perfectly obvious even without the explanation text. Both examples are from standard Save windows. Mac OS uses verbs for the button titles, so it is obvious what will happen when they are selected, and the user doesn't even need to read the actual dialog box message.
When the command cannot be described by a verb, don't resort to Yes and No. Use OK and Cancel instead, and make OK initiate the command. If the command or operation could be consirered to cause data loss, always make Cancel the default button.
If the user doesn't understand the dialog, the developer has failed miserably. In general, each dialog box that is not a standard Save or Open dialog should feature two message elements: a message with the primary question or warning, and an additional descriptive text supplying additional information, such as "This action cannot be undone". See the example on the right for a real-world example of what you should never do. The dialog in question has an inappropriate title message, but worse than that, it asks if the user is "sure" without giving a hint on what the user should be sure about.
On the other hand, don't overdo descriptive messages. It's bad to not tell the user what is going on, but it's almost just as bad to give them too much information. Long messages are slower to read through than short, concise ones, and long messages also have a bigger chance of being frustratingly confusing.
If the dialog box you are designing features more than two pushbuttons or other controls, use spacing to convey meaning. Consider the examples from section 1 again:
The first example fails to use any meaningful spacing. The distances between the pushbutton controls are identical, despite the fact that the buttons correspond to commands that have very distinct outcomes. Interestingly, the one button that causes dataloss is rather inconveniently smack in the middle of the button group. Thus it's the easiest button to hit accidentally: you can accidentally cause dataloss by clicking a few pixels to the right of the Yes button OR a few pixels left of the Cancel button.
The second set of buttons uses spacing much more effectively. Since the image in question is from a "Do you want to save before closing" prompt, just like the other set of buttons, Cancel will cause the close event to cancel, and Save will save the document and then close. Thus Don't Save is the only command that will directly cause unsaved data to disappear. Therefore there is a significant space between it and Cancel & Save, both of which do not directly erase unsaved changes. The decision to place Don't Save quite far away from the other buttons also makes it quite difficult to accidentally click Don't Save.
Don't try to protect your users from themselves. Some apps assume that the user is a security risk and that data should be protected by requiring the user to type in a message, usually a variant of "Yes", to proceed with the command the user has initiated. This really slows down users and makes them feel less good about the program they are working in. People rarely like it when they feel they are being considered idiots. Requiring keyboard input can also be incosiderate towards users who have certain disabilities due to which they may not be good with the keyboard but can use the mouse.