Warning Messages

Is this the right user interface?

Design concepts

Usage patterns

Guidelines

Presentation

Icons

Don't show this message again

Progressive disclosure

Default values

Text

Documentation

A warning message is a modal dialog box, in-place message, notification, or balloon that alerts the user of a condition that might cause a problem in the future.

A typical modal warning message.

The fundamental characteristic of warnings is that they involve the risk of losing one or more of the following:

●A valuable asset, such as important financial or other data.

●System access or integrity.

●Privacy or control over confidential information.

●User's time (a significant amount, such as 30 seconds or more).

By contrast, a confirmation is a modal dialog box that asks if the user wants to proceed with an action. Some types of warnings are presented as confirmations, and if so, the confirmation guidelines also apply.

Note: Guidelines related to dialog boxes, confirmations, error messages, standard icons, notifications, and layout are presented in separate articles.

Is this the right user interface?

To decide, consider these questions:

●Is the user being alerted of a condition that might cause a problem in the future? If not, the message isn't a warning.

●Is the UI presenting an error or problem that has already occurred? If so, use an error message instead.

●Are users likely to perform an action or change their behavior as the result of the message? If not, the condition doesn't justify interrupting the user so it's better to suppress the warning.

●Is the condition the direct result of an action initiated by the user? If not, consider using a non-critical event notification.

●Is the condition a special condition in a control? If so, use a balloon instead.

●For confirmations, is the user about to perform a risky action? If so, a warning is appropriate if the action has significant consequences or cannot be easily undone.

●For other types of warnings, does the user need to act now or in the immediate future? Don't display warnings if users can continue to work productively without immediate problems. Postpone the warning until the condition is more immediate and relevant.

Design concepts

Avoid overwarning

© 2010, Microsoft Corporation. All rights reserved. Page 357 of 882

Why is this notification a warning? What are users supposed to do (beside worry)?

●Are not obvious. Don't display a warning to state the obvious consequence of an action. For example, assume users understand the consequences of not completing a task.

Incorrect:

Canceling an incomplete wizard means the task doesn't get done...who knew?

●Occur infrequently. Constant warnings quickly become ineffective and annoying. Users often become more focused on getting rid of the warning than addressing the problem.

Incorrect:

Users are more likely to focus on getting rid of the warning than fixing the underlying problem.

A message that doesn't have these characteristics might still be a good message, just not a good warning.

Determine the appropriate message type

Some issues can be presented as an error, warning, or information, depending on the emphasis and phrasing. For example, suppose a Web page cannot load an unsigned ActiveX control based on the current Windows Internet Explorer® configuration:

●Error. "This page cannot load an unsigned ActiveX control." (Phrased as an existing problem.)

●Warning. "This page might not behave as expected because Windows Internet Explorer isn't configured to load unsigned ActiveX controls." or "Allow this page to install an unsigned ActiveX Control? Doing so from untrusted sources may harm your computer." (Both phrased as conditions that may cause future problems.)

●Information. "You have configured Windows Internet Explorer to block unsigned ActiveX controls." (Phrased as a statement of fact.)

To determine the appropriate message type, focus on the most important aspect of the issue that users need to know or act upon. Typically, if an issue blocks the user from proceeding, you should present it as an error; if the user can proceed, present it as a warning. Craft the main instruction or other corresponding text based on

that focus, then choose an icon (standard or otherwise) that matches the text. The main instruction text and icons should always match.

© 2010, Microsoft Corporation. All rights reserved. Page 359 of 882

Be specific

Warnings are more compelling when the following information is specific and clear:

●The source of the warning.

●The specific condition and potential problem.

●What the user should do about it.

●What happens if the user doesn't do anything.

Incorrect:

In this example, what is the potential problem? What is the user supposed to do, aside from not using the projector over the network? Without more specific information, all the user can do is feel bad about proceeding.

Correct:

In this example, the problem and consequences are clear.

© 2010, Microsoft Corporation. All rights reserved. Page 360 of 882

In this example, the feature icon has a warning overlay.

For modal dialog boxes with a warning footnote, put the warning icon in the footnote instead of the content area.

Correct:

In this example, the footnote has the warning icon.

For more guidelines and examples, see Standard Icons.

Don't show this message again

●If a warning dialog box needs this option, reconsider the warning and its frequency. If it has all the characteristics of a good warning (involves risk, and is immediately relevant, actionable, not obvious, and infrequent), it shouldn't make sense for users to suppress it.

For more guidelines, see Dialog Boxes.

Progressive disclosure

●If you must include advanced information in a warning message, reveal it by using progressive disclosure buttons (for example, "Show details"). Doing so simplifies the warning for typical usage. Don't hide needed information because users might not find it.

●Don't use "Show details" unless there really is more detail. Don't just restate the existing information in a different format.

For labeling guidelines, see Progressive Disclosure.

Default values

● Select the safest, least destructive, or most secure response to be the default.

Text

General

●Remove redundant text. Look for it in titles, main instructions, supplemental instructions, content areas, command links, and commit buttons. Generally, leave full text in instructions and interactive controls, and remove any redundancy from the other places.

●Don't use the terms "warning" or "caution" in the text. When used correctly, the warning icon sufficiently communicates that users must proceed with caution.

Incorrect:

In this example, the low battery dialog box is an imminent problem, so the main instruction describes what the user needs to do now.

●Be concise—use only a single, complete sentence. Strip the main instruction down to the essential information. If you must explain anything more, use a supplemental instruction.

●Use words like "now" and "immediately" if the user must act immediately. Don't use these words if there is no urgency.

●Be specific—if there are objects involved, give their full names.

●Use sentence-style capitalization.

Supplemental instructions

● The supplemental instruction for a warning is based on its design pattern:

●Don't repeat the main instruction with slightly different wording. Instead, omit the supplemental instruction if there is not more to add.

●Use complete sentences, sentence-style capitalization, and ending punctuation.

Commit buttons

● For warning dialog boxes, the commit buttons are based on its design pattern:

Problems aren't OK, so use Close instead.

Documentation

When referring to warnings:

● If the warning asks a question, refer to a warning by its question; otherwise, use the main instruction. If the question or main