Vidéo · · 11 min
Les process design évoluent, les Product Builder, le momentum en delivery
Andy Madrick, designer chez Notion, montre comment l'IA a changé son workflow : prototypes que tout le monde peut modifier, animations générées à partir de captures, technique du scaffold. Pantéa décrit le passage du designer au Product Builder. Et deux équipes françaises expliquent comment garder le momentum en delivery.
Charles Loumeau
Contenus mentionnés
- Dive Club × Andy Madrick (Notion), Why AI changed design handoff forever
- The Product Crew, AI Design : le futur du designer n'est pas dans le code (Pantéa, Beside)
- Clé de Voûte × Robin (Batch Ventures) et François (Pictarine), 3 méthodes pour accélérer le développement produit
Au programme
Les sujets de cette vidéo
Designer + IA : les nouveaux process chez Notion
Andy Madrick est designer chez Notion. Dans le podcast Dive Club, il raconte comment l'IA a changé sa routine.
Son problème de départ : avec des maquettes Figma statiques, la boucle de feedback est longue. Les collègues commentent, demandent une variante, attendent de voir le résultat, et on recommence.
Sa solution est un playground généré par l'IA : un prototype interactif que n'importe qui peut manipuler. Des contrôles intégrés, un peu comme des interrupteurs, permettent de changer en direct le titre, le nombre d'éléments ou la variante. Les collègues testent les options et envoient une capture de leur version préférée. Les retours sont plus riches, plus rapides, avec moins de réunions. Les gens ne décrivent plus ce qu'ils voudraient voir, ils le font eux-mêmes.
Pour les animations, il ne les règle plus dans Figma. Il prend des captures des différentes étapes, les envoie à l'IA, et la vision par ordinateur comprend l'enchaînement attendu et produit la transition en CSS. Des heures de réglages deviennent quelques minutes.
Reste le passage en production : un prototype codé avec Cursor est rarement reprenable tel quel. Chez Notion, le développeur relit désormais le plan de tâches de l'agent avant qu'il ne code, pour le guider vers les bonnes parties du code. Ils utilisent aussi la technique du « scaffold » : les développeurs construisent une version fonctionnelle mais moche de la feature, avec un backend propre, puis l'agent applique le design d'Andy par-dessus.
Des designers deviennent Product Builder
Pantéa, designer avec quinze ans d'expérience (PayPal, BlaBlaCar, aujourd'hui Beside, une startup qui construit des agents IA), était l'invitée de The Product Crew. Elle décrit trois changements dans son métier.
Le design statique ralentit tout. Avec Cursor, elle prototype directement dans le code, teste des branches, partage via Loom et obtient un retour en 24 heures. Le produit vit dès le début.
Elle ne conçoit plus seulement des écrans. Dans un produit IA, elle conçoit aussi les comportements invisibles : le ton, les limites de l'IA, le passage à un humain, les cas sensibles. Le design devient aussi de l'ingénierie comportementale.
Les rôles se mélangent. Elle code, teste et livre par elle-même. Les frontières entre designer, PM et développeur s'estompent au profit d'un profil qu'elle appelle Product Builder : quelqu'un qui n'a pas le niveau d'un développeur ou d'un PM sur tout, mais qui touche à ces périmètres avec un fort ownership, de bout en bout.
Sa conclusion : ce qui reste irremplaçable, c'est le jugement. L'IA génère des options, le designer décide quoi construire et ce qui est acceptable. Le métier se déplace de la production vers l'arbitrage.
Comment les meilleures équipes gardent la vitesse en grandissant
Le podcast Clé de Voûte a réuni Robin, fondateur de Batch Ventures, et François, CEO de Pictarine, autour d'une même obsession : ne jamais perdre le momentum.
Robin l'a observé dans l'écosystème Y Combinator : les meilleures équipes pensent momentum avant beau produit. Des boîtes lancent des produits partiellement codés, avec des fonctionnalités qui ne marchent pas encore, parce que ce qui compte est le signal de marché. Il nuance : certaines pivotent trop vite, et le produit ne se limite pas à l'interface. Le support, l'onboarding, tout l'écosystème autour font aussi la qualité de l'expérience.
La bonne question, selon lui : a-t-on un signal de marché suffisant pour apprendre ? Définir ce seuil à l'avance, c'est le travail du PM.
François a transformé cette culture en principes écrits chez Pictarine. Le premier, « J'agis » : tu n'attends ni la prochaine réunion, ni la validation du chef, ni 3 % de données en plus. Si une feature peut partir un vendredi, elle part le vendredi, parce que le week-end est leur pic de trafic. Avec une condition : agir vite sans communiquer, c'est du chaos ; agir vite en communiquant, c'est de la vélocité. L'équipe doit savoir ce qui se passe pour pouvoir challenger.
Sa conclusion : la vitesse vient de la clarté sur ce qu'on accepte comme « assez bon » pour passer à l'étape suivante. Définir ça, c'est aussi le travail du PM.