What this prompt does
This prompt designs a complete in-app notification center and activity feed for your SaaS product. You provide [product_name], [product_type], [user_roles], [team_size], [notification_volume], and your [framework], and it lays out the bell and badge, the notification panel, a team activity feed, a preferences matrix, the delivery-system architecture, and [framework] implementation notes.
The structure works because notification systems look simple but get hard fast once you factor in batching, multiple channels, and quiet hours. The prompt forces the full design before any code: it groups notifications by time, defines distinct visual treatments for your [notification_types], builds a preferences matrix of types-by-channels, and specifies delivery logic like channel fallback and rate limiting to prevent fatigue. Tying it to your [notification_volume] and [team_size] keeps the design realistic for how busy the feed will actually be.
When to use it
- You're adding notifications to a SaaS dashboard and want the full UX and delivery design before coding.
- Your current notifications overwhelm users and you need batching, grouping, and quiet-hours logic.
- You need a preferences matrix so users can control each
[notification_types]per channel. - You're building a team activity feed with real-time updates and filtering.
- You want delivery architecture (channel fallback, rate limiting, unsubscribe handling) thought through.
- You need
[framework]implementation guidance for virtualized lists and WebSocket reconnection.
Example output
You get a layered design: a notification bell with unread-count badge and urgent states; a grouped dropdown panel (Today, Yesterday, This Week) with per-type icons, mark-as-read, archive, and an empty state; a filterable team activity feed with real-time WebSocket updates and collapsible batch actions; a preferences matrix of [notification_types] against in-app/email/push/Slack channels with quiet hours and digest options; a delivery section covering fallback, batching, and rate limiting; and [framework] notes on virtualized rendering and optimistic mark-as-read.
Pro tips
- List your real
[notification_types]— they drive both the visual treatments and the preferences matrix rows. - Set
[notification_volume]honestly; high volume makes batching, digests, and quiet hours essential, not optional. - Match
[framework]to your stack so the WebSocket and virtualization advice is directly applicable. - Use
[user_roles]to shape what each role sees in the activity feed and which notifications they receive. - Design the preferences matrix early; retrofitting per-channel controls after launch is painful.
- Ask a follow-up to deepen the delivery-architecture section into a real schema once the UX is settled.
