pattern · auth · onboarding
Permission priming
also called pre-permission prompt (community), soft ask (community), double permission pattern (web-dev), primer dialog (community), permission pre-prompt (community)
Explaining why access is needed in the product's own dialog first, and only firing the operating system prompt once the reader has said yes to that.
Permission priming is an ask before the ask. The product puts up its own card, in its own voice, saying what it wants access to and what the reader gets for it, and offers two answers. Only one of them reaches the operating system. Say yes and the real prompt appears, already answered in the reader’s head. Say not now and nothing happens at all, which is the whole point: the system prompt has not been spent, and the app can ask again after the next order, the next photo, the next trip.
The reason it exists is that the platform prompt is close to a single use resource. On iOS the notification prompt is shown once, and a person who declines has to find a buried settings screen to change their mind. Android and browser prompts are similar enough in practice, and browsers now punish repeat asking directly: Chrome and Firefox suppress prompts a person keeps dismissing, and Safari requires a gesture before one can be shown at all. A cold prompt on first launch, before the app has done anything worth being told about, is therefore not a fast route to permission. It is how a product loses the channel permanently, and the decline rate on cold notification asks is the reason priming became standard practice.
Timing is most of the craft. Ask where the value is obvious, immediately after the gesture that creates it: the order is placed, so offer to say when the driver leaves; the photo has been taken, so offer the camera roll. Name the specific thing you will send and how often, because a vague promise reads as marketing and gets refused. And keep the ask proportionate. One primer per moment, dismissible with a plain Not now, is priming. The same card returning on every screen until it wins is nagging, and a reader who cannot make it go away will remove the app instead.
The pattern is honest as long as the primer is honestly a primer. It has to be visibly the product’s own interface rather than a copy of the system dialog, because a card dressed as an operating system alert is borrowing an authority it does not have, which is misdirection and reads as one the moment anyone notices. The decline has to be a real answer, not a delay disguised as one. And the promise made in the card is the contract for what the channel is used for afterwards, so a push notification permission granted for delivery updates does not also license weekend discount campaigns. The same shape applies to every sensitive permission, location, camera, microphone, contacts, and the rule is the same everywhere: earn it in your own words first, then let the system ask once.
Which word?
| If you want | say |
|---|---|
| your own dialog asks before the real system prompt does | permission priming |
| the consent notice that greets you before you read anything | cookie consent banner |
| the same prompt keeps returning until you give in | nagging |
Related
See also: Push notification