Je conçois désormais davantage avec Claude qu’avec Figma

• Le workflow de design est en train de passer d’un modèle fondé sur des documents de spécification, des maquettes Figma et des revues d’implémentation à un flux où l’on crée des fonctionnalités prototypes qui tournent dans la vraie base de code
• Copilot, Cursor et Gemini se sont montrés décevants sur des tâches où j’étais déjà à l’aise — modifier un jeu, rédiger un brief produit, produire des wireframes — mais dans un environnement à apprendre comme OCaml et Bonsai, l’assistance de l’IA est devenue indispensable
• Le processus est centré sur l’implémentation réelle : transmettre le problème et la proposition sous forme de prompt, faire implémenter les fonctions de base, itérer, déployer dans l’environnement de développement, recueillir les retours utilisateurs, puis soumettre une feature
• Un prototype combinant du prompting LLM avec une saisie JSQL m’a conduit à affiner à de nombreuses reprises les boutons, raccourcis clavier, libellés, prompts et messages de confirmation, en concentrant l’effort sur le résultat réel plutôt que sur des composants Figma ou de la mise en forme documentaire
• Les designers peuvent désormais transformer directement leurs idées en formes utilisables, mais des prototypes qui ressemblent à des fonctionnalités terminées posent aussi de nouveaux défis pour la participation aux revues et l’exploration créative

---

Du scepticisme envers les LLM à un outil de support indispensable

• Pendant longtemps, j’ai été déçu presque à chaque fois que j’utilisais un LLM, avec l’impression que sur les tâches que je maîtrisais bien, le résultat était moins bon que si je les faisais moi-même
• L’an dernier, j’ai utilisé Copilot et Cursor pour modifier un jeu que j’avais créé, mais aucun des deux n’a réussi à produire des changements fonctionnels ; dans mon précédent emploi, j’ai aussi essayé Gemini pour générer un plan de brief produit et des wireframes, mais tout a fini à la poubelle
• Après avoir rejoint Jane Street l’été dernier, j’ai eu énormément de nouvelles choses à apprendre, et avec des technologies encore peu familières comme OCaml et Bonsai, l’assistance de l’IA a pris un rôle essentiel
• Le grand changement, c’est que l’IA a fini par transformer jusqu’au workflow de design dans lequel j’avais le plus confiance

Des prototypes dans la vraie base de code plutôt que Figma ou des documents

• Au lieu d’écrire une spécification, de produire une maquette Figma, de rédiger une proposition puis de revoir l’implémentation avec des développeurs, je crée une fonctionnalité prototype qui exécute exactement l’idée que j’ai en tête
• En pratique, le flux consiste à écrire une phrase qui décrit le problème et la proposition, puis à lancer dans l’éditeur le build, le serveur et Claude, en utilisant cette description comme prompt
  • Je fais d’abord fonctionner la capacité de base pour vérifier le potentiel, puis j’itère autant que nécessaire
  • Je pousse ensuite les changements dans l’environnement de développement, je demande l’avis des utilisateurs, puis je soumets une feature avec l’apparence et le comportement souhaités
  • Chez Jane Street, une feature correspond au processus qui équivaut à une pull request
• Un prototype fonctionnant dans la vraie base de code offre une expérience meilleure que des maquettes ou des documents sur presque tous les plans
• J’ai récemment réalisé un prototype ajoutant du prompting LLM à une saisie JSQL, qui fonctionnait réellement, et que j’ai testé en l’utilisant moi-même pendant plusieurs jours
  • JSQL est un dialecte SQL interne utilisé dans plusieurs outils destinés aux utilisateurs
  • Claude offre une itération libre et quasi illimitée, sans jamais rechigner devant un 50e changement d’avis ou une petite retouche supplémentaire
  • J’ai ainsi amélioré le bouton Submit, les raccourcis clavier, les libellés, les prompts et même les messages de confirmation générés
• Dans mon entreprise précédente, ce type d’amélioration de workflow aurait nécessité plusieurs jours ou semaines d’allers-retours entre design et ingénierie, ou plus probablement n’aurait tout simplement jamais eu lieu
• L’effort investi dans cette fonctionnalité s’est concentré sur l’amélioration du livrable réel, et non sur des productions intermédiaires comme la création de composants Figma ou l’ajustement de la mise en forme d’un document

