Toggle navigation

Alert Guidelines

Any UI control that captures the user's attention can be thought of as an alert. They should be used wisely so they aren't overwhelming.

For the purposes of this guide, alerts are characterized by being interruptive and requiring action to proceed, unlike notifications or validation messages.

When to use alerts

Every alert guideline says to use alerts sparingly. Overwhelming users with alerts dilutes their importance and annoys users. The Microsoft Windows Application Design Guidelines suggest when to use alerts this way: "Don't overwarn. Limit warnings to conditions that involve risk and are immediately relevant, actionable, not obvious, and infrequent. Otherwise, remove or rephrase the message."

It lists specific reasons for using alerts, such as:

  • Awareness
  • Error prevention
  • Imminent problem
  • Risky action confirmation
  • Unintended consequence confirmations
  • Clarifications

Here are some examples:

The U.S. Web Design System suggests that, when designing forms, consider using inline validation instead of (or in addition to) alerts.

How to use alerts

The macOS Human Interface Guidelines are succinct in their guiding principle: "When an alert is necessary, your most important job is to explain the situation clearly and give users a way to handle it."

More specifically:

  • Create specific, actionable, user-centered error messages. Users should either perform an action or change their behavior as the result of the message.1
  • Use pre-defined or system styles when possible. Don't deviate from familiar.
  • Generally, use 2-button alerts (for dialogs overlays).2
  • Express everything in the user’s vocabulary. Use clear language, free from jargon.3
  • The default button name should correspond to the action you describe. In particular, it’s a good idea to avoid using OK for the default button.3
  • They should be easy to dismiss when appropriate (e.g., responding to Escape key or the Close button in a dialog, in addition to an explicit dismiss button or link).
  • Refer to your existing style and tone guide if you have one (you can find some inspiration in these voice, tone, and content guides, if you don't). As an example, the Microsoft Windows Style and Tone guidelines writes this about using "please" and "sorry":
    • "Use please whenever its absence would be considered curt"
    • "Use sorry only in error messages that result in serious problems for the user"

Basic usage


Similar to validation messages, alerts can be used to communicate errors or provide warnings about potentially destructive actions. Unlike validation, however, alerts should generally not be used for success messages, unless it is to notify that an important action has completed.


As shown above, alerts vary by operating system and platform. Most software platforms provide built-in alert components. It is best to use default system styles for alerts. Some operating systems allow for icons and/or color to differentiate states or types of alerts.


  1. KDE Human Interface Guidelines
  2. iOS Human Interface Guidelines
  3. macOS Human Interface Guidelines

Further reading

By Leon Barnard
Got questions or feedback? Email