This skill should be used when the user is building or reviewing toast notifications, banners, modal dialogs, inline messages, snackbars, or alert systems. Covers the four-tier notification hierarchy, feedback patterns, success and error messaging, and alert fatigue prevention.
npx claudepluginhub oborchers/fractional-cto --plugin saas-design-principlesThis skill uses the workspace's default tool permissions.
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.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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: