Projet · B2B outil interne
Retailer config
L'écran où se règle chaque retailer du réseau. Avant lui, changer un seul champ passait par un ticket et par un développeur. Le sujet : rendre lisible et modifiable une centaine de réglages éparpillés en base, pour trois équipes qui n'ont pas le même métier.
- tickets par semaine, avant, pour changer un champ en base
- ~10
- de développeur par semaine, perdu en petites modifications cumulées
- ~1 jour
- retailers à configurer à l'époque
- 500 à 1 000
- Rôle
- Product Designer
- Année
- 2023 · environ un an
- Équipe
- Seul au design, sans PM · Développeurs
- Plateforme
- Web · Desktop
En 30 secondes
- Situation
- Pour modifier un réglage d'un retailer, un Partner Success ouvrait un ticket et un développeur s'interrompait pour changer la valeur en base. Mis bout à bout, cela coûtait environ une journée de développeur par semaine.
- Mission
- Donner une interface à des données qui n'en avaient pas, pour que ceux qui connaissent le retailer puissent agir eux-mêmes.
- Action
- Une interview par métier, un rangement calé sur le rôle du retailer et sur l'équipe qui lit, puis une règle d'affichage par type de donnée plutôt qu'un dessin par champ.
- Résultat
- Les tickets de modification ont disparu, les développeurs configurent eux-mêmes les retailers dans l'outil, et un champ ajouté en base s'y affiche tout seul.
01 · Comprendre
Un ticket et un développeur pour changer un champ
Chaque retailer du réseau a sa configuration : des dizaines de réglages qui décident de la façon dont il est intégré, facturé et servi. Ces réglages n'existaient qu'en base de données. Pour en changer un seul, un Partner Success ouvrait un ticket, puis un développeur arrêtait ce qu'il faisait pour aller modifier la valeur.
Il en tombait de l'ordre d'une dizaine par semaine, uniquement pour des changements de champs. Une petite modification par-ci, une autre par-là : cumulées, elles prenaient environ une journée de développeur par semaine, pour 500 à 1 000 retailers à l'époque. Le coût ne se limitait pas au temps des développeurs. Certaines configurations devaient être corrigées tout de suite, et l'attente créait des problèmes avec les retailers, au point de bloquer un partenariat ou de faire échouer un deal. Le Partner Success, lui, savait exactement quoi changer. Il lui manquait seulement l'endroit pour le faire.
J'étais seul au design, sans PM. Je suis parti de la problématique seule, sans solution imposée. Avant de dessiner quoi que ce soit, j'ai mené une interview avec chaque métier pour comprendre ce que chacun venait chercher dans une configuration, et ce qui le bloquait.
Ce qui rendait le sujet difficile
- Trois publics aux métiers et aux niveaux techniques très différents, sur un seul écran
- Des données réparties dans plusieurs tables, sans ordre lisible pour quelqu'un qui ne connaît pas la base
- Une centaine de champs de natures différentes : texte, chiffres, tableaux, tableaux dans des tableaux, modèles de messages traduits
02 · Structurer
Ranger par rôle du retailer, puis par équipe qui lit
Le rangement ne suit pas les tables de la base, il suit le métier. Dans le réseau, un retailer peut demander un article, en fournir un, ou faire les deux. Chaque rôle a ses propres réglages. Le premier niveau de l'écran reprend donc ce découpage.
Un retailer qui ne fait que fournir n'affiche que General et Supplier. Personne ne lit une branche qui ne le concerne pas.
Un filtre par équipe, pour ne pas crouler sous les champs
Le second niveau vient d'un tri mené avec les équipes : pour chaque champ, qui en a besoin et qui n'en a pas besoin. Un réglage d'intégration ne dit rien à un agent ops, et un Partner Success n'a pas à parcourir des jetons d'accès. L'écran se filtre donc par équipe, et masque ce qui n'est pas utile à celui qui regarde.
Ce que l'écran garantit
- Un arbre à gauche, repliable, qui montre toute la configuration et le nombre de champs de chaque branche
- Les mêmes sections à droite, dans le même ordre : ce qu'on clique dans l'arbre est ce qu'on lit
- Un filtre par équipe, qui grise ce qui ne concerne pas celui qui regarde
1 / 2 · L'écran
Un retailer choisi en haut, toute sa configuration en dessous. L'arbre de gauche et les cartes de droite suivent le même ordre : ce qu'on clique d'un côté est ce qu'on lit de l'autre.
Le même écran pour trois métiers, mais pas la même quantité d'information pour chacun.
03 · Construire
Une règle par type de donnée, pas un dessin par champ
Le plus gros défi du projet a été celui-là : afficher autant de données, dans autant de formats, sans rendre l'écran illisible. Dessiner une centaine de champs un par un aurait produit un écran figé : au premier champ ajouté en base, il aurait fallu revenir voir le designer pour savoir où le mettre et à quoi il devait ressembler. J'ai préféré décrire comment s'affiche chaque type de donnée, et laisser le schéma faire le reste.
Les types à couvrir
- Les valeurs simples : texte, nombre, pourcentage, oui ou non
- Les listes et les tableaux, avec ajout et suppression de lignes
- Les tableaux dans des tableaux, pour les configurations à plusieurs niveaux
- Les modèles de messages : un titre, un corps, et une version par langue
Le modèle de message est le cas le plus chargé. Il contient du texte et des variables, il existe dans plusieurs langues, et chaque traduction doit pouvoir être lue et corrigée séparément, sans quitter la configuration du retailer.
1 / 2 · Tableaux
Le même gabarit accueille une liste, un oui ou non et un tableau avec ajout et suppression de lignes. Les jetons d'accès restent masqués. L'icône de modification n'apparaît qu'au survol, pour garder l'écran calme.
Modifier sans toucher à la configuration du voisin
Ouvrir la modification à plus de monde crée un risque nouveau. Pour ne pas tout ressaisir, les retailers partagent des configurations, à la manière de préréglages : ils sont réunis en groupes, et une même configuration peut s'appliquer à plusieurs retailers d'un groupe, alors que certains champs restent propres à un seul. Changer une valeur peut donc en changer plusieurs. L'écran signale les sections partagées, et précise la portée d'une modification avant qu'elle soit enregistrée.
Le projet a duré environ un an, porté par un gros travail côté back-end. Nous avons livré section par section. Ce découpage servait autant les développeurs que les utilisateurs : une section à la fois, avec des règles d'affichage déjà posées, plutôt qu'un écran entier à intégrer d'un bloc.
Quand un champ est ajouté en base, il apparaît dans l'outil selon son type. Personne ne demande où le mettre.
04 · Impact
Les tickets ont disparu, l'outil est devenu la norme
Les demandes de modification ne passent plus par un ticket. Le Partner Success corrige la configuration au moment où le retailer le demande, et les blocages liés à l'attente n'existent plus.
Ce qui a changé
- De l'ordre d'une dizaine de tickets par semaine en moins, soit environ une journée de développeur rendue chaque semaine
- Les développeurs utilisent eux-mêmes l'outil pour configurer un retailer, au lieu d'écrire en base
- Un champ ajouté en base apparaît dans l'outil sans ticket et sans passage par le design
- L'outil n'évolue plus aujourd'hui, et il reste utilisé au quotidien par les trois équipes
Ce que je referais autrement tient à la lecture des données. Au départ, je comprenais mal certaines d'entre elles : j'ai pris pour de simples champs ce qui était en réalité des tableaux, faute de savoir lire correctement le schéma en SQL. Sur un outil dont tout le dessin dépend du type de donnée, cette erreur se paie en maquettes à refaire. Aujourd'hui, je commencerais par lire la base avec un développeur, avant le premier écran.
Un outil qu'on n'a plus besoin de faire évoluer et que tout le monde continue d'ouvrir : c'est le signe que la structure tenait.
En résumé
Je range une donnée selon ceux qui la lisent, pas selon la base qui la stocke, et je dessine des règles plutôt que des écrans, pour que l'outil continue de grandir sans moi.