Votre CTO vient donc de vous confier un projet de refonte ou de construction du système de notification de votre produit. Cela semblait être un projet simple et direct, mais vous avez commencé à faire des recherches et vous vous êtes rendu compte que non seulement le processus est assez compliqué, mais qu’il n’y a pas beaucoup d’informations en ligne sur la façon de le faire. Après tout, des entreprises comme LinkedIn, Uber et Slack ont de grandes équipes de plus de 25 employés travaillant uniquement sur les notifications. Mais les petites entreprises n’ont pas ce luxe – alors comment pouvez-vous atteindre le même niveau de qualité avec une seule équipe ?
Cela peut certainement être écrasant, c’est pourquoi nous avons créé une série d’articles de blog pour vous guider dans la création du meilleur système de notification pour votre entreprise. Ceci est le premier article de cette série, et nous vous présentons les exigences essentielles des utilisateurs pour les développeurs et les utilisateurs non techniques de votre système de notification.
Il est essentiel qu’avant de créer un système de notification, vous connaissiez les exigences de vos collègues développeurs et coéquipiers non techniques qui créeront les notifications pour vos utilisateurs finaux. Comprendre les personnalités de ces coéquipiers vous aidera à créer un produit plus efficace avec une meilleure expérience utilisateur.
Qu’est-ce qu’un système de notification ?
Un système de notification est un ensemble de services (modèles, intégrations de fournisseurs, logique de routage, préférences, journalisation, etc.) qui permettent de créer rapidement et facilement une communication claire et directe entre une application et ses utilisateurs. Cette clarté de communication implique généralement une myriade de canaux, notamment les e-mails, SMS, notifications push, etc. qui permettent à l’application d’atteindre chaque utilisateur avec la meilleure expérience utilisateur possible.
Un système de notification bien conçu supprime la complexité du processus de création de chaque notification, ce qui permet une expérience cohérente entre les produits et les équipes. Cela fournit également un hub centralisé pour les notifications à travers l’organisation, rendant ainsi la surveillance et l’analyse plus accessibles.
Selon le produit de votre entreprise, un système de notification peut fonctionner avec différents cas d’utilisation. Vous pouvez utiliser un système de notification central pour alerter vos utilisateurs finaux d’une demande entrante, envoyer des messages sur les actions entreprises, informer les utilisateurs finaux des mises à jour et des mises à niveau ou des promotions de produits, ou même déployer des notifications de gestion de compte.
Exigences du développeur pour un système de notification
Un développeur doit comprendre le cadre du système de notification afin de pouvoir l’intégrer dans d’autres parties de l’application ou du logiciel. Ce sont eux qui finissent par câbler les notifications pour la myriade de cas d’utilisation applicables, il est donc important de construire le système en pensant à eux.
Évolutivité et fiabilité
La fiabilité permet d’éviter les messages perdus. Même si de nombreux messages arrivent simultanément ou si le système est en pleine charge, la livraison des messages doit être garantie. Bien qu’il puisse y avoir des retards lors de la charge maximale, vous devez être sûr de ne pas perdre de messages. Le système doit également réessayer les livraisons de messages ayant échoué en envoyant des messages de manière fiable sur le réseau et réessayer si un message échoue.
Une organisation devra envoyer différents volumes de notifications à différents moments, de sorte que le développeur utilisant l’API n’aura pas à se soucier de la mise à l’échelle automatique de l’infrastructure. Par exemple, une organisation doit envoyer de nombreuses notifications lorsqu’elle effectue des ventes flash. À d’autres moments, pendant les périodes de faible volume, il devra envoyer moins de notifications. Le système doit pouvoir évoluer vers le haut et vers le bas de manière efficace au fur et à mesure que le volume de notifications change et qu’une organisation se développe.
Canaux abstraits
En l’absence d’un système de notification central, l’incohérence entre les canaux tels que les SMS, les e-mails ou les notifications push est susceptible de devenir un problème, que ce soit entre les autres développeurs, la réussite des clients, le marketing, etc.
Vous pouvez modifier le fournisseur de canal de notification, qu’il s’agisse d’AWS SES ou de Twilio pour les e-mails, dans le service de notification sans modifier le code d’application dans les autres produits. Ainsi, les canaux de notification et les fournisseurs seront abstraits et centralisés au lieu d’avoir le code saupoudré sur toute la base de code de l’application. Ainsi, si votre entreprise cesse de faire affaire avec un fournisseur en particulier, elle peut passer à un nouveau fournisseur en quelques heures sans affecter aucune autre partie du service de notification.
L’interface uniforme simplifie le développement de chaque produit et équipe en faisant abstraction des différents fournisseurs de notification (email, push, SMS, etc.) afin que le développeur puisse facilement basculer entre différents fournisseurs sans réécrire le code.
Bonne documentation
Pour que d’autres développeurs utilisent votre système de notification, vous devez fournir une bonne documentation pour comprendre comment l’utiliser. La documentation interne fait partie intégrante de tout système, car elle éduque et aide les utilisateurs à référencer et à savoir comment utiliser votre produit. Lors de la création d’une plate-forme pour d’autres développeurs, vous devez fournir une excellente documentation afin qu’ils disposent des outils nécessaires pour résoudre les problèmes liés au support.
Une bonne documentation pour un système de notification devrait être un guide facile pour les aider à démarrer. Il devrait également fournir une référence complète pour toutes les opérations dans le système de notification. Un développeur intégrant le système de notification ne devrait pas avoir à deviner les opérations et les paramètres pris en charge pour le système.
La documentation doit également être facilement repérable. Sans savoir exactement où aller dans le système, le développeur doit rechercher ce qu’il veut et le trouver facilement. La documentation doit être précise, cohérente, disponible sur demande et à jour. Il doit inclure des exemples, des exemples de code, des captures d’écran et des didacticiels pour plus de contexte sur le système.
API intuitives
Les utilisateurs techniques doivent envoyer des notifications par programmation. Ainsi, un système de notification doit avoir des API pour soumettre des notifications à livrer. Ces API doivent être intuitives à partir de différentes plates-formes afin que le système ne limite pas la mise en œuvre d’autres systèmes. Les utilisateurs doivent appeler les API à partir de n’importe quel langage ou plate-forme de programmation, et la documentation de l’API doit également être disponible sur demande.
Analytique
Les notifications communiquent avec un public cible. Les opérateurs système souhaitent donc mesurer les performances du système de notification (et l’impact des notifications elles-mêmes) et collecter des informations qui peuvent aider l’organisation à mieux concevoir ses notifications.
-
Intégrations pour exporter des données vers un entrepôt de données
Les données collectées par le service de notification sont précieuses mais brutes. Ainsi, l’analyse des données permet d’obtenir des informations supplémentaires pour votre organisation. De telles analyses sont souvent effectuées dans d’autres systèmes où les événements d’engagement sont en corrélation avec d’autres données pour mieux représenter le comportement des utilisateurs.
Un système de notification devrait prendre en charge les exportations de données sous des formes lisibles à la fois par l’homme et par la machine. Il peut également s’intégrer aux outils d’entreposage de données et les exporter directement.
L’engagement avec une notification est une mesure essentielle pour les entreprises, le système de notification doit donc suivre cet engagement. Les engagements de suivi sont généralement effectués en suivant les clics sur les liens et la notification push s’ouvre.
Pour les liens, le système de notification réécrit les liens dans les notifications pour passer par lui-même. Chaque visite sur les liens enregistre un événement dans le système, puis redirige vers le lien d’origine. Cela permet au système de suivre les clics. Les SDK sur les clients remarquent lorsqu’un utilisateur ouvre une notification et l’enregistrent pour les notifications push.
Les informations sur le comportement d’exécution du système sont importantes pour que le système continue de fonctionner. Les métriques de latence et de débit aident à comprendre les retards dans les sous-systèmes et le taux de notifications envoyées. La longueur de la file d’attente, ainsi que le temps de service et le temps d’attente (tous deux des mesures de latence), peuvent estimer les retards et optimiser davantage le système. Ces métriques aident à la planification de la capacité.
-
Prise en charge de la journalisation intégrée
Lorsque les choses tournent mal, le système doit permettre aux utilisateurs de mieux comprendre ces problèmes. Les journaux techniques fournissent de telles informations. Par exemple, les journaux montrent que bien que les notifications aient été soumises avec succès au système, elles n’ont pas été remises au fournisseur en aval. Les utilisateurs savent maintenant que ce n’est pas nous ; c’est eux.
Les utilisateurs techniques doivent consulter des journaux techniques détaillés pour les erreurs qui se produisent lorsqu’une notification n’est pas envoyée. Autre exemple : le développeur devrait voir qu’un message envoyé via SendGrid a été renfloué à cause d’une erreur HTTP 401 indiquant que la clé API est mauvaise. Les journaux techniques montrent également d’autres détails essentiels sur les opérations du système. Les journaux peuvent aider les opérateurs à diagnostiquer les problèmes lorsqu’ils surviennent.
Prise en charge des environnements de test
Un environnement de test permet au développeur de simuler l’envoi de notifications en toute sécurité. Il est utile dans les environnements d’intégration continue ou de transfert où vous devez exécuter un code de test sans envoyer de notifications aux clients ou utilisateurs finaux réels.
La prise en charge d’un environnement de test permet un développement rapide des applications et donne également confiance aux programmeurs. Les programmeurs peuvent écrire des tests suffisamment proches du fonctionnement du système de notification plutôt que de se moquer du système dans leurs tests.
Un environnement de test permet également aux développeurs d’expérimenter et d’essayer différents paramètres et opérations pour voir leurs résultats sans impacter les clients. Sans cela, chaque interaction avec le système de notification est potentiellement dangereuse, car elle peut envoyer une notification à un client. Un système qui ne prend pas en charge un environnement de test retarde le rythme de développement car les développeurs doivent attendre la production pour essayer les choses.
Marque blanche
Si votre entreprise couvre plusieurs produits ou marques, le système de notification doit pouvoir déployer des notifications aux clients d’autres marques et modifier la marque et les logos à la volée. La marque blanche facilite grandement le passage à de nouvelles marques pour l’envoi de notifications. L’entreprise nouvellement acquise peut conserver son image de marque tout en passant au système de notification de l’entreprise existante. Par exemple, Twilio, Segment et SendGrid (tous détenus par la même société) souhaitent envoyer des notifications aux trois logiciels et modifier la marque et les couleurs sur place, en fonction du produit recevant la notification.
Exigences utilisateur non techniques pour un système de notification
Les utilisateurs non techniques sont ceux qui n’ont besoin que d’une interface utilisateur fluide et d’une expérience utilisateur pour utiliser le système de notification. Les concepteurs, les éditeurs de contenu, la réussite et l’assistance des clients et votre équipe marketing ne s’interfacent pas avec le code, vous devez donc également créer pour répondre à leurs besoins. Examinons quelques-unes des exigences pour un utilisateur non technique.
Convivialité
La convivialité est une exigence non négociable car vos utilisateurs en ont besoin pour créer et envoyer des notifications de manière transparente. Assurez-vous que l’interface est conviviale afin qu’ils puissent explorer le système rapidement. Il ne devrait pas non plus nécessiter beaucoup d’intégration et de formation pour comprendre le système.
Les utilisateurs doivent être en mesure d’effectuer efficacement les tâches prévues (dans la séquence d’étapes la plus courte possible). Pour obtenir une convivialité décente, choisissez des interfaces utilisateur basées sur les tâches plutôt que des interfaces génériques. Les interfaces basées sur les tâches sont des interfaces conçues avec une action utilisateur particulière à l’esprit. Par exemple, la journalisation : un représentant du support client doit trouver pourquoi un utilisateur ne reçoit pas de notification et doit pouvoir rechercher des notifications à cet utilisateur par e-mail dans les journaux. L’interface doit :
- Différencier clairement les différents types de journaux et afficher les informations pertinentes pour chacun grâce à un identifiant spécifique (dans ce…