Un élargissement rapide du périmètre ces deux derniers mois

• Il a fallu du temps pour arriver à ce mode de travail, et au début après mon arrivée, je n’utilisais l’IA que pour de petites tâches comme corriger de petits irritants UX
• Pour les grandes idées, j’utilisais encore Figma et des documents, et mes tentatives de construire directement avec Claude échouaient
• Au cours des deux derniers mois, les occasions d’ouvrir Figma ont fortement diminué, sous l’effet combiné de meilleurs modèles, d’une meilleure maîtrise des outils et d’un meilleur choix du périmètre
• L’IA a fonctionné non seulement pour les prompts JSQL, mais aussi pour environ six prototypes impliquant des changements côté utilisateur, modèle de données ou bibliothèque
  • Certains prototypes représentaient des diff de plus de 2 000 lignes
  • Je l’ai aussi utilisée pour implémenter un prototype interactif d’une nouvelle application conçue dans Figma
  • Certaines nouvelles applications ont même sauté l’étape Figma pour itérer dès le départ sur le design visuel avec Claude

Redonner du pouvoir aux designers et redéfinir la manière de reviewer

• Quand ils ont une idée, les ingénieurs peuvent produire une preuve de concept fonctionnelle, alors que les designers doivent en général convaincre quelqu’un d’autre de la réaliser à leur place
• Une idée comme « faire du prompting LLM directement dans une saisie JSQL » n’a pas forcément une faisabilité évidente au départ ; confier le prototype à quelqu’un d’autre peut alors faire perdre du temps
• Certaines propositions ne répondent pas clairement aux besoins utilisateurs, et le fait de donner une forme réelle à une idée avec Claude permet aux autres de l’essayer directement et de l’évaluer plus facilement
• L’inconvénient, c’est que les reviewers reçoivent alors quelque chose qui ressemble à une fonctionnalité terminée, et il devient flou de savoir s’ils doivent simplement relire le code ou aussi intervenir sur la fonctionnalité elle-même
• En design, c’est un peu l’équivalent d’un PM qui apporte des wireframes détaillés et demande juste de les rendre beaux : ce n’est pas une forme de revue très agréable
• Une proposition doit être claire et complète, mais elle doit aussi être traitée par les collègues ingénieurs comme une maquette Figma avec laquelle on peut itérer ensemble dans l’espace du design
• Pour l’instant, la solution consiste à ajouter une courte note dans la description de la feature
  • Le prototype est un document de proposition vivant
  • Le code peut être jeté
  • 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, l’implémente dans une feature séparée, s’appuie sur le prototype comme référence, mais reste propriétaire du code de production
• Dans le travail réel, nous continuons à déterminer ce qui est pertinent et ce qui donne de bonnes sensations dans ce nouveau workflow

Les limites de l’itération et le sentiment de revenir à un vrai médium

• Une inquiétude avec le design via Claude est qu’on s’éloigne d’une manière de penser fluide et créative, pour se retrouver enfermé dans des itérations limitées à ce que l’on pense que Claude peut produire
• Quand les changements sont itératifs, comme avec un outil mature, cela fonctionne bien ; mais lorsqu’on crée quelque chose de nouveau, on risque de passer à côté de certaines idées
• Quand j’ai commencé ma carrière professionnelle en 2011, le débat autour de designers should code était très présent, et ses détracteurs soutenaient qu’une fois qu’on se met à programmer, il devient difficile d’apporter de grands changements aux idées
• Comme j’aimais créer des sites web et programmer, j’ai continué à écrire du code ; puis, avec la généralisation de frameworks front-end comme React et la complexification du développement front-end, j’ai choisi la spécialisation
• Mes projets personnels en React m’ont aidé à mieux interagir avec les développeurs, mais au travail, je passais presque tout mon temps dans Figma et les documents
• Si j’avais rejoint Jane Street avant l’arrivée des LLM, je me serais probablement encore davantage enfermé dans Figma ; et contrairement à JavaScript, OCaml et Bonsai m’étaient totalement nouveaux, au point que contribuer techniquement me semblait hors de portée
• Aujourd’hui, je produis à nouveau des résultats réels, je travaille dans ce médium même, et je retrouve la sensation d’avoir plus de liberté pour essayer n’importe quoi

