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:
- Error prevention
- Imminent problem
- Risky action confirmation
- Unintended consequence confirmations
Here are some examples:
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.”
- Create specific, actionable, user-centered error messages. Users should either perform an action or change their behavior as the result of the message. (KDE Human Interface Guidelines)
- Use pre-defined or system styles when possible. Don’t deviate from familiar.
- Generally, use two-button alerts (for dialogs). (iOS Human Interface Guidelines)
- Express everything in the user’s vocabulary. Use clear language, free from jargon. (macOS Human Interface Guidelines)
- Ensure that the default button name corresponds to the action you describe. In particular, it’s a good idea to avoid using OK for the default button. (macOS Human Interface Guidelines)
- 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 here, 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”
Types of Alerts
Similar to validation message, 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.