skillZs
★ LIVE SKILL TAGS ★
>>> LIVE SKILLS INDEX <<<
* OPEN SOURCE *
NO LOGIN, NO TRACKING
※ REAL INSTALL DATA ※
← back to all skills
uxcel-lab/product-skills113 installs

ux-notifications-and-toasts

Design or critique notifications — pick the right type (badge, banner, snackbar, toast, alert, push) for the message's urgency, and respect user attention with timing, frequency, and opt-out controls. Trigger when the user asks to design or review notifications, toasts, snackbars, badges, banners, alerts, push notifications, or a notification strategy.

How do I install this agent skill?

npx skills add https://github.com/uxcel-lab/product-skills --skill ux-notifications-and-toasts
view source ↗

Is this agent skill safe to install?

  • Gen Agent Trust Hubpass

    The skill is a set of UX design guidelines for notifications and toasts. It contains no executable code, network operations, or sensitive data access, and all external links point to the author's official documentation.

  • Socketpass

    No alerts

  • Snykpass

    Risk: LOW · No issues

What does this agent skill do?

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)

DecisionApply whenAvoid / adapt whenDefault recommendation
Push notifications at allTime-sensitive, user-valued updates (order shipped, message received)Re-engagement nags, generic promos — the fastest route to opt-outTransactional first; promotional only with explicit, granular opt-in
Push opt-in askPrimed, at a relevant journey moment, with the value statedRaw system dialog at first launchPrime → ask in context (see ux-modals-and-dialogs for permission patterns)
PersonalizationName, past behavior, preferences — measurably higher engagementCreepy specificity; data users didn't expect you to usePersonalize from in-app behavior; stay transparent
Rich media (images/GIFs)Visual content adds real information (product image, delivery photo)Decoration that bloats a simple messageText-first; media when it informs
Location-based (geofencing)Genuine contextual value (gate change, store nearby with an active order)Surveillance-flavored marketing pingsHigh bar; explicit permission, obvious value
Timing optimizationSend in users' active hours, their time zoneOptimizing for clicks over usefulness (11pm "we miss you")User-behavior-based timing, capped frequency
Badge counts vs. dotsCounts for countable unread items (inbox)Counts that grow unbounded and induce anxietyDot for "something new"; count where the number helps
Performance monitoringTrack opens/CTR and opt-outs/mutes as fatigue signalsCelebrating opens while opt-outs climbTreat opt-out rate as the primary health metric

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

❌ Don't✅ Do
Every message styled as an urgent alertType matched to real urgency; most messages are quiet
Re-ping the same unread message hourlyOne event, one notification; group the rest
System notification while the user is in the appBadge increment or inline insert
Badge count showing the weatherBadges for unread notifications only
Success modal interrupting the flowAuto-dismissing snackbar/success alert
Snackbar covering the FABSnackbar above all content, clear of controls
Push permission dialog at first launchPrimed, contextual ask with stated value
"We miss you 😢" at 11pmTime-zone-aware, behavior-based, user-valued pings
Mute buried four screens deepPer-type controls, easy global off
150 characters of jargon~39-char title that carries the message
Ship without checkingHand off to heuristics + accessibility + aesthetics + microcopy + dark-patterns

Source lessons (Uxcel)

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/uxcel-lab/product-skills/ux-notifications-and-toasts">View ux-notifications-and-toasts on skillZs</a>