[GN⁺]

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 ? »

  • J’ai déjà vu ça, et c’était construit de bout en bout en vibe coding
    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
  • Il y en a beaucoup trop qui arrivent avec un « c’est presque fini, il ne reste que quelques retouches mineures avant la mise en production »
    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 »
  • Dans le monde de l’ingénierie audio, c’est courant depuis un moment, à mesure que la musique produite en home demo approche d’une qualité professionnelle
    Les gens s’habituent à leur résultat et acceptent de moins en moins les changements apportés par un nouveau mixage professionnel
  • Chez nous aussi, le business apporte des solutions qu’il a imaginées comme s’il s’agissait d’exigences, alors que ce n’est généralement pas ce que veut le client
    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
  • C’est en train d’arriver en ce moment même
    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

  • Il faut le prendre avec un très gros grain de sel
    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é
  • D’après ce que j’ai compris, Jane Street a fortement contribué à OCaml et construit aussi son propre framework web
    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
  • Même s’ils n’étaient pas investisseurs, je ne suis pas sûr de l’importance qu’il faut accorder aux opinions d’une entreprise de trading quantitatif sur le design frontend
  • HN tout entier ressemble désormais à un immense panneau publicitaire pour l’IA
  • Il n’est peut-être pas nécessaire de voir même un billet de blog un peu intéressant écrit par un employé au hasard comme de la guerre psychologique
    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 ?

  • Ici, « gratuit, itérations illimitées, sans s’en soucier » semble surtout vouloir dire que, quand on travaille avec un tiers sur un projet ou avec un designer freelance, le tarif couvre en général « une première version + une révision », puis chaque modification supplémentaire est facturée en plus
    Les petits studios de design fonctionnent souvent pareil, et ce n’est pas toujours une facturation horaire comme pour les développeurs
  • En 2025, le bénéfice net par employé chez Jane Street se comptait en plusieurs millions de dollars, et on parle bien de bénéfice, pas de chiffre d’affaires
  • Il veut probablement dire gratuit au sens de libre de créer sans travail manuel, plus qu’au sens du prix
  • À ce propos, lors d’un entretien avec un CEO, un lead dev et un lead designer, on m’a posé la question banale « quel est ton point faible ? »
    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.

  • Regardez mon site portfolio, il vaut mieux le voir sur desktop.
    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.
  • J’ai eu la même expérience, donc j’ai commencé à tester différents prompts et différentes entrées.
    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.
  • La plupart des applications n’ont pas besoin d’une créativité non conventionnelle.
  • Même chose pour moi.
    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.
  • J’utilise aussi Claude Design.
    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.

  • Après avoir travaillé six ans comme ingénieur full-stack surtout orienté frontend, j’en ai eu assez d’écrire du code à la main et je suis passé au design.
    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.
  • Comprendre les contraintes du médium aide, mais il n’est pas nécessaire de connaître toutes les couches jusqu’au niveau où les électrons se déplacent dans le silicium.
  • Les LLM tendent en général à faire oublier le code, donc j’ai des doutes sur l’intérêt de les utiliser ainsi pour apprendre.
    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.
  • Les designers n’apprennent pas à coder.
    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.
  • Il faut des designers qui ont déjà travaillé étroitement avec des ingénieurs et qui ont un bon jugement.

• 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.

  • Cet article n’a pas été écrit par quelqu’un qui gagne sa vie avec Figma.
    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.

  • Je suis dans une situation similaire.
    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.
  • Pourquoi ne pas demander à Claude Design de rédiger un document spécifiant complètement le prototype ?
  • L’ancienne façon de faire était lourde, les cycles de feedback étaient longs et l’UI était verrouillée par des gatekeepers.
    Elle est en déclin.
    Désormais, les gens du backend font aussi du frontend.
  • Le code n’est plus écrit pour être lu.
    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