How to get push notifications right
This is one of those topics that looks small until it costs you something. The short answer to push notifications is that it is mostly a sequence of small decisions, not one big one.
Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. The version that survives contact with a real deadline is the simple one.
Why this earns attention
Permission is granted once and revoked forever. It is worth being explicit about, because assumptions differ quietly. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
The steps
- Establish what you have today before changing anything
- Notify about things people asked for, not things you want to say
- Deep link into the exact screen the notification is about
- Write down the decision so the next person does not re-litigate it
Deep link into the exact screen the notification is about. That sounds obvious written down. It is still the thing most often skipped. Budget a little time for it every quarter and it never becomes a project of its own.
Turning this into a decision
How to tell if yours is fine
You do not control the device, the network, or the operating system version, and the design has to accept that. Three things worth confirming about push notifications before you move on:
- Someone can say what the current setup is without going to look
- Permission is granted once and revoked forever — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Pick the one that would hurt most if it failed, and start there.