Notifications playbooks
Make updates timely, understandable, and actionable without overwhelming people. Choose a scenario, then the decision you need to make.
Notification preference overload
A settings page with too many switches can make people disable everything. Group choices around meaningful events and explain the consequence of each channel.
- Triage notification preference overload before adding controls
- Prioritize notification preference overload with useful choice
- Investigate notification preference overload with an event map
- Verify notification preferences across event categories
- Learn from notification preference overload and blanket muting
Notification preference defaults
First-run defaults shape trust before someone understands every event. Review which updates are enabled, why, and how a person can change the choice later.
Notification preference channel language
“Push,” “alerts,” “activity,” and “email” may describe implementation or user outcomes. Align labels, descriptions, and event examples so each setting can be chosen confidently.
Notification quiet-hours expectations
Quiet hours can delay an alert while leaving the underlying event available. Make time zone, urgency, and in-app availability legible so delayed delivery is not mistaken for loss.
Notification urgency calibration
Urgency labels should describe the consequence of waiting, not the team’s desire for attention. Compare event impact, interruption behavior, and the user’s ability to recover.
- Triage notification urgency before escalating interruption
- Prioritize notification urgency with a safe interruption boundary
- Investigate notification urgency with consequence evidence
- Verify notification urgency across routine and time-sensitive events
- Learn from notification urgency and alert-fatigue decisions
Notification grouping by resource
Related updates should gather around the resource people recognize, while distinct resources remain separable. Define grouping keys that preserve context and useful actions.
Notification grouping duplicate updates
Retries, repeated saves, and state changes can produce several messages for one meaningful update. Decide when to update, group, or preserve a notification as a separate event.
- Triage duplicate notification updates before coalescing
- Prioritize duplicate notification updates without hiding change
- Investigate duplicate notification updates with event identity
- Verify notification coalescing across retries and real updates
- Learn from duplicate notification updates and coalescing errors
Notification grouping across projects
People working across projects need context that survives grouping. Test whether shared actors, event types, or dates are enough to combine items without misattribution.
Notification action context
An action label is useful only when the destination and outcome are clear from the notification. Connect event, actor, resource, and next action without relying on a generic “open” button.
Notification action stale deep link
A notification can outlive the page, project, or state it links to. Define a useful fallback that explains what changed and keeps the person oriented.
Notification action scope
The same event may expose different actions to owners, reviewers, and read-only members. Align visible actions with the current role and target state.
Notification badge count drift
A badge can disagree with an inbox after reading, grouping, opening several tabs, or switching devices. Define exactly what the count represents and when it changes.
Notification badge meaning
A number beside a bell is read as unread work unless the interface explains otherwise. Keep badge semantics narrow and communicate important information through the list itself.
- Triage notification badge meaning before changing the shell
- Prioritize notification badge meaning with a clear promise
- Investigate notification badge meaning from count to destination
- Verify notification badge meaning across zero and unread states
- Learn from notification badge meaning and metric confusion
Notification inbox empty history
An empty notification view can mean first use, all caught up, a filter with no matches, or unavailable history. Give each state an honest explanation and next step.
- Triage an empty notification inbox before changing its copy
- Prioritize notification inbox empty states with honest recovery
- Investigate notification inbox empty states with history traces
- Verify notification inbox empty states and recovery paths
- Learn from notification inbox empty states and missing context
Notification read-state confusion
Opening, focusing, dismissing, and explicitly marking a notification can mean different things. Define the read transition so the list and badge communicate the same state.
- Triage notification read-state confusion before changing list behavior
- Prioritize notification read-state clarity with reversible cues
- Investigate notification read-state transitions across surfaces
- Verify notification read state across open and mark actions
- Learn from notification read-state confusion and missed work
Notification permission timing
Requesting permission before a person understands the benefit creates a brittle first impression. Tie the request to a clear event and provide a useful path when permission is declined.
- Triage notification permission timing before showing a prompt
- Prioritize notification permission timing with user intent
- Investigate notification permission timing through user journeys
- Verify notification permission timing and denial recovery
- Learn from notification permission timing and prompt fatigue
Notification channel fallback
When one delivery channel is muted or unavailable, a fallback can preserve visibility or create duplicate noise. Define the event’s durable in-app state and alternate delivery behavior.
- Triage notification channel fallback before adding another delivery path
- Prioritize notification channel fallback with less duplicate noise
- Investigate notification channel fallback across delivery states
- Verify notification channel fallback without duplicate alerts
- Learn from notification fallback and duplicate delivery choices
Notification delivery retry visibility
A queued or retried notification may be invisible to the person waiting for it. Explain durable event state, delivery uncertainty, and the next available action without exposing internal jargon.
- Triage notification delivery retry visibility before changing status copy
- Prioritize notification retry visibility with truthful status
- Investigate notification retry visibility from event to channel
- Verify notification retry status and recovery copy
- Learn from notification retry visibility and repeated actions
Notification deduplication window
The same event can cross workers, channels, or retries. A useful deduplication rule needs a stable identity and a time boundary that does not merge legitimate repeated events.
- Triage notification deduplication windows before suppressing repeats
- Prioritize notification deduplication with preserved change
- Investigate notification deduplication windows with event traces
- Verify notification deduplication across retries and state changes
- Learn from notification deduplication windows and hidden updates
Notification copy truncation
Long titles and action labels can hide the event, actor, or next step on narrow screens and previews. Shorten copy without removing the context needed to choose safely.
- Triage notification copy truncation before shortening messages
- Prioritize notification copy truncation with preserved context
- Investigate notification copy truncation across layouts and previews
- Verify notification copy across narrow screens and previews
- Learn from notification copy truncation and missing context