- Au lieu de rédiger des spécifications et de créer des maquettes Figma, passage à un workflow de design où les idées sont transformées directement en fonctionnalités prototypes réellement utilisables
- Autrefois sceptique vis-à-vis des LLM comme Copilot, Cursor ou Gemini, l’auteur a réalisé après avoir rejoint Jane Street que l’assistance IA est devenue indispensable
- Claude permet des itérations gratuites et illimitées : même après 50 modifications, il ne rechigne pas à affiner le bouton Submit, les raccourcis clavier ou les formulations
- Les designers peuvent eux aussi, comme les ingénieurs, créer eux-mêmes des preuves de concept (POC) fonctionnelles afin que d’autres puissent les tester directement
- En concentrant tous les efforts sur le livrable réel, cette approche débouche sur un nouveau modèle de collaboration qui élimine les tâches intermédiaires annexes
Du scepticisme envers les LLM au changement de cap
- Longtemps resté sceptique vis-à-vis des LLM, avec des résultats décevants à chaque essai
- L’an dernier, tentative avec Copilot et Cursor pour modifier un jeu développé personnellement, mais aucun des deux n’a réussi à produire des changements fonctionnels
- Dans un précédent emploi, utilisation de Gemini pour générer une ébauche de brief produit et des wireframes, mais tout a été abandonné
- Les usages testés concernaient tous des domaines déjà bien maîtrisés, et les résultats étaient moins bons qu’en faisant soi-même
- Après avoir rejoint Jane Street l’été dernier, prise de conscience que l’assistance IA est indispensable
- Notamment parce qu’il y avait de nombreux domaines nouveaux et encore mal maîtrisés, comme OCaml et Bonsai
- La plus grande surprise a été de voir changer son workflow de design, pourtant domaine qu’il maîtrisait le mieux
Un workflow centré sur le prototype
- Au lieu de rédiger des spécifications, faire des maquettes Figma, écrire des propositions ou revoir l’implémentation avec les développeurs, construction directe de fonctionnalités prototypes qui exécutent exactement le comportement visé
-
Flux de travail concret
- Rédiger le problème et la proposition par écrit
- Ouvrir l’éditeur, lancer le build, le serveur et Claude, puis utiliser cette description comme prompt
- Faire d’abord fonctionner le cœur de la fonctionnalité pour prouver la faisabilité
- Itérer autant que souhaité
- Pousser les changements dans l’environnement de développement et recueillir les retours utilisateurs
- Soumettre une feature correspondant, dans cette entreprise, à une pull request, avec l’apparence et le comportement attendus
- Un prototype intégré au vrai codebase s’est révélé meilleur que des maquettes ou des documents dans presque tous les cas
Exemple de prototype pour la saisie JSQL
- Création récente d’un prototype ajoutant le prompting LLM à la saisie JSQL
- JSQL est un dialecte SQL interne utilisé dans divers outils destinés aux utilisateurs
- Le prototype fonctionnait réellement, et a été utilisé et testé pendant plusieurs jours au quotidien
- Claude permet des itérations gratuites et illimitées : même au 50e changement d’avis ou pour de petites retouches, cela ne pose aucun problème
- Ajustement du bouton Submit, ajout de raccourcis clavier, retouches des formulations, ajustement des prompts, ajout de messages de confirmation générés
- Dans un emploi précédent, ce type d’amélioration aurait nécessité plusieurs jours voire semaines d’aller-retour entre ingénierie et design, ou n’aurait tout simplement jamais vu le jour
- Tous les efforts sont consacrés à l’amélioration du livrable réel, et non à des tâches annexes comme la création de composants Figma ou la mise en forme de documents
Comment ce workflow s’est installé
- Il a fallu du temps pour arriver à cette manière de travailler
- Au début après l’arrivée dans l’entreprise, l’IA n’était utilisée que pour de petites tâches comme la correction de défauts UX mineurs
- Pour les idées plus ambitieuses, Figma et les documents restaient la norme, et les tentatives avec Claude échouaient
- Ces deux derniers mois, les occasions d’ouvrir Figma ont fortement diminué
- Grâce à la combinaison des progrès des modèles, de l’expérience acquise et d’un meilleur choix de périmètre, l’IA fonctionne aussi sur des tâches plus importantes
- En plus des prompts JSQL, de nombreux prototypes ont traité des changements liés aux outils utilisateur, aux modèles de données et aux bibliothèques, certains avec des diffs de plus de 2 000 lignes
- Après avoir conçu dans Figma puis implémenté un prototype interactif, ou pour certaines nouvelles applications, Figma est parfois totalement contourné et le design visuel est itéré dès le départ avec Claude
Ce que cela apporte aux designers
- Un ingénieur peut transformer une idée en preuve de concept fonctionnelle par lui-même, alors qu’un designer doit souvent convaincre d’autres personnes
- Une idée comme le « prompting LLM directement dans la saisie JSQL » peut être d’une faisabilité incertaine au départ, et demander à quelqu’un d’autre d’en réaliser le prototype pourrait faire perdre du temps
- Il se peut aussi que la proposition ne réponde pas clairement à un besoin utilisateur
- En implémentant réellement l’idée avec Claude, il devient beaucoup plus facile pour les autres de l’essayer et de l’évaluer directement
Les défis du mode de revue
- L’inconvénient est que les reviewers se retrouvent face à une fonctionnalité déjà terminée
- D’où la question : finissent-ils par ne pouvoir relire que le code, sans vraiment avoir prise sur la fonctionnalité elle-même ?
- C’est comparable, côté design, au fait de recevoir des wireframes détaillés d’un PM avec pour seule consigne de « faire quelque chose de joli »
- L’objectif est de formuler la proposition de façon aussi claire et complète que possible, tout en souhaitant que les collègues ingénieurs itèrent aussi dans l’espace du design, comme ils le feraient à partir d’une maquette Figma
-
Solution actuelle
- Choisir de considérer la feature différemment et ajouter une courte note explicative
- Le prototype est un document de proposition vivant, le code est jetable, et le rôle du reviewer est d’apporter un retour sur le design et l’expérience utilisateur
- Au final, le reviewer reprend l’idée et l’implémente dans une feature séparée, en s’appuyant sur le prototype mais en gardant la responsabilité directe du code de production
- La bonne manière de procéder reste encore en exploration
Inquiétudes et tension familière
- Concevoir avec Claude fait craindre de quitter une pensée souple et créative pour rester enfermé dans une pensée itérative limitée à ce que l’on suppose que Claude peut produire
- Cela peut convenir à des outils matures qui évoluent par petites touches, mais risque de faire passer à côté d’idées quand il s’agit de quelque chose de nouveau
- C’est une tension familière, qui rappelle le débat de 2011 : « les designers doivent-ils écrire du code ? »
- Les critiques soutenaient qu’une fois engagé dans la programmation, il devenait plus difficile de faire évoluer fortement les idées
- Pourtant, comme l’auteur aimait à la fois créer des sites web et programmer, il a continué à coder
- Avec la généralisation de frameworks front-end comme React et la complexification du développement, le choix a été fait d’aller vers davantage de spécialisation
- Les projets personnels sont encore réalisés en React, ce qui aide à mieux communiquer avec les développeurs
- Mais la majeure partie du temps de travail était consacrée à Figma et aux documents
- Sans les LLM, rejoindre Jane Street aurait probablement conduit à s’enfermer encore davantage dans Figma
- Il existait déjà une certaine expérience en JavaScript, mais OCaml et Bonsai étaient entièrement nouveaux, ce qui aurait donné l’impression que toute contribution technique était hors de portée
- À la place, le retour vers la création du livrable réel donne le sentiment de revenir à ce médium, ce qui paraît enthousiasmant et procure une liberté encore plus grande d’essayer n’importe quoi
1 commentaires
Réactions sur Hacker News
Côté business, ils arrivent déjà souvent avec les exigences sous la forme d’une solution qu’ils ont eux-mêmes imaginée, et c’est généralement une sorte de machine de Rube Goldberg, donc il faut faire de la rétro-ingénierie dans la discussion pour remonter au vrai besoin
À l’avenir, ils risquent d’arriver avec une solution déjà « prête » et « fonctionnelle », et d’être encore moins ouverts à l’idée de prendre du recul sur la conception et l’architecture dans leur ensemble
On va sans doute entendre : « Il suffit de le faire comme ça. C’est presque terminé, pourquoi est-ce qu’on a encore besoin de l’avis de X ? »
Le problème, c’est que le business ne comprend pas pourquoi l’app ne peut pas être déployée telle quelle en production
La pression du type « avec l’IA on peut aller plus vite » augmente, et au final tout dépendra de la qualité de la dynamique organisationnelle
L’avantage, c’est que les idées sont bien plus sérieusement testées qu’avec un simple croquis sur une serviette
Claude aura probablement déjà posé des questions sur les cas limites et les décisions de design, et il est fort possible qu’à un moment quelqu’un ait explicitement dit « ne t’occupe pas de ça, fais une hypothèse » ou « après quelques essais, cette interaction ne me plaît pas, propose autre chose »
Pour l’instant, la pression du « qu’est-ce qu’il y a, déployez-le simplement » est forte, stupide et démoralisante, donc on est proche d’une perte nette, mais si ça se stabilise, cela pourrait devenir un gain net pour les projets futurs
Sauf que ces retouches mineures, ce sont des problèmes comme une mise en page qui casse si le navigateur ne fait pas exactement 1920 px de large, des filtres et tris qui dysfonctionnent parfois, ou encore de nouvelles valeurs qui ne se répercutent pas correctement dans l’app après certaines actions
Quel que soit le problème, le business estime déjà avoir fait 95 % du travail et part du principe qu’« un développeur expérimenté corrigera ça rapidement »
Les gens s’habituent à leur résultat et acceptent de moins en moins les changements apportés par un nouveau mixage professionnel
Il y a des PM, CSM et TAM qui savent traduire un problème client en fonctionnalité produit utilisable, mais si on saute l’étape de définition du problème et qu’on laisse une autre équipe fonctionnelle fabriquer une solution, cela finit généralement en catastrophe avec un énorme gaspillage côté ingénierie et autres ressources
Quand quelqu’un arrive avec une solution, on risque de passer des mois à construire un logiciel exploitable en production avant de découvrir que les clients le détestent, que cela ne résout pas leur problème, ou que cela en crée de nouveaux
Pas là où je travaille aujourd’hui mais dans une ancienne boîte, où ça a été mis en production tel quel malgré des problèmes de perte de données et de sécurité
Si je comprends bien, Jane Street est investisseur dans Anthropic, donc il faut garder ça en tête
En juillet 2025, le régulateur indien SEBI a aussi accusé Jane Street d’avoir recouru à plusieurs entités pour faire de la manipulation de marché, et lui a interdit l’accès au marché
Les grosses machines à cash ont sûrement besoin de beaucoup de dashboards
Ici, le designer semble partir dans la mauvaise direction, comme s’il tombait dans une forme de fantasme d’ingénieur consistant à vouloir rendre le prototype aussi profond et réaliste que possible
Mais ce n’est pas l’aspect le plus important du travail de design
Le plus important, c’est de construire la bonne chose
Des questions comme « Pourquoi faut-il une zone de saisie JSQL ? Qu’est-ce qu’on veut vraiment ? Quelles autres approches existent ? » se résolvent souvent mieux avec des croquis au stylo sur papier, des réunions, de l’observation et des discussions
C’est préférable à un cadrage trop rapide sur un design précis qui amène ensuite à débattre de détails comme savoir si le bouton doit être à gauche ou à droite, ou comment le LLM doit se comporter précisément
Bien sûr, c’est peut-être exactement ce qu’ils veulent nous faire croire
Je vois ça parfois
Les LLM, aujourd’hui, ne voient pas au-delà de l’itération en cours, donc c’est à moi de sortir du cadre et de me demander « et si on regardait sous cet angle ? », ce qui fait soudain émerger une nouvelle façon de concevoir
Parfois, il faut même créer un diagramme de flux pour aider le LLM à voir au-delà de son étape d’avancement
Quand il dit « Claude m’a donné des itérations gratuites et illimitées, sans se soucier du fait que je changeais d’avis pour la 50e fois ou que je demandais de petites retouches », est-ce qu’il ne paie pas Claude ?
Les petits studios de design fonctionnent souvent pareil, et ce n’est pas toujours une facturation horaire comme pour les développeurs
J’ai répondu honnêtement que j’étais vraiment mauvais en design, et que j’avais aussi du mal à extrapoler à partir d’un design system
J’ai énormément de mal à arriver à quelque chose qui ait l’air correct, et dans le processus je finis presque toujours par empirer les choses
Le designer qui me faisait passer l’entretien l’a pris personnellement et m’est tombé dessus
Ça m’était déjà arrivé auparavant
Les designers détestaient les questions incessantes sur l’apparence que ça devait avoir, et voulaient un transfert ponctuel après lequel tout serait censé être réglé
Même en agence marketing/publicité, je devais me battre en permanence pour obtenir des exemples montrant à quoi devaient ressembler les éléments non couverts par les specs de design
Je ne dis pas que j’avais raison, mais pour moi c’est un vrai talon d’Achille
Donc quand j’entends « gratuit, itérations illimitées, sans s’en soucier », je pense d’abord au temps et à la patience avant de penser à l’argent
Bolt, que j’utilise pour le prototypage, ne se met pas en colère
Il ne produit peut-être pas le meilleur design, mais c’est bien meilleur que ce que je suis capable de faire, et une fois terminé on peut demander à un vrai designer de l’améliorer
En attendant, je n’ai pas à m’inquiéter de mettre quelqu’un en colère
J’utilisais Claude Design côté frontend.
Le rendu visuel et l’impression générale sont largement corrects, mais les designs finissent souvent par se ressembler et suivent en général des patterns convenus du web moderne.
Je me demande si quelqu’un a essayé avec ça des pistes créatives non conventionnelles.
J’y ai passé environ trois semaines jusqu’ici et ce n’est pas encore terminé, mais vous aurez l’idée.
De la même manière qu’il y avait des boilerplates SaaS ces dix dernières années, il existe aussi des boilerplates LLM appris depuis Internet.
Cela dit, en y mettant suffisamment la main, tout reste encore possible.
C’est intéressant de voir qu’il s’aligne sur les exigences qu’on lui donne, et que sans direction il fait des choix prudents.
Si vous allez évaluer l’esthétique du rendu ainsi que l’expérience utilisateur et le contenu, mais que vous donnez très peu de prompts sur l’aspect esthétique, vous n’obtiendrez que des valeurs par défaut prudentes.
Il sait bien produire des designs qui donnent une impression de copie bootstrap/tailwind, mais il faut pousser consciemment dans une autre direction sur ce point.
Pour les pages web simples, j’ai commencé à mettre le style visuel comme seul objectif des premières itérations.
Il suffit de lui indiquer précisément qu’on veut quelque chose de non standard visuellement, et de lui donner des exemples du style de site souhaité.
En se battant un peu avec, on obtient quelque chose qui semble un peu plus créatif, mais cela demande du travail de prompt.
Il m’a été recommandé par des designers très respectés et très expérimentés, et eux réalisent désormais leurs prototypes presque entièrement dans Claude avant de les peaufiner dans Figma s’ils leur plaisent.
Si on demande au départ une UI générique sans prompt de style détaillé, il est normal d’obtenir un design générique.
L’avantage ici, c’est que les designers apprennent à coder.
J’ai toujours trouvé étrange que des designers façonnent des logiciels sans savoir comment les logiciels sont fabriqués.
Pour info, je suis moi-même designer.
En revanche, designer dans le code est une approche tech d’abord.
Si le but du design est de façonner un résultat en fonction d’objectifs humains, on peut aussi considérer qu’il vaut mieux ne pas partir des règles strictes du code.
Ce n’est pas pour obtenir un joli rendu, mais pour faire avancer la réflexion, il reste difficile de battre le stylo et le papier.
Maintenant qu’on peut pratiquement coder à la voix, je reviens au vibe coding et à la création de produits, et c’est vraiment génial.
Mon manager est encore en train de comprendre cette nouvelle situation, mais on dirait que l’ancienne séparation des rôles commence à mourir.
Je pense qu’être à l’intersection est la meilleure place aujourd’hui.
J’ai l’impression que toute ma vie m’a préparé à ce moment.
Pour les designers, cela ressemblerait plutôt à une sorte de Figma où l’on voit le résultat puis on l’ajuste en langage au lieu d’un éditeur visuel.
Ma femme est product manager dans une FAANG, et son équipe s’appuie énormément sur l’IA pour vibe coder des morceaux de logiciel qu’ils auraient auparavant faits avec Word ou Excel.
Ils n’apprennent pas à coder et ne regardent pas le code une seule seconde.
L’approche qui consiste à dire que « le prototype est un document de proposition vivant, que le code peut être jeté, et que le rôle du reviewer est de donner du feedback sur la conception et l’expérience utilisateur ; qu’au final le reviewer récupère l’idée pour l’implémenter comme une fonctionnalité séparée, en s’appuyant sur le prototype comme référence mais en possédant lui-même le code de production » résout un problème que j’avais sur tous les POC.
C’est une très bonne manière de faire.
Quand on traite un problème précis d’un produit précis, il est facile de parler de « document de proposition ».
Mais énormément de designers utilisent toujours Figma pour définir et maintenir des design systems à l’échelle de produits et de plateformes entiers, et dans ce cas Figma reste la source de vérité.
Mon équipe travaille aussi comme ça, et moi je suis ingénieur frontend ; honnêtement, l’ancienne façon de faire me manque vraiment.
Comme les spécifications écrites sont remplacées par des prototypes fonctionnels, cela ajoute une charge cognitive supplémentaire : il faut maintenant lire le code pour déterminer quels changements étaient voulus et quel bruit doit être ignoré.
On nous transmet des PR générées et il faut décider s’il faut faire les modifications nécessaires ou tout refaire depuis zéro, avec de la friction dans les deux cas.
Il m’est aussi arrivé de voir beaucoup de changements involontaires générés ; après avoir passé du temps à les réimplémenter, j’ai ensuite eu droit à un « ah, désolé, ça n’était pas censé changer ».
Je comprends l’intérêt de donner plus d’autonomie, mais cela a retiré une partie du plaisir que je trouvais dans mon ancien travail pour la remplacer par des casse-têtes.
Les équipes design et produit font du vibe design et du vibe coding de fonctionnalités ou d’expériences avec Claude, fabriquent vite des prototypes, puis les montrent aux clients pour récolter du feedback avec un minimum de temps d’ingénierie.
C’est formidable.
Mais ce qui peut surprendre, c’est que cela n’a pas vraiment aidé à livrer plus vite dans l’ensemble.
Je pense que c’est parce qu’on a perdu de la réflexion dans le processus.
Une part non négligeable de la réflexion est désormais sous-traitée au modèle de langage.
Il colmate les trous des prompts et remplit les comportements non explicités par des hallucinations.
Là où autrefois on se serait arrêté en se disant « ça colle mal », « comment transmettre cette idée ? », « qu’est-ce qui se passe dans ce cas ? », ces pauses ont disparu, et maintenant ces détails sont repoussés à après la construction proprement dite.
Bien sûr, on peut améliorer le process et réfléchir à mieux exploiter cette nouvelle méthode, mais est-ce mieux qu’avant ? Pas sûr.
Elle est en déclin.
Désormais, les gens du backend font aussi du frontend.
C’est ça, l’erreur.
Vous allez inspecter l’assembleur produit par un compilateur ? Non.
Alors pourquoi regarder ce code ?
Nous avons simplement remonté le niveau d’abstraction.
J’utilise moi aussi souvent la même approche
Même avant l’IA, je faisais déjà ça manuellement
D’abord, je m’asseyais avec l’utilisateur, juste avec un stylo et du papier, puis je construisais rapidement un POC ou une démo frontend, je le laissais manipuler, puis j’ajustais jusqu’à ce que ça fonctionne comme il le souhaitait
Pour moi, il a souvent déjà été plus rapide de coder une démo frontend rapide, sans qualité de production, que de créer des interactions précises dans Figma
Comme l’interaction était entièrement possible, cela permettait de repérer bien plus de cas limites côté expérience utilisateur
Maintenant, grâce à Claude Code, il est plus rapide de créer des prototypes jetables, mais la différence n’est pas énorme
Comme 80 % du temps total consiste à discuter avec l’utilisateur et à réfléchir à la manière dont cela doit fonctionner, Claude revient surtout à réduire de moitié les 20 % restants par rapport au fait de le construire soi-même rapidement
La première version est plus rapide, mais les itérations sont plus lentes quand on n’a pas tout à fait compris
Edwin, ça fait plaisir de voir que tu as publié ce billet
Je me souviens qu’on avait fait un hackathon ensemble vers 2012/2013
La capacité à arriver plus vite à un prototype fonctionnel est extrêmement puissante, même s’il existe la tentation de déployer tel quel des idées inabouties
Les exigences de design et d’expérience utilisateur gagnent énormément quand on peut dépasser les storyboards et wireframes pour toucher et vivre le flux réel