Partez d’une tâche du client
Android recommande de demander l’accès lorsque la fonctionnalité concernée en a besoin ; Apple, de contextualiser les demandes de notifications. Appliquons ces principes à une boulangerie fictive de Budapest préparant une application de retrait. Ses clients doivent choisir une boutique, commander du pain et connaître les possibilités de retrait.
La boulangerie pourrait proposer un raccourci vers les boutiques proches, à côté d’une liste manuelle. Après acceptation d’une commande, elle pourrait proposer une alerte de fin de préparation. Ces avantages sont distincts. Expliquez chacun séparément, avec le vocabulaire du parcours d’achat.
Prévoyez un parcours utilisable après un refus
Ici, refuser la localisation devrait laisser accessibles la liste des boutiques, leurs adresses et horaires. Refuser les notifications devrait préserver un écran de commande précisant le retrait. Aucun refus ne devrait effacer le panier ni imposer une nouvelle inscription.
Demandez aux développeurs de présenter les deux parcours en revue. Une explication soignée ne suffit pas si l’écran suivant reste vide. Montrez-les aussi à l’assistance : elle doit pouvoir expliquer où retrouver une commande sans supposer qu’une alerte s’est affichée.
Dimensionnez raisonnablement la première version
Le choix manuel peut suffire à une boulangerie ayant deux boutiques. Les suggestions automatiques facilitent l’usage, mais ajoutent du développement et des cas à maintenir. Vérifiez que ce raccourci résout un problème fréquent avant d’acheter des intégrations cartographiques ou de l’inscrire au calendrier de lancement.
Dans cet exemple, trouver une boutique ne justifie pas de conserver l’historique des déplacements du client. Précisez si la localisation est traitée sur l’appareil ou transmise à un serveur, quelles données sont conservées et pourquoi. L’alerte de commande prête ne devrait pas non plus devenir discrètement un abonnement promotionnel. Distinguez ces préférences dans le cahier des charges.
Alignez la promesse sur le fonctionnement réel
La boulangerie doit décider qui marque une commande comme prête et quoi faire en cas d’oubli. Les notifications ne résolvent pas une organisation imprécise en cuisine. Convenez du statut auquel les clients peuvent se fier et gardez les consignes de retrait accessibles dans l’application.
Ne promettez pas que chaque alerte sera vue. Apple documente les réglages modifiables des notifications ; Android, la gestion des autorisations révoquées. Demandez à l’équipe d’expliquer le comportement réel sur chaque plateforme prise en charge. Une présentation commune ne doit pas masquer les différences entre dialogues système ou réglages disponibles.
Validez avec une courte liste de contrôle
Avant publication, vérifiez le parcours sur les téléphones et dans les langues prévus. Attribuez chaque anomalie à un responsable et gardez un bref enregistrement du parcours corrigé pour la version suivante.
- Partez d’une nouvelle installation et testez l’acceptation comme le refus.
- Modifiez les autorisations dans les réglages, puis revérifiez les écrans boutiques et commande.
- Vérifiez que le choix manuel et les détails de commande restent faciles à trouver.
- Vérifiez que les traductions décrivent le même avantage et la même solution de repli.
- Simulez une commande prête et contrôlez les vues du client et du personnel.