UX Notifications And Toasts

Notifications & Toasts Skill

How this skill behaves (read first)

This is a generative skill. The default failure modes: urgency inflation (everything is an alert; success messages interrupt), frequency abuse (repeat pings for the same event until users kill all notifications), and attention disrespect (badges for non-notifications, pings with no user value). A notification spends the user's attention — the type must match the message's actual urgency, and the system must stay worth listening to. This skill gates:

1. Establish urgency, audience moment, and channel — these pick the type.
2. Apply the always-true core — type-urgency match, frequency discipline, content brevity, user control.
3. Surface the engagement levers (push strategy, personalization, rich media) with trade-offs — this is dark-patterns-adjacent territory.

Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, ux-microcopy-audit, and ux-dark-patterns-audit for validation.

Step 0 — Establish context before designing

Ask if not known; state the assumption if proceeding without an answer:

• How urgent is the message, really? Needs action now (failed payment) → persistent alert. Useful soon (storage near limit) → warning. FYI (saved, sent) → transient snackbar/toast. Just "something's new" → badge. Be honest — urgency inflation is the root failure.
• Where is the user? In the app and active → don't interrupt: increment a badge or insert the update inline. Away → push (if opted in). Mid-task → batch for later.
• Whose goal does it serve? A notification that serves only the business (re-engagement nag) costs trust. If users wouldn't thank you for it, reconsider.
• Platform — Android toasts/snackbars vs. iOS conventions; push character limits (~39 title / ~150 body).

The always-apply core (correct for almost every case)

Match the type to the urgency

• Badge — dot (or count) top-right of an icon, for unread notifications only — never scores, weather, or marketing. Dot shape, conventional placement; disappears once seen.
• Status badge — at-a-glance state (online, in-progress, completed) — informational, not a ping.
• Banner — temporary strip (top/bottom) for events worth a glance (new message preview); doesn't block.
• Snackbar — bottom-of-screen confirmation in context, often with one action ("Message sent" + Undo). Never covers a FAB or important controls.
• Toast — low-priority system messages; can't be dismissed, can stack — use sparingly.
• Alert — persists until resolved; for things that demand attention. Success = green + check, auto-dismissing; info = ℹ; warning = time-to-act heads-up; error = red + exclamation, immediate action. Don't dress an info message as a warning.
• Push — reaches users outside the app; the highest-cost channel, opt-in and easiest to lose (see gated table).

Frequency discipline

• One event, one notification. No re-pings for the same unread message; group related notifications instead.
• Foreground grace: when the app is open, update the badge or insert content into the view — don't fire a system notification at someone already looking at the screen.
• Contextual and personal beats broadcast: segment, reference the user's actual journey (usage limit approaching, feature they use), never spray.

Content

• Concise and scannable: short title carrying the message, plain language, no jargon. Push: ~39-char title, ~150-char body — shorter is better.
• Actionable where possible: snackbar Undo, push actions that resolve without opening the app.

User control (non-negotiable)

• Easy to mute or turn off — globally and per-type, with frequency options. Users who can tune notifications keep them; users who can't, kill them (or the app).
• No blame or shame in opt-out flows.

The context-dependent decisions (surface, don't auto-apply)

Validate the result (orchestration)

Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.

After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics, microcopy, and dark-patterns are Tier A (auto-run); accessibility, aesthetics, and mobile-responsiveness are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage; mobile-responsiveness applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.

• ux-heuristics-audit (Tier A) — visibility of system status without disruption, match between urgency and presentation, user control and freedom.
• ux-accessibility-audit (Tier B — offer; narrow under a design system) — color-plus-icon urgency coding (never color alone), screen-reader announcement of transient messages, snackbar timing sufficient to read.
• ux-aesthetics-audit (Tier B — offer; suppress under a design system) — alert styling restraint, badge/banner visual noise across the interface.
• ux-microcopy-audit (Tier A) — title/body brevity, plain language, CTA verb quality, opt-out wording.
• ux-dark-patterns-audit (Tier A) — the backlog flags this skill as attention-respect territory: manufactured urgency, nag loops, buried mute settings, guilt-trip opt-outs.
• ux-mobile-responsiveness-audit (Tier B — offer; applies only on mobile) — when the context is mobile: snackbar/FAB layout, push rendering across OSes.

If the audits surface a conflict (e.g., engagement targets vs. notification fatigue), resolve back toward the primary task: a notification system only works while users trust it — protect that trust over any single campaign.

Common do/don't patterns

Source lessons (Uxcel)

• Notification Types & When to Use Them
• Best Practices for Designing Notifications
• Push Notification Strategies That Drive Engagement
• Designing Mobile Notifications & Dialogs