Visual — hero
Projet professionnel
Chanel — My Little Black Book
Faire grandir MLBB sans lui faire tout avaler.
My Little Black Book accompagne les équipes boutique dans beaucoup de moments du quotidien : retrouver un client, préparer une action, vendre, payer, gérer du stock ou reprendre une tâche plus tard. Quand je rejoins le produit, il est encore surtout européen. Pendant près de deux ans, le périmètre, l’équipe et le nombre de demandes augmentent en même temps.
(01) Contexte
Trois divisions, un seul produit
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 scope.
Où en était le produit
L’échelle du produit et de l’organisation, pas des résultats attribués au design.
Une partie de cette 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.
123- 1Le composant média commun donne sa place au visuel de campagne.
- 2Le visuel choisi est affiché en entier, tel que le client le recevra.
- 3Les canaux reprennent le pattern de liste commun : nommés, un tap pour choisir.
Le système aide à absorber les demandes. Mais il ne répond pas à la question la plus importante : est-ce que cette demande mérite vraiment de devenir une feature ?
(02) Jugement produit
Une feature que j’ai préféré tuer
À 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 risque était donc assez mauvais : ajouter une nouvelle couche dans un produit déjà dense, pour remplacer un usage qui fonctionne par une version plus faible.
Comment la demande de calendrier a été pesée
- 01Le calendrier idéal
- 02Ce qu’on pouvait vraiment développer
- 03La version minimale
- 04À côté des outils de planning déjà utilisés en boutique
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 assez politique, mais le sujet a finalement été arrêté.
(03) Parcours vendeur
Le terrain reste le meilleur filtre
Cette histoire résume assez bien mon rôle sur MLBB. Je ne suis pas là pour transformer chaque demande en écran. Je dois aussi 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 à toutes les é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.
-
01
Retrouver
0:00Depuis la Home, ouvrir les Suggestion Boards, nommer le board et choisir le client.
-
02
Comprendre
0:10Ajouter les pièces par leur nom complet et leur référence, comme les vendeurs en parlent. Un board peut se préparer à l’avance et s’enrichir au fil du temps.
-
03
Agir
0:16Le partager sous forme de lien. Le client dit ce qu’il veut faire mettre de côté.
Le passage de Sketch à Figma, le système partagé et ce type d’arbitrage ont servi la même chose : continuer à faire évoluer MLBB sans devoir redessiner le produit à chaque nouvelle demande.
