Design product notification emails. Use when building activity alerts, digests, status updates, or managing notification frequency and user preferences.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Design product notification emails. Use when building activity alerts, digests, status updates, or managing notification frequency and user preferences.
license
MIT
Notification Design
Design product notification emails that inform without overwhelming - covering notification types, frequency management, digest strategies, and preference centers.
When to use this skill
Building a notification system for a product or SaaS app
Users are unsubscribing or complaining about too many emails
Deciding which events should trigger an email vs. push vs. in-app
Implementing digest or batching logic to reduce notification volume
Designing a preference center for notification controls
Choosing between instant alerts and periodic summaries
Notification open rates or click rates are declining
Related skills
transactional-email - receipts, auth emails, and other must-deliver messages
email-sequences - drip campaigns and automated multi-step flows
template-design - HTML email templates that render everywhere
suppression-lists - managing bounces, complaints, and opt-outs
rate-limiting - volume controls that protect sender reputation
Notification types
Not all notifications are equal. Each type has different urgency, expected frequency, and design requirements.
Security and account alerts
Password resets, login from new device, two-factor codes, account lockouts.
Channel: Email (primary) + push (secondary)
Timing: Immediate, always
User control: None - these are mandatory. Users cannot opt out of security notifications.
Design: Minimal, direct. Lead with the event ("Someone signed in to your account from a new device"). Include device/location/time details. Clear CTA ("If this wasn't you, secure your account"). Never include sensitive data in the email body - say "your payment was processed" not "your payment of $4,231.00 was processed."
Transactional confirmations
Order confirmations, shipping updates, subscription renewals, payment receipts.
Channel: Email (primary)
Timing: Immediate, triggered by user action
User control: None for critical confirmations. Optional for shipping status updates.
Design: Structured, scannable. Order number, line items, totals, tracking links. Keep the layout consistent across all transactional emails so users recognize the pattern instantly.
Activity notifications
Comments on your post, mentions, replies, collaboration invites, task assignments.
Channel: Email, push, or in-app depending on urgency and user preference
Timing: Immediate or batched into digests
User control: Full control - type, frequency, and channel
Design: Context-rich. Show who did what, include enough preview text that the user can decide whether to click through. "Alex commented on your design: 'Can we try a darker shade for the header?'"
Social and engagement notifications
New followers, likes, reactions, shares, endorsements.
Timing: Batched - never send individual emails for likes or reactions
User control: Full control, default to digest or off for email
Design: Aggregated. "3 people reacted to your post" not three separate emails. These are low-urgency, high-volume - the worst candidates for individual emails.
Product and system updates
New features, maintenance windows, policy changes, terms updates.
Channel: Email + in-app banner
Timing: Scheduled, infrequent
User control: Optionable for feature announcements, mandatory for terms/policy changes
Design: Brief, scannable. Lead with what changed and why it matters to the user. Link to full details.
Billing and usage alerts
Approaching plan limits, failed payments, upcoming renewals, usage spikes.
Channel: Email (primary) + in-app
Timing: Triggered by threshold or calendar event
User control: Limited - payment failures and renewal reminders should be mandatory. Usage alerts can be configurable.
Design: Clear numbers. "You've used 8,500 of your 10,000 monthly API calls (85%)." Include a direct link to upgrade or update payment method.
Channel selection
The biggest mistake in notification design is sending everything via email. Each channel has a natural fit.
When to use email
The user needs a permanent record (receipts, confirmations, legal notices)
The content is detailed enough to need formatting (order summaries, reports)
The user may not be online right now but should see this eventually
Digests and summaries that aggregate multiple events
The user hasn't installed your app or enabled push
When to use push notifications
Time-sensitive actions that need attention within minutes (security alerts, delivery arriving)
The user is likely on their phone and the notification is glanceable
Re-engagement nudges for users who haven't opened the app recently
Real-time collaboration (someone is typing, live updates)
When to use in-app notifications
The user is currently active in your product
Feature announcements and tips shown in context
Social engagement signals (likes, views) that don't warrant interruption
Anything you'd feel bad about putting in someone's inbox
The urgency-channel mapping
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
Email
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.
Frequency management
Notification fatigue is the primary reason users unsubscribe. More than 3 emails per week from a single product starts driving fatigue scores up significantly.
Frequency thresholds
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.
Fatigue signals to monitor
Track these per-recipient to catch fatigue before unsubscribes:
Days since last engagement: If a user hasn't opened or clicked in 14+ days, reduce frequency. At 30+ days with no engagement, consider stopping non-critical emails entirely.
Bounce count: Even one bounce adds significant fatigue risk. Multiple bounces should trigger suppression.
Complaint count: A single spam complaint is a severe signal. Two complaints from the same user means stop immediately.
Reply rate: For notifications that invite response, declining reply rates signal disengagement.
Implementing frequency caps
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.
Digest and batching strategies
Digests consolidate multiple notifications into a single email. They are the primary tool for fighting notification fatigue while keeping users informed.
Time-based digests
Group notifications by fixed time windows:
Hourly digest: For high-activity products where users expect near-real-time awareness (project management, team chat overflow). Only send if there are 3+ pending notifications.
Daily digest: The most common pattern. Send once per day at a consistent time. Best for activity summaries, social engagement roundups, content recommendations.
Weekly digest: For low-frequency products or summary/analytics content. Weekly engagement reports, content roundups, community highlights.
Event-based digests
Trigger a digest when conditions are met rather than on a fixed schedule:
Threshold-based: Send when 5+ notifications have accumulated, regardless of time.
Activity spike: When a piece of content gets sudden attention (10+ reactions in an hour), send one "your post is getting traction" email instead of 10 individual notifications.
Session-based: Batch notifications while the user is active in-app, then send a summary email after they leave.
Smart batching
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.
Digest design patterns
A good digest email has:
A clear summary header: "12 updates since yesterday" or "Weekly activity on your projects"
Grouped by context, not by time: Group notifications by project/thread/resource, not chronologically. Users care about "what happened on Project X" not "what happened at 3:14 PM."
Priority ordering: Most important or most active items first. A comment that needs your response ranks above 5 likes.
Truncated previews: Show enough to decide whether to click through - usually the first line of a comment or the event summary. Don't try to put the full content in the digest.
One clear CTA per group: "View conversation" or "See all activity" - not a CTA for every individual notification.
Unread count by category: "3 comments needing response, 7 reactions, 2 new followers"
What to never digest
Some notifications must always be sent immediately, never batched:
Security alerts (new login, password change, 2FA codes)
Payment failures and billing issues
Time-sensitive invitations with deadlines
Direct messages from another user (first message only - subsequent can be batched)
Anything the user explicitly asked for in real-time
Preference centers
A preference center lets users control their notification experience instead of choosing between "everything" and "unsubscribe from all."
Single page. Don't make users click through multiple screens. Every option should be visible at once.
Accessible from every email. Link to the preference center near the unsubscribe link in every notification. "Manage notification preferences" should be as prominent as "Unsubscribe."
Include a pause option. Let users snooze non-essential emails for a set period instead of unsubscribing permanently. This retains subscribers who are temporarily overwhelmed.
Show what each option means. Brief descriptions next to each toggle: "Get an email when someone replies to your comment" not just "Replies."
Pre-populate with current settings. Users should see their current preferences, not blank defaults.
Respect choices immediately. Changes should take effect within minutes, not "within 24-48 hours." Delayed preference changes erode trust.
Keep security and billing notifications non-optional. Mark them as "Always on" so users understand they can't be disabled - and so you stay compliant.
Mobile responsive. Over 50% of email opens happen on mobile. Your preference center must work well on a phone screen.
No login required for basic changes. Use a signed token in the preference center URL so users can adjust settings without logging in. Friction kills engagement with preference centers.
Comply with CAN-SPAM and GDPR. If you replace the unsubscribe link with a preference center link, you must still include an option to opt out of all non-transactional emails.
Default settings matter
Your defaults determine the experience for 80%+ of users who never visit the preference center.
Start conservative. Default to digest mode for high-frequency notification types. Users who want instant alerts will find the setting. Users who get overwhelmed won't.
Ramp with usage. A new user doesn't need notifications about features they haven't used yet. Enable notification categories as users activate the relevant features.
Different defaults by user type. Power users who log in daily may want instant notifications. Infrequent users are better served by weekly digests.
Notification email design
Consistent structure
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 line patterns
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.
Plain text fallback
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.
Keep it short
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.
Threading
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.
Metrics to track
Per-notification-type metrics
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
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.
System-level metrics
Notification-to-action ratio: What percentage of notifications result in the user taking the intended action? This is the true measure of notification value.
Time to action: How long between notification delivery and user action? Increasing latency signals declining relevance.
Digest engagement vs. instant: Compare click rates for digested vs. instant notifications. If digests perform equally well, you're sending too many instant notifications.
Preference center visit rate: If users are frequently visiting the preference center, they're trying to reduce volume. If they never visit, either your defaults are good or they don't know it exists.
Unsubscribe-to-preference-change ratio: Users who adjust preferences instead of unsubscribing are giving you a second chance. A high ratio of unsubscribes to preference changes means your preference center isn't visible or useful enough.
Common mistakes
Treating all notifications as equally important
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.
No notification strategy at launch
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.
Defaulting to instant for everything
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.
Making the preference center hard to find
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.
Sending notifications for your benefit, not the user's
"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.
Ignoring engagement signals
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.
Not separating transactional and notification infrastructure
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.
No deduplication
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.
Implementation checklist
Notification taxonomy: Document every notification type with urgency level, default channel, and default frequency
Channel routing: Route each type to the appropriate channel (email, push, in-app) based on urgency
Digest system: Implement time-based digests for activity and social notifications
Frequency caps: Set per-recipient, per-category limits with overflow to digest
Preference center: Build with per-type granularity, pause option, and no-login-required access
Fatigue monitoring: Track per-recipient engagement and auto-reduce frequency for disengaged users
Deduplication: Dedupe on event identity, not request identity
Threading: Use consistent message headers to group related notifications
Separate infrastructure: Use dedicated sending domain/subdomain for notifications
Plain text fallback: Include plain text version of every notification
Per-type metrics: Track open, click, unsubscribe, and complaint rates per notification category
Compliance: Unsubscribe option in every email, preference center meets CAN-SPAM/GDPR requirements
References
RFC 8058 - One-Click Unsubscribe (required for marketing/promotional notifications)
