Voilà le truc. Beaucoup d'organisations se plantent parce qu'elles ne savent pas comment ranger leurs designers. Les mettre en silos ? Mauvaise idée. Les jeter partout ? Aussi mauvaise. Il faut un modèle qui marche vraiment, sinon vous finissez avec des designers frustrés qui font du travail qu'on rejette, des devs qui comprennent rien aux intentions design, et des PM qui sont pris entre les deux.
C'est exactement là que ce bouquin devient utile. Il vous dit comment structurer vos équipes de manière à ce que le design soit respecté, écouté, et intégré dans chaque décision de produit. Pas comme un décorateur, mais comme un vrai pilier stratégique.
Les trois modèles d'organisation du design qui existent vraiment
Il y a plutôt trois façons d'organiser votre équipe design, et elles ne font pas toutes le même boulot. Le livre les détaille bien, alors lisez attentivement.
Le modèle centralisé, c'est quand vous avez un studio interne qui prend toutes les décisions design pour tout le reste de l'organisation. Un Head of Design coiffe l'équipe, et sous lui vous avez des spécialistes : recherche utilisateur, archi info, design visuel, ce genre de truc. C'est efficace pour garantir une cohérence visuelle partout, mais ça peut être lent. Les demandes s'entassent. Les designers ne comprennent pas toujours le contexte du produit sur lequel ils travaillent. Et puis les squads doivent attendre après vous.
Le modèle décentralisé, c'est l'inverse. Vous mettez des designers dans chaque squad produit. Ils travaillent au quotidien avec les PM et les devs. Ils connaissent les besoins, les contraintes, les utilisateurs de cette zone du produit. Ça accélère les trucs énormément. Les designers se sentent impliqués, responsabilisés. Ils voient leurs idées arriver en prod. Mais attention : le risque, c'est que votre produit devient un Frankenstein. Pas de cohérence globale. Chaque squad fait un truc différent.
Le modèle centralisé au niveau de la tribu, c'est un hybride. Vous avez plusieurs squads qui travaillent sur des thèmes proches (un tunnel d'achat par exemple, une section du produit). Les designers sont mutualisés au niveau de la tribu pour couvrir toutes ces squads. C'est le meilleur compromis pour la plupart : vous gardez la cohérence, vous laissez les designers comprendre le contexte, et vous ne créez pas un goulot d'étranglement.
Ce que les organisations ratent presque toujours
Le truc que les orgas ratent, c'est la communication. Elles pensent que si elles choisissent un modèle, c'est bon. Pas du tout. Si vous avez des designers répartis dans différentes squads ou au niveau des tribus, ils faut qu'ils se parlent. Sinon, après deux mois, vous avez douze palettes de couleurs différentes, quatre typographies, et des patterns UI qui ne matchent pas.
Le design ne c'est pas juste l'esthétique, c'est aussi la cohérence. Et la cohérence ne vient pas du néant. Elle vient d'une communication régulière entre les designers. Des rituels. Des réunions de travail collective. Un document partagé sur les patterns réutilisables. Un guide de style qu'on met vraiment à jour.
Autre truc crucial : la relation entre les PM, les devs et les designers doit être vraiment collaborative. Si les PM donnent des specs complètes au designer une fois par mois, et que le designer pond une belle maquette qu'on rejette deux fois, vous avez un problème d'organisation. Les trois doivent être dans la même squad, avec les mêmes objectifs clairs. C'est ça que le livre explique bien : comment créer les bonnes interfaces de travail entre les acteurs.
Et puis il y a les orgas qui acceptent l'imperfection. Ouais. Beaucoup de designers sont bloqués parce qu'ils veulent que ce soit parfait. Mais en réalité, l'agilité et l'innovation viennent de l'acceptation qu'on va itérer, qu'on va apprendre en parlant aux utilisateurs, qu'on va améliorer. Pas de paralysie par l'analyse.
Comment mettre en place un flux d'information qui ne prend pas la tête à tout le monde
Un des points les plus utiles du bouquin, c'est qu'il vous dit comment gérer l'information. Les organigrammes hiérarchiques classiques, ça marche pas pour le design. C'est trop lent, trop rigide. Vous avez besoin d'un réseau horizontal où les gens communiquent directement entre eux, où les idées circulent vite, où on prend des décisions éclairées rapidement.
Voilà ce que ça veut dire en vrai :
- Les designers partagent leurs insights rapidement avec les PM et les devs au lieu d'écrire un rapport de 50 pages
- Les utilisateurs remontent directement dans les conversations des équipes produit, pas via un gate-keeper
- Les décisions design se prennent en petit groupe, avec les bons acteurs, pas en grand comité de 15 personnes qui ont rien à faire là
- On formalise juste assez pour pas que le truc devienne du chaos, mais pas trop pour pas que ça ralentisse
Ce que ça donne en pratique ? Vous gagnez du temps. Énormément. Les designers comprennent les contraintes techniques d'entrée de jeu. Les devs savent pourquoi on fait une décision de design. Les PM voient venir les problèmes avant qu'ils arrivent. Et l'équipe apprend ensemble, au lieu que chaque métier fasse son truc dans son coin.
Les avantages qu'on oublie souvent
Si vous mettez bien en place un de ces modèles, avec la bonne communication et la bonne culture, voilà ce que vous gagnez vraiment :
Un, l'agilité. Vous pouvez pivoter rapidement sur votre produit quand le marché change ou que les utilisateurs demandent un truc différent. Pas de cycles de 6 mois où tout le monde attend.
Deux, les silos disparaissent. Les designers, les PM et les devs arrêtent de se battre parce qu'ils comprennent mutuellement les contraintes. Ça améliore le climat de travail énormément. Et en passant, c'est vrai aussi pour tous les autres métiers.
Trois, vous créez de la vraie valeur pour les utilisateurs. Pas juste un truc beau, mais utile. Parce que le design n'est pas la dernière étape, c'est la première. Et parce que tout le monde y réfléchit ensemble.
Quatre, l'innovation. Quand vous avez un réseau d'information ouvert, où les gens se sentent libres de proposer des idées bizarres sans se faire crier dessus, l'innovation arrive. C'est jamais un truc planifié. C'est un PM qui balance une idée, un designer qui dit oui mais avec ce twist, un dev qui dit en fait c'est possible, et boom, vous avez un truc disruptif.
Cinq, la satisfac utilisateur grimpe. Parce qu'on intègre leurs feedbacks rapidement au lieu d'attendre trois mois. Parce qu'on itère sur des vrais problèmes, pas sur des suppositions. Parce que tout le monde dans la squad comprend qui on sert vraiment.
Pour qui ce livre, vraiment
Si vous êtes Head of Design ou Head of Product et que vous avez jamais structuré une équipe design, lisez-le. C'est pratique, c'est pas du blabla théorique, ça parle vrai.
Si vous êtes dans une squad et que vous sentez que le design n'est pas écouté, que les décisions prennent trois mois, que rien n'avance, montrez ça à votre lead. Ça aidera à expliquer le problème et comment le fixer.
Si vous êtes Product Manager et que vous gérez un design qui arrive toujours trop tard, que c'est jamais ce que vous aviez en tête, ce livre va vous dire pourquoi et comment arranger les interactions.
Si vous êtes dev et que vous crevez de frustration parce qu'on vous demande des trucs techniquement impossibles, lisez aussi. Vous verrez que c'est un problème d'organisation, pas un problème de designers stupides.
Même les startup founders qui construisent leur org la première fois y trouveront quelque chose. Parce qu'il vaut mieux bien organiser son design dès le départ plutôt que de le refactoriser en urgence quand vous avez 20 personnes.
Verdict honnête
Ce bouquin est pas magique. Il ne va pas résoudre les problèmes humains entre collègues qui ne s'aiment pas. Il ne va pas remplacer une bonne culture d'entreprise. Et il ne va pas non plus s'appliquer identique à toutes les orgas, parce que votre contexte à vous est spécifique.
Mais il va vous donner un cadre clair pour penser votre organisation design. Il va vous montrer que oui, il existe des modèles qui marchent mieux que d'autres. Et il va vous permettre d'avoir une conversation intelligente avec votre équipe sur comment on travaille, pourquoi on n'avance pas, et comment on s'arrange.
Le style est direct, pas pompeux. Les exemples sont basés sur des vrais situations d'orgas (enfin, vous sentirez que c'est du vécu). Ça se lit vite, c'est pas un bouquin de 500 pages où il faut trier le blabla.
Si vous construisez une équipe produit ou que vous en gérez une qui ne fonctionne pas bien, c'est vraiment le genre d'ouvrage que vous devriez avoir à proximité. Pas pour le lire entièrement d'une traite, mais pour le consulter quand vous vous posez la question : bon, maintenant qu'on est 10 designers au lieu de 2, comment on s'organise ?
