Dialog Box Design Concepts

Dialog Boxes
Dialog Box Usage Patterns

When properly used, dialog boxes are a great way to give power and flexibility to your program. When misused, dialog boxes are an easy way to annoy users, interrupt their flow, and make the program feel indirect and tedious to use. Modal dialog boxes demand users' attention. Dialog boxes are often easier to implement than alternative user interfaces (UIs), so they tend to be overused.

Designing effective dialog boxes

A dialog box is most effective when its design characteristics match its usage. A dialog box's design is largely determined by its purpose (to offer options, ask questions, provide information or feedback), type (modal or modeless), and user interaction (required, optional response, or acknowledgement). Its usage is largely determined by the context (user or program initiated), probability of user action, and frequency of display.

Dialog box characteristics

Modal dialog boxes have these characteristics:

  • Are displayed in a window that is separate from the user's current activity.
  • Require interaction—users must close before continuing with the owner window.
  • Can break users' flow.
  • Use a delayed commit model; changes aren't made until explicitly committed.
  • Have command buttons that commit to task.
  • Best used for critical or infrequent, one-off tasks that require completion before continuing.

Modeless dialog boxes have these characteristics:

  • Can be displayed in context using a task pane or with an independent window.
  • Don't require interaction—users can switch between the dialog box or pane and the calling window as desired.
  • Can use an immediate commit model; changes are made immediately.
  • Have command buttons that close the window.
  • Best used for frequent, repetitive, or on-going tasks.

Dialog box interactions

Dialog boxes also have different types of user interaction:

  • Response required. Users must respond to provide required input. For example, a Replace command requires displaying a dialog box so users can specify the Find and Replace strings.
  • Response optional. Users might respond to provide optional input, but the default values are usually acceptable. For example, while users might make changes in a Print dialog box, they usually accept the default options.
  • Acknowledgement only. Users' only interaction is to acknowledge the dialog box by reading and closing it.

Dialog box contexts

Dialog boxes are displayed in different contexts:

  • User initiated. A dialog box is displayed as the direct or indirect result of a user interaction.
  • System or program initiated. A dialog box is displayed independently of any user interaction.

Creating effective dialog boxes

Consider these effective examples:

  • A modal dialog box is an excellent choice for user initiated, one-off tasks that require a response:

    Screen shot of 'Want to save changes?' dialog box

  • A modal dialog box is an excellent choice for infrequent system or program initiated, one-off tasks that require a response:

    Screen shot of 'Router not working' dialog box

  • A modeless dialog box is an excellent choice for user initiated, on-going tasks:

    Screen shot of Find and Replace dialog box

  • A modal dialog box is a good choice for critical or infrequent, program initiated messages that are likely to change user behavior:

    Screen shot of Low Battery warning dialog box

Now consider these ineffective examples:

  • A modal dialog box is a poor choice for frequent tasks to provide options that users don't have to change. Instead, use the default options without asking, but allow users to make changes later.

    Screen shot of a modal Paste Options dialog box

    Screen shot of a modeless formatting tag

    In the correct example, Microsoft® Word 2007 correctly displays a modeless UI instead of a modal dialog when users paste text. That way, users aren't required to respond.

  • A modal dialog box is a poor choice for messages that are unlikely to change user behavior. Instead, consider using a notification or a status bar, or even doing nothing.

    Screen shot of a modal folder-status dialog box

    Screen shot of Status bar displaying folder status

    Using a modal dialog box for status is annoying. In the correct example, Microsoft Outlook® correctly uses the status bar for this purpose, instead.

  • A modal dialog box is often a poor choice for displaying important options. Instead, display essential options either directly with in-place UI, or on demand using progressive disclosure.

    Screen shot of two modal dialog boxes

    Screen shot of Find dialog box with 'Less' button

    In this example, the search options could be set in an owned dialog box, but Word correctly uses progressive disclosure instead.

  • A modal dialog box is a poor choice for giving feedback of minor importance, because it requires acknowledgement.

    Screen shot of 'Search item not found' dialog box

    In this example, Word uses a modal dialog to indicate that it has finished searching a document, which forces users to click the OK button to acknowledge. Modeless feedback would be a better choice.

If you do only one thing...
Make sure that your dialog box design (determined by its purpose, type, and user interaction) matches its usage (determined by its context, probability of user action, and frequency of display).

Improving ineffective dialog boxes

Often the best solution to a bad modal dialog box is either to eliminate the dialog or to redesign it in a way that isn't modal. Some people have concluded that this means all modal dialog boxes are bad and should be eliminated. This is not a correct conclusion (except for Web-based applications, which really should try to avoid pop-up blockers). For example, it is perfectly acceptable to interrupt users with a model dialog box for tasks that require interaction. Modal dialog boxes are the right choice in many circumstances. Trying to eliminate every modal dialog box can reduce the quality of your overall UI.

If you have a dialog box that isn't effective, consider these alternatives:

  • If the dialog box is modal but doesn't have to be, consider using a modeless dialog box, task pane, or other modeless UI.
  • If the dialog box is for acknowledgement only, consider adding commands to make it actionable. For example, if the dialog box is presenting a problem, consider also providing solutions to the problem.
  • Review Is this the right user interface? to determine if there is a better solution.
  • If the user experience isn't harmed by removing the dialog box, consider just removing it.

Using the Don't show this <item> again option

Sometimes optional modal dialog boxes turn out to be annoying, especially when displayed often. Such dialog boxes typically strive to inform users about a recurring situation or a feature that addresses such situations. A common solution to this problem is to provide a Don't show this <item> again option that suppresses the dialog box in the future:

Screen shot of dialog defining the Information Bar

In this example, the dialog box attempts to educate users about a recurring situation. Selecting Don't show this <item> again prevents the dialog box from being displayed in the future.

This solution has problems. It assumes that users:

  • Make rational decisions about which dialog boxes to suppress based on their future needs and not on their emotions ("Stop pestering me!").
  • Can accurately recognize the reoccurring situations in the future.
  • Can remember and apply the information from the previous instance of the dialog box, no matter how long ago it was displayed.

If users fail in any of these steps, they won't see the dialog box in their moment of need, and there is no obvious way to get the dialog box back once suppressed.

If you think your dialog box needs a Don't show this <item> again option, that is a clear sign that it is annoying and potentially unnecessary. Before adding this option, consider the following alternatives:

  • Change the design to eliminate the need for the message.
  • Make the hard design decision: do users really need to see this dialog box? Will bad things happen if users don't know this information? If so, always display it; if not, never display it.

    Screen shot of 'Dismiss reminders?' dialog box

    In this example, users don't need this confirmation because dismissing Outlook reminders has no adverse consequences. This confirmation shouldn't be displayed at all.

  • Use less intrusive solutions, such as in-place UI, progressive disclosure, modeless UI (such as balloons or tooltips), or notifications.

Do the right thing by default. Don't force users to configure their way out of a bad initial experience. Keep in mind that littering your program with unnecessary modal dialog boxes is more likely to foster outrage than user education. At a certain point, users tend to dismiss such dialog boxes without reading them.

If you are convinced that users really need to see the information for a while and a dialog box is the best solution, only then should you use the Don't show this <item> again option. If users may need to restore these dialog boxes, provide a Restore messages command in the program's Options dialog box.

Tip: When running your own program, don't change any of the Don't show this <item> again defaults. Doing so helps you evaluate your program's experience the same way your users will.

© 2014 Microsoft. All rights reserved.