Chanel · My Little Black Book

Une demande peut être parfaitement logique pour une branche et beaucoup moins pour les deux autres. Si chaque besoin local devient sa propre feature, l’application se remplit vite de comportements particuliers et devient de plus en plus difficile à faire évoluer.

Je travaille avec les PO et les développeurs pour garder ce qui doit être commun, tout en laissant de la place aux vraies différences métier. À la fin de la mission, je suis le seul designer sur le produit.

La cohérence passe aussi par le système. Quand j’arrive, une partie du travail vit encore dans Sketch. La migration vers Figma et la première couche de design system se font pendant que les features continuent de sortir.

Le système aide à absorber les demandes, mais il ne dit pas si une demande mérite de devenir une feature.

À un moment, une des branches veut intégrer un calendrier directement dans MLBB. Sur le papier, l’idée se tient : concentrer davantage d’outils dans l’application et éviter aux managers de changer d’environnement.

Sur le terrain, la logique tient beaucoup moins. Les managers ont déjà leurs habitudes et leurs outils de planning. MLBB est déjà chargé, la dette technique est réelle et l’effort disponible ne permettrait probablement pas de construire un calendrier meilleur que ce qui existe déjà.

Le pari n’est donc pas bon : ajouter une nouvelle couche dans un produit déjà dense, pour remplacer un usage qui fonctionne par une version plus faible.

Je ne voulais pas arriver devant le business avec un simple « non ». J’ai montré le cas idéal, ce qu’on pouvait vraiment développer avec le temps et la dette existante, puis ce que donnerait une version minimale. Mis à côté de ce qu’on avait observé en boutique, le rapport coût / valeur devenait beaucoup plus clair. Il a fallu défendre cette position dans un contexte politique, mais le sujet a finalement été arrêté.

Une bonne partie de mon rôle sur MLBB ressemble à ça : avant de transformer une demande en écran, vérifier ce qu’elle change pour le vendeur ou le manager, ce qu’elle ajoute au produit et ce qu’elle coûtera ensuite aux équipes qui devront la maintenir.

Quand une feature est utile, l’application doit se faire oublier assez vite pour laisser la place à la relation en boutique.

Le passage de Sketch à Figma, le système partagé et ce type d’arbitrage ont servi le même but : continuer à faire évoluer MLBB sans devoir redessiner le produit à chaque nouvelle demande.