Push notifications: what to get right first

Every audit we run turns up some version of this. If you only fix one thing about push notifications this quarter, make it the first item below.

You do not control the device, the network, or the operating system version, and the design has to accept that. Budget a little time for it every quarter and it never becomes a project of its own.

Start here

Permission is granted once and revoked forever. There is a version of this that is over-engineered, and it is worth avoiding. The version that survives contact with a real deadline is the simple one.

Then this

Notify about things people asked for, not things you want to say. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Eventually

Deep link into the exact screen the notification is about. The reasoning matters more than the rule, because the rule has exceptions. Check it against what you would want a competitor's site to get wrong.

In practice

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.