Aller au contenu
Sumio

04 / 06 · Use case

D'une communication fragmentée à un système de messages cohérent

Entreprise
Glady
Rôle
Product Designer
Équipe
Designers, Product Marketing Manager
Outils
Figma, Notion, Asana
Période
2021

4

composants de message pour tous les cas d'usage

3

équipes alignées sur le même référentiel

En bref

Chez Glady, les messages de l’application s’étaient multipliés sans cadre : styles différents, aucune règle d’usage, et un bruit visuel qui dégradait l’expérience comme la voix de marque. J’ai initié ce projet pour le traiter comme un sujet de système, pas de retouche : un référentiel commun, quatre composants intégrés au design system, et un process pour que chaque nouveau message passe par les mêmes règles.

L’enjeu

Sans guidelines, chaque équipe produisait ses propres messages. Un même écran pouvait en cumuler plusieurs, de types différents, sans hiérarchie. Les utilisateurs recevaient trop d’informations, certaines impossibles à fermer, d’autres hors de propos pour leur situation.

La question que j’ai posée : comment unifier les messages et donner des règles claires aux équipes, tout en offrant une expérience plus lisible aux utilisateurs ?

Croiser besoins utilisateurs et priorités business

En reprenant les retours terrain, j’ai isolé des frustrations précises : messages intrusifs non pertinents, messages impossibles à fermer une fois lus, accumulation qui surcharge l’interface, textes trop longs pour être assimilés rapidement.

Pain points et besoins côté utilisateurs

J’ai mis ces frustrations en regard des objectifs business : cohérence, réduction du bruit informationnel, impact sur l’expérience, engagement et conversion, et réduction de la dette produit. Ce croisement m’a permis de défendre le projet autrement que par l’esthétique : chaque message mal cadré était aussi une opportunité business perdue et un coût de maintenance.

Pain points et besoins côté business

Poser des principes, puis le système

J’ai posé trois principes, devenus la grille de décision de toutes les équipes :

  • Bon moment, bonne info, bon utilisateur : un message intervient au bon moment, apporte une information pertinente et cible les bonnes personnes.
  • Une expérience sans rupture : un message n’interrompt pas l’action en cours, sauf si une action critique est requise.
  • Un format adapté au contenu : forme, mise en page et emplacement correspondent à ce que le message doit dire.

J’ai découpé le chantier en quatre temps :

  1. Audit de l’existant : mise à plat de tous les messages de l’application, des redondances et des types existants. J’ai livré des corrections rapides en parallèle, sans attendre la fin du projet.
  2. Référentiel des messages : une ressource centralisée pour visualiser les composants disponibles et leurs guidelines.
  3. Intégration au design system : chaque composant documenté (intention, règles d’usage, comportements attendus, exemples) pour que les équipes l’utilisent en autonomie.
  4. Tests de la démarche auprès des équipes, avec un accompagnement sur le process design.

Quatre composants, des règles explicites

J’ai défini chaque composant par trois critères : son job to be done, sa durée de vie dans l’interface et ses règles d’interaction. Quatre composants couvrent l’ensemble des cas d’usage : Banners, Marketing cards, Snackbars et Modals.

Les quatre composants de message

Exemple pour le Banner : « Je souhaite être informé d’une information essentielle afin de pouvoir compléter une action. » Placé en haut d’écran, trois lignes maximum, il peut être fermé par l’utilisateur sauf si une action est requise ou s’il s’agit d’un statut global. Son indicateur : le taux de clic quand une action est attendue.

Avant et après : un écran qui cumulait les messages, puis un message par rôle

Faire vivre le système

Un référentiel n’a d’effet que si les équipes se l’approprient. Je l’ai présenté à tous, avec un canal Slack dédié pour poser des questions et signaler des incohérences. J’ai inscrit l’onboarding sur les composants et la vérification des guidelines dans le process design existant.

Annonce du référentiel aux équipes

Pour que la cohérence tienne dans la durée, j’ai conçu un template de demande : toute création ou évolution de message passe par lui, avec son contexte, son type, sa cible, son intention et son KPI.

Template de demande de message

Résultats

  • 4 types de messages couvrant l’ensemble des cas d’usage produit.
  • Un référentiel adopté par les équipes design, produit et marketing.
  • Moins d’erreurs de formulation et d’incohérences de ton détectées en production.
  • Un socle réutilisable dans le design system, aligné sur la voix de marque.

Ce que j’en retiens

Un référentiel n’est pas un travail de documentation : c’est un levier pour aligner les équipes, clarifier les intentions et rendre les messages utiles. C’est en croisant les retours utilisateurs, le support et le produit que le projet est devenu légitime au-delà du design.

Les suites que j’avais cadrées : étendre le référentiel à d’autres typologies (notifications, onboarding) et mesurer plus finement l’impact sur l’expérience via des tests A/B ou des analytics ciblés.