メニュー
Design product notification emails. Use when building activity alerts, digests, status updates, or managing notification frequency and user preferences.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | notification-design |
| description | Design product notification emails. Use when building activity alerts, digests, status updates, or managing notification frequency and user preferences. |
| license | MIT |
Design product notification emails that inform without overwhelming - covering notification types, frequency management, digest strategies, and preference centers.
transactional-email - receipts, auth emails, and other must-deliver messagesemail-sequences - drip campaigns and automated multi-step flowstemplate-design - HTML email templates that render everywhereemail-compliance - CAN-SPAM, GDPR, unsubscribe requirementssuppression-lists - managing bounces, complaints, and opt-outsrate-limiting - volume controls that protect sender reputationNot all notifications are equal. Each type has different urgency, expected frequency, and design requirements.
Password resets, login from new device, two-factor codes, account lockouts.
Order confirmations, shipping updates, subscription renewals, payment receipts.
Comments on your post, mentions, replies, collaboration invites, task assignments.
New followers, likes, reactions, shares, endorsements.
New features, maintenance windows, policy changes, terms updates.
Approaching plan limits, failed payments, upcoming renewals, usage spikes.
The biggest mistake in notification design is sending everything via email. Each channel has a natural fit.
Users associate different urgency levels with different channels. Respect this:
| Urgency | Best channel | Examples |
|---|---|---|
| Critical - act now | Push + email | Security breach, payment failed, system down |
| Important - act today | New comment needing response, task assigned | |
| Informational - act when convenient | Email digest | Activity summary, weekly report |
| Low - FYI only | In-app | Likes, views, minor updates |
Sending low-urgency notifications through high-urgency channels (push for likes, individual emails for reactions) trains users to ignore all your notifications - including the important ones.
Notification fatigue is the primary reason users unsubscribe. More than 3 emails per week from a single product starts driving fatigue scores up significantly.
Based on production fatigue scoring (from molted.email):
| Weekly sends to one recipient | Fatigue level | Recommendation |
|---|---|---|
| 0-1 | Low (score 0-10) | Safe to send |
| 2-3 | Moderate (score 10-20) | Monitor engagement |
| 4-5 | High (score 20-30) | Reduce frequency, switch to digests |
| 5+ | Critical (score 30+) | Stop individual sends, digest only |
These are per-product thresholds. A user getting 2 emails/week from your app plus 3 from their bank plus 4 from a shopping site is getting 9 total - your 2 feel like more than 2.
Track these per-recipient to catch fatigue before unsubscribes:
Set hard limits on how many notifications a single user receives:
Per-recipient caps:
- Security/transactional: unlimited (but these should be rare by nature)
- Activity notifications: max 5/day via email, overflow goes to digest
- Marketing/product updates: max 2/week
- Social/engagement: email digest only, max 1/day
When a user hits the cap for a category, queue remaining notifications for the next digest instead of dropping them.
Digests consolidate multiple notifications into a single email. They are the primary tool for fighting notification fatigue while keeping users informed.
Group notifications by fixed time windows:
Trigger a digest when conditions are met rather than on a fixed schedule:
The Padlet approach is a good model: when a user is on pace to receive more than 3 emails about the same resource they haven't visited, send one email saying "there's a lot of activity" instead of continuing to send individual notifications. This respects the inbox while still surfacing the signal.
A good digest email has:
Some notifications must always be sent immediately, never batched:
A preference center lets users control their notification experience instead of choosing between "everything" and "unsubscribe from all."
At minimum, offer these controls:
Notification preferences for [User Name]
Activity on your content
[ ] Comments and replies [Instant / Daily digest / Off]
[ ] Mentions [Instant / Daily digest / Off]
[ ] Reactions and likes [Daily digest / Weekly digest / Off]
Collaboration
[ ] Task assignments [Instant / Daily digest / Off]
[ ] Project invitations [Instant / Off]
[ ] Status changes [Daily digest / Weekly digest / Off]
Product updates
[ ] New features [On / Off]
[ ] Tips and best practices [On / Off]
Billing
[ ] Payment confirmations [Always on]
[ ] Usage alerts [On / Off]
[ ] Renewal reminders [Always on]
Account security
[ ] Login alerts [Always on]
[ ] Password changes [Always on]
--
Pause all non-essential emails for: [1 week / 1 month / 3 months]
Unsubscribe from all marketing emails
Your defaults determine the experience for 80%+ of users who never visit the preference center.
Every notification email from your product should share a recognizable structure:
[Your Logo]
[Notification headline - what happened]
[Context - who did it, where, preview of content]
[Primary CTA button]
[Footer: manage preferences | unsubscribe | help]
Once users recognize the pattern, they can scan your notifications in seconds without reading every word.
Subject lines for notifications should be scannable and differentiated by type:
| Type | Pattern | Example |
|---|---|---|
| Activity | [Actor] [action] [object] | "Alex commented on your design" |
| Digest | [Count] updates [timeframe] | "8 updates on your projects today" |
| Security | [Urgency]: [event] | "Security alert: new login from Chicago" |
| Billing | [Event]: [detail] | "Payment failed: Visa ending 4242" |
| System | [Product]: [change] | "Acme: New export feature available" |
Avoid generic subjects like "You have a notification" or "New activity on your account." They train users to ignore you.
Always include a plain text version. Some corporate email systems strip HTML, and accessibility tools work better with plain text. The plain text version should contain the same information and links as the HTML version.
Notification emails are not newsletters. They should convey one piece of information and one action. A comment notification doesn't need your full product tour in the footer. Design for scan-and-decide: the user should know in 3 seconds whether they need to act.
Use consistent Message-ID, In-Reply-To, and References headers to group related notifications into threads in the user's inbox. Activity on the same resource (post, project, document) should thread together rather than creating separate inbox entries.
If your notification system supports threading, replies within a thread can bypass per-recipient cooldowns since the user is already engaged in the conversation. Production email policy engines (like molted.email) handle this by skipping cooldown checks when a threadId is present.
Track these for each notification category independently. A 40% open rate on security alerts and a 5% open rate on social notifications tell you very different stories.
| Metric | Healthy range | Warning signs |
|---|---|---|
| Open rate | 40-60% for transactional, 20-40% for activity, 15-25% for digests | Below 15% for any type means users aren't finding value |
| Click rate | 5-15% for transactional, 2-5% for activity digests | Below 2% across the board suggests poor CTAs or irrelevant content |
| Unsubscribe rate | Below 0.2% per send | Above 0.5% per send is a frequency or relevance problem |
| Complaint rate | Below 0.1% | Above 0.3% risks deliverability damage (Google's threshold) |
Note: Apple Mail Privacy Protection inflates open rates by preloading images for ~46% of email clients. Weight click-through rates and downstream actions more heavily than open rates for accurate measurement.
The most common mistake. When every event generates an email - new comment, new like, new follower, new view - users learn that your emails are noise. Reserve email for notifications that actually need attention. Route low-value signals to in-app or digest only.
Teams add notification emails ad-hoc as features ship. "Users should know when someone comments, right?" leads to 15 notification types with no frequency management, no digests, and no preference center. Design the notification taxonomy before building individual notifications.
New users who sign up, trigger a few actions, and immediately get 8 emails in an hour will unsubscribe or mark you as spam. Default to digest mode for high-frequency categories. Let users opt into instant delivery.
If the only way to reduce notifications is to unsubscribe entirely, that's what users will do. Put "Manage notification preferences" in every email footer, right next to the unsubscribe link. Better yet, offer inline frequency controls: "Too many emails? Switch to weekly digest" directly in the notification.
"You haven't logged in for 7 days!" is for your engagement metrics, not for the user. Re-engagement notifications should offer genuine value: "3 tasks are waiting for your review" is actionable. "We miss you!" is not.
Continuing to send the same volume to users who stopped opening emails 30 days ago. Track per-recipient engagement and automatically reduce frequency for disengaged users. After 30+ days of no engagement despite multiple sends, stop non-critical notifications entirely until the user re-engages.
When your notification emails share infrastructure with marketing campaigns, a bad marketing send (high bounces or complaints) can damage delivery of your transactional and notification emails. Use separate sending domains or subdomains: notifications.example.com for product notifications, mail.example.com for marketing.
User triggers the same action twice (double-clicks, page refresh, API retry) and gets duplicate notifications. Use deduplication keys tied to the event, not the request. If the same comment already generated a notification, don't send another one.
Diagnose email problems and plan email infrastructure. Use when emails land in spam, bounce rates spike, deliverability drops, open rates decline, providers throttle sending, you need to set up email for a new product, or you're not sure which email skill to use.
Choose and configure an agent-native inbox provider for AI agents that send and receive email. Use when giving an AI agent its own email address, setting up two-way agent email communication, comparing agent inbox platforms, or adding guardrails to autonomous email workflows.
Build dashboards, alerts, and monitoring systems for email sending operations. Use when setting up deliverability monitoring, configuring alert thresholds, checking blocklists, building email metrics dashboards, or responding to deliverability incidents.
Classify inbound email replies by intent and route them appropriately. Use when building reply handling for outreach, support, or transactional email - detecting interested, not interested, OOO, bounce, unsubscribe, forwarded, and question replies.
Maintain email conversation context across messages using threading headers. Use when building thread reconstruction, linking replies to conversations, detecting thread hijacking, stripping quoted content, or providing thread context to AI agents.
Receive, parse, and process incoming email via provider webhooks. Use when setting up inbound email handling, parsing MIME messages, extracting content from replies, detecting threads, filtering spam on inbound, or routing incoming messages.