Design better alerts
Alert design best practices and examples
From the mundane to the life changing, we are bombarded with notifications that annoy, alert, and redirect our attention and actions.
Although alerts in our digital world may seem trivial, they should be crafted with great care and responsibility. This article focuses on how to design better user interface alerts.
I published the file I created to illustrate the examples in this article to the Figma Community.
Alert types:
Informational alerts
Informational alerts provide the user with a passive callout to information. These types of alerts can be within page content or presented at the top of a z-index hierarchy. Informational alerts should usually not be included in a modal, as that is too intrusive for a passive callout. Informational alerts don’t usually contain action buttons except for the ability to close the alert.
Toasts
A toast is a contextual alert that usually pops up from the bottom of the screen with a non-critical message, typically in response to an action. The toast disappears after a few seconds and shouldn’t interrupt the user’s current task. Toasts often provide the ability to undo an action just taken or alert the user of an action that just occurred. Toasts shouldn’t contain critical error messages or items that must be actioned.
Notifications
Notifications are usually activated by another user’s action (e.g. commenting on a post) or a system generated event. Unlike toasts, the notification isn’t temporary and usually lives in a notification menu. However, like toasts, notifications shouldn’t interrupt the user’s current task.
Confirmations
Confirmations ask the user to verify an action. Confirmations are used for destructive actions (e.g. deleting a folder containing items) or consequential creation actions (e.g. publishing an article). Confirmations are usually presented in a modal and prevent other user interactions until a decision is made. Confirmations should explicitly state the outcome and consequences of the action.
Learn more in an article I wrote on confirmation design best practices.
How alerts are activated:
System activated
System activated alerts occur on a global app level and aren’t triggered by user action. They can be action-required or passive alerts. Examples include, subscription renewal notification, scheduled app maintenance alert, app download available, etc.
User activated
User activated alerts occur in response to a someone committing some type of action within the app. Examples include, user liking a post, user sending a message, deleting/creation confirmation, etc.
Contextually activated
Contextually activated alerts occur in relation to temporary circumstantial events. Examples include, location and time-based alerts, in-app accomplishments, etc.
Passively activated
Passively activated alerts are informational and don’t require action. They can be presented in context to page content or presented as a banner. Examples include, promotion of an upcoming event, important callout, cookie notification, etc.
I aim to design, code, and write about UI components and patterns for enterprise SaaS. I’m creating a product that allows software designers and engineers to plug into a comprehensive set of UI components to build amazing interfaces. Stay tuned!
If you’re interested, sign up to stay informed on my progress.
