Guides notification hierarchy for inline messages, toasts, banners, modals matching urgency to disruption level, with dismissal rules, color/icon standards, and alert fatigue prevention.
How this skill is triggered — by the user, by Claude, or both
Slash command
/saas-design-principles:notification-hierarchyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The notification hierarchy is one of the most commonly misapplied patterns in SaaS. IBM Carbon's framework provides the clearest decision guide. Each notification type has a specific purpose — misusing them causes alert fatigue and lowers productivity.
The notification hierarchy is one of the most commonly misapplied patterns in SaaS. IBM Carbon's framework provides the clearest decision guide. Each notification type has a specific purpose — misusing them causes alert fatigue and lowers productivity.
From lowest to highest disruption:
Contextual feedback within a specific UI section. Persists until resolved.
Use for: Validation errors, field-level guidance, status indicators.
Brief, non-blocking confirmations of completed actions.
Use for: "Item saved," "Email sent," "Record updated."
Rules:
System-level or product-level notifications not tied to a specific task.
Use for: Maintenance windows, plan limits, degraded service, required actions.
Rules:
Block all other interaction. The nuclear option.
Use exclusively for:
Never use modals for: Informational messages, success confirmations, or anything that could be a toast or banner.
| Scenario | Notification Type |
|---|---|
| Field has a validation error | Inline message |
| User saved a record successfully | Toast (auto-dismiss 3s) |
| User deleted something (with undo) | Toast (persist until dismissed) |
| System maintenance in 30 minutes | Banner |
| User's plan is approaching its limit | Banner |
| User is about to delete their account | Modal |
| Session is about to expire | Modal (with countdown) |
Standardized across every major design system:
| Color | Meaning | Icon Required |
|---|---|---|
| Blue | Informational | Yes |
| Green | Success | Yes |
| Yellow | Warning | Yes |
| Red | Error/Danger | Yes |
Never rely on color alone for meaning. Each status must also have a unique icon — this is both an accessibility requirement and a usability one.
IBM Carbon explicitly warns: "Frequent distractions lower productivity and can lead to alert fatigue."
The principle: If uncertain whether a notification is necessary, it probably isn't. Confine each notification to the portion of the interface it's relevant to.
Working implementations in examples/:
examples/toast-system.md — Toast manager with 4-toast limit, auto-dismiss, undo actions, and color/icon system in ReactWhen reviewing or building notification systems:
npx claudepluginhub oborchers/fractional-cto --plugin saas-design-principlesDesigns UI feedback for user actions: immediate responses, confirmations via toasts/checkmarks, status indicators, notifications across visual/text/audio/haptic channels with hierarchy and accessibility best practices.
Writes notification copy matching component type (toast, banner, modal) to urgency, front-loads subjects, and limits to one action per notification.
Maps user actions (form submission, delete, errors) to feedback mechanisms (toast, modal, inline) with copy that confirms success or explains failure + recovery.