Ressources
Articles, guides, templates et retours d'expérience sur le design produit et l'IA.
Bien démarrer avec Claude Code
Guide complet pour les designers : de l'installation au déploiement, qualité visuelle, skills et Figma MCP.
Claude Code et Figma MCP : concevoir et implémenter sans changer d'outil
Depuis quelques mois, j'utilise Figma MCP pour lire mes maquettes directement depuis Claude Code, générer des composants fidèles au design, et itérer en temps réel entre la maquette et le code. Ce workflow compresse le cycle conception-intégration de plusieurs jours à quelques heures. Je conçois dans Figma, puis Claude Code lit les specs des composants, les espacements, les tokens et la mise en page via MCP, et génère du code prêt pour la production, fidèle à l'intention initiale. Le plus intéressant n'est pas la vitesse. C'est la qualité de la boucle de feedback : quand je vois le résultat instantanément, je prends de meilleures décisions de design parce que je les évalue en contexte, pas de manière isolée.
Concevoir un design system dans Figma, puis l'implémenter avec Claude Code
J'ai récemment mené une expérimentation complète : concevoir un design system entier dans Figma (tokens, composants, variantes, documentation), puis l'implémenter sur un site dédié en Astro et Tailwind, piloté intégralement par Claude Code. Le design system couvre les fondations (couleur, typographie, espacement, élévation), les composants atomiques (boutons, inputs, badges, tags) et les patterns composites (cartes, navigation, formulaires). Ce que cette approche change dans la relation entre le design et le développement est fondamental. Le design system devient une source de vérité unique que le designer et l'IA peuvent lire. Claude Code n'interprète pas des captures d'écran, il lit des données de design structurées. L'écart entre le design voulu et le résultat implémenté se réduit à presque rien.
Former des non-designers à l'IA générative : retours de terrain
J'ai commencé à animer des ateliers IA pour des entrepreneurs et des équipes produit. L'idée reçue la plus courante est que l'IA générative remplace les compétences. Ce n'est pas le cas. Elle amplifie ce que vous savez déjà. Un product manager qui comprend les besoins utilisateurs écrira de meilleurs prompts qu'un junior qui copie des templates. La formation fonctionne mieux quand je pars de leurs problèmes concrets, pas de l'outil.
50 apps en un an : ce que le prototypage IA change concrètement
Depuis le lancement de Condamine Apps, j'ai prototypé et déployé 50 applications web fonctionnelles avec Claude Code, Bolt et Cursor. Le gain de vitesse est réel : ce qui prenait des semaines prend maintenant des jours. Mais les décisions de design restent les miennes. L'IA accélère la production, elle ne remplace pas la réflexion. Le vrai changement, c'est que je peux maintenant valider des idées avec de vrais prototypes fonctionnels au lieu de maquettes statiques.
Utiliser Claude Code sur l'ensemble d'un projet de design produit
Du cadrage fonctionnel à la production d'écrans, du prototypage à la documentation, j'ai intégré Claude Code à chaque phase d'un projet de design produit pendant six mois. Pour le cadrage, il aide à structurer les exigences et générer des diagrammes de flux utilisateur. Pour le design, il lit les fichiers Figma et produit du code de composants. Pour le prototypage, il construit des applications fonctionnelles déployées sur Vercel en quelques heures. Pour la documentation, il génère des specs techniques et des supports de handoff. Ce qui fonctionne : l'accélération est réelle sur les tâches répétitives, la génération de code et l'itération rapide. Ce qui ralentit : des instructions ambiguës produisent des résultats ambigus, ce qui rend la capacité du designer à cadrer précisément encore plus critique. Ce qui change : la posture du designer passe de quelqu'un qui livre des écrans à quelqu'un qui orchestre une chaîne de production. Le craft ne disparaît pas, il évolue.
Pourquoi j'organise le travail design en saisons, pas en sprints
Chez France VAE, j'ai restructuré le workflow design autour de saisons d'un mois avec trois cycles de livraison chacune. Les sprints créent de l'urgence mais pas de la clarté. Une saison donne suffisamment de temps pour cadrer un problème, explorer des solutions et livrer quelque chose de tangible. Chaque saison a un thème, un ensemble de livrables et une rétrospective. L'équipe est passée du mode réactif au mode intentionnel en deux saisons.
Animer des ateliers de design thinking en mission publique
Chez beta.gouv.fr, j'ai animé des ateliers de deux jours avec des acteurs de terrain qui n'avaient jamais entendu parler de design thinking. La méthode a fonctionné, mais seulement après avoir retiré tout le jargon. Pas de "How Might We", pas de dot voting théâtral. Des questions claires, des post-its et des conversations structurées. Le résultat était meilleur parce que les participants se sentaient respectés, pas sermonnés.
Le binôme PM-Designer : trois principes pour que ça fonctionne
Chaque collaboration PM-Designer productive que j'ai vécue reposait sur trois choses. Une préparation rigoureuse : chaque atelier a un scénario, des exercices et un livrable défini. Une transparence continue : le PM voit le design évoluer en temps réel, et on ajuste ensemble plutôt que d'attendre une grande révélation. Des décisions documentées : chaque arbitrage est consigné, pour ne jamais rouvrir les mêmes débats. Sur le partage des responsabilités, le PM porte les specs, le designer les alimente avec des maquettes annotées et des parcours utilisateurs documentés. On s'aligne sur les priorités en amont, et on présente ensemble aux parties prenantes. Le travail de design avance plus vite quand le PM fait confiance au processus et que le designer respecte les contraintes produit.
Recruter des designers quand on est le seul designer
Quand j'ai rejoint UNOWHY, j'étais le seul designer pour cinq produits. Le réflexe est de recruter quelqu'un qui travaille comme soi. La meilleure approche est de recruter quelqu'un qui vous complète. J'ai recruté cinq designers en trois ans. Chacun apportait une compétence que je n'avais pas : motion, recherche, pensée systémique. L'équipe est devenue plus forte justement parce que je n'ai pas cherché à me cloner.
Le cadrage design, c'est 80 % du travail
La plupart des projets design qui dérapent le font avant qu'un seul écran ne soit dessiné. Le brief était vague, le périmètre implicite, les critères de succès absents. Je passe désormais la première semaine de toute mission sur un document de cadrage : quel problème on résout, pour qui, ce qu'on livre, ce qu'on ne fait explicitement pas. Ce n'est pas un travail glamour. C'est le travail qui rend tout le reste possible.
Template : Cadrage Design
Le document que je remplis avant d'ouvrir Figma pour aligner tout le monde sur le 'Pourquoi'.
Rituel : Synchro PO / Design
Comment organiser la collaboration hebdomadaire pour éviter l'effet tunnel.
Atelier : Design Teardown
Template pour auditer une interface existante en équipe et identifier les dettes UX.
Checklist : Design de fonctionnalité
Rien ne doit être oublié avant le dev : edge cases, états vides, erreurs, responsive.
Méthode : Découpage UI (Slicing)
Comment je découpe une interface en composants React/Atomic pour les développeurs.
Figma : Convention de nommage
Comment je gère les statuts (WIP, Review, Dev Ready) pour qu'on s'y retrouve.
Construire une roadmap quand le produit n'existe pas encore
SQOOL Extend a commencé comme un slide PowerPoint en réunion de direction. Pas de specs, pas d'utilisateurs, pas de benchmark concurrentiel. Pour construire la roadmap, j'ai mené cinq entretiens avec les parties prenantes, cartographié les hypothèses sur une matrice de risques, et conçu un plan MVP en trois phases. La première version a été déployée dans cinq établissements en quatre mois. La roadmap n'était pas un diagramme de Gantt, c'était une séquence de paris qu'on pouvait valider rapidement.
Comment une culture design s'installe vraiment dans une organisation produit
Chez UNOWHY, j'ai travaillé à faire du design une pratique partagée au-delà de l'équipe design. J'ai invité les product managers à observer les tests utilisateurs. J'ai animé des ateliers d'idéation cross-fonctionnels réunissant métier, tech et design. J'ai documenté chaque décision de conception pour que l'équipe puisse s'y référer au lieu de rouvrir les mêmes débats. De petites actions répétées, tissées dans le quotidien. Avec le temps, six départements se sont impliqués dans la démarche design : tech, produit, customer success, design, direction et utilisateurs finaux. L'argument le plus convaincant a toujours été le plus simple : un test utilisateur de trente minutes qui évite trois semaines de développement dans la mauvaise direction.
Un design system pour cinq marques : le vrai défi n'est pas technique
Chez UNOWHY, j'ai construit un design system unifié pour SQOOL, SQOOL Extend, SQOOL Protect, Hi SQOOL et la marque corporate. L'architecture Figma était simple : fondations partagées, tokens spécifiques par marque. Le plus dur a été de mettre cinq product managers d'accord sur des composants communs. J'ai passé plus de temps en réunions d'alignement que dans Figma. Le système a réduit le temps de conception de 60 %, mais seulement parce que l'équipe lui faisait confiance.
Passer de designer à lead : ce que personne ne vous explique
Le plus gros ajustement, ce n'est pas le management, c'est d'accepter de lâcher le craft. Quand je suis devenu Design Lead chez UNOWHY, j'ai dû accepter que mon équipe designerait les choses différemment de moi. Et c'était très bien comme ça. Mon travail est passé de la production d'écrans à la prise de décisions : recrutement, processus, priorités, alignement des parties prenantes. Les designers qui galèrent le plus en rôle de lead sont ceux qui n'arrivent pas à arrêter de designer.
Designer pour 500 000 utilisateurs qui n'ont jamais demandé votre produit
SQOOL a été déployé dans 465 lycées d'Île-de-France. Les élèves ne l'ont pas choisi, la Région l'a fait. Designer pour des utilisateurs captifs change tout. On ne peut pas se fier aux métriques d'engagement ou au NPS. Il faut observer le comportement réel en classe, parler aux enseignants, et regarder où les élèves bloquent. L'interface doit fonctionner du premier coup parce qu'il n'y a pas de flux d'onboarding quand la sonnerie retentit.
Quand la direction produit est floue, le design crée le plus de valeur
Chez UNOWHY, j'ai hérité de SQOOL Connect, un launcher Android vieillissant avec des dizaines de fonctionnalités et aucune direction produit claire. Au lieu de redessiner l'interface, j'ai cartographié le parcours enseignant-élève à travers les cinq applications. Cette cartographie est devenue un prototype de vision unifiée, présenté au comité de direction. On a construit un démonstrateur testable et on l'a mis devant de vrais utilisateurs. Les résultats ont orienté vers des applications spécialisées plutôt qu'un launcher unique. Connect a été abandonné. Cinq produits ciblés l'ont remplacé, et la suite a atteint 500 000 utilisateurs. Structurer l'ambiguïté en amont a épargné des mois de développement sur un produit qui n'aurait pas résolu le vrai problème.
Storybook comme outil de négociation avec les développeurs
Chez Dailymotion, j'ai créé le premier UI Kit de l'équipe avec Storybook. L'objectif initial était la documentation. L'impact réel a été la négociation. Quand un développeur voulait sauter un état hover ou simplifier un composant, je pouvais montrer la page Storybook et dire "c'est ce qu'on a validé ensemble". Les conversations design-développement sont passées des opinions aux artefacts partagés.