ux-notifications
Skill21 starsChanged 5 months agoMITView on GitHub
Notification UX: push permission timing, per-type granularity, quiet hours, badge accuracy, deep-link targets, notification content quality, grouping and channels, and in-app notification centers. Use when designing or reviewing push notifications, notification settings, or any messaging that interrupts the user.
In this repository17 other files it gives its agents.
- ux-accessibilitySkill
- ux-ai-automationSkill
- ux-contentSkill
- ux-error-handlingSkill
- ux-formsSkill
- ux-generalSkill
- ux-help-onboardingSkill
- ux-information-architectureSkill
- ux-navigationSkill
- ux-networkSkill
- ux-reviewSkill
- ux-safety-privacySkill
- ux-searchSkill
- ux-settingsSkill
- ux-user-accountSkill
- ux-utilitySkill
- ux-visual-designSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 50
iOS provisional authorization: Consider provisional authorization to deliver notifications quietly to the Notification Center without any …
- Distinctive: line 54
Graceful denial: If the user declines, keep the app fully functional and offer an in-app notification center instead.
- Distinctive: line 63
Write like a person, not a system: "Your ride is 2 minutes away."
- Distinctive: line 64
Never use clickbait or fake urgency.
- Distinctive: line 73
When applying this checklist to a screen, flow, or codebase:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Notifications UX
A notification interrupts someone's life. Every one you send spends trust, and the balance is easy to overdraw: the OS-level "turn off all notifications" switch is one long-press away, and once flipped it almost never comes back.
Checklist
| Item | Guidance |
| Permission timing | Ask after the user has experienced value, tied to a feature that needs it — never on first launch. |
| Pre-permission prompt | An in-app screen explains what notifications the user will get before the system dialog appears. |
| Per-type granularity | One toggle per notification type (orders, messages, promotions). Never a single on/off switch. |
| Transactional vs promotional | Marketing notifications are opt-in and separate from transactional ones. Disabling promotions never disables receipts or security alerts. |
| Quiet hours | User can set a do-not-disturb schedule, or the app respects the OS Focus / DND modes. |
| Badge accuracy | App icon badge count matches actual unread items and clears when they are viewed. |
| Deep-link target | Tapping a notification lands on the exact relevant content, never the home screen. |
| Notification content | Specific and actionable: "Sara replied to your comment", not "You have a new notification." |
| Grouping | Multiple notifications from the same source collapse into a group or summary. |
| Android channels | Every notification type has its own channel so users can control them at the OS level. |
| In-app notification center | A history of past notifications is available in the app for anything the user missed or dismissed. |
| Frequency capping | Promotional notifications are rate-limited. Sending caps are enforced per user, per day. |
Permission Strategy
Contextual ask: Request permission at the moment the value is obvious — after the user places an order ("Get delivery updates?"), follows a topic, or sends a first message. Acceptance rates for contextual asks are several times higher than launch-time asks.
Pre-permission screen: Show your own explainer first. If the user declines your screen, you keep the ability to ask again later; if they decline the system dialog, you may never get another chance (iOS allows the system prompt only once).
iOS provisional authorization: Consider provisional authorization to
deliver notifications quietly to the Notification Center without any prompt —
the user upgrades or disables them after seeing real examples.
Graceful denial: If the user declines, keep the app fully functional and offer an in-app notification center instead. Provide a path to enable later ("Turn on in Settings > Notifications").
Content Guidelines
- Front-load the payload: the first ~40 characters must carry the message.
- Write like a person, not a system: "Your ride is 2 minutes away."
- Never use clickbait or fake urgency; it earns one tap and loses the channel.
- Include the actor and the object: who did what to what.
- Support rich content (images, actions) where it saves the user an app launch — "Reply", "Mark as done", "Track order" as inline actions.
How to Review
When applying this checklist to a screen, flow, or codebase:
- Go through every checklist item and mark it Pass, Fail, or N/A — never skip items silently.
- Cite specific evidence for each finding: the screen, component, file, or line it applies to.
- Tag each failure with a severity: Blocker (breaks the experience), Major (hurts usability), or Minor (polish).
- End the review with the top 3 recommended fixes, ranked by user impact.
Related Skills
ux-settings— where notification controls live and how they are groupedux-safety-privacy— permission prompt best practicesux-navigation— deep links that notifications land onux-content— notification copy quality
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.