L’essor du « designer de modèle » : le rôle du design est en train de changer dans les produits d’IA

• Fort de plus de 8 ans d’expérience dans la conception de produits IA, Barron Webster occupe chez Figma le tout premier poste de « designer de modèle » au monde, ce qui marque l’émergence d’un nouveau rôle hybride où les designers collaborent directement avec les LLM
• La mission centrale du designer de modèle consiste à compenser les limites des modèles fondamentaux et à introduire de nouveaux outils et de nouvelles façons de penser dans les équipes design pour concevoir des fonctionnalités IA
• Contrairement au design UI traditionnel, la conception de produits IA exige de prototyper d’abord le comportement du modèle avant de concevoir l’interface, faute de quoi on risque de créer une UI qui ne correspond pas au fonctionnement réel
• La mise en place d’un système d’évaluation (evals) est au cœur du contrôle qualité des produits IA, et il faut des outils permettant aux designers de manipuler et d’exécuter des cas d’évaluation dans une boucle de feedback rapide
• À l’ère de l’IA, les designers doivent comprendre en profondeur la structure des entrées et sorties des modèles et avoir une vision d’ensemble du système ; ils ne peuvent plus être de simples créateurs d’UI, mais doivent participer à la prise de décision

---

Présentation de Barron Webster

• Designer fortement impliqué dans les produits IA depuis plus de 8 ans, avec une vraie capacité à prendre du recul sur les cycles de hype
• A participé chez Google Creative Lab à la conception de Teachable Machine, lancé en 2017, premier outil permettant au grand public d’entraîner un modèle d’IA
• A ensuite travaillé sur des fonctionnalités IA chez Replit, contribuant à la croissance de la startup jusqu’au statut de licorne
• A récemment rejoint Figma comme premier designer de modèle au monde

Le rôle du designer de modèle

• Il fait partie de l’équipe de recherche IA de Figma et assume deux missions principales
  • Résoudre les cas où même tirer le maximum des modèles fondamentaux ne suffit pas
  • Comme les données de Figma sont dans un format propriétaire, les modèles fondamentaux les traitent mal ; il travaille donc à combler cet écart
• Il introduit dans l’organisation design de nouveaux outils et une logique AI-first
  • Figma étant une grande entreprise, beaucoup de designers n’ont pas d’expérience dans la conception d’expériences IA
  • Concevoir des fonctionnalités IA est différent du design produit traditionnel
• L’objectif est de construire des outils permettant aux designers de prototyper très tôt l’essence d’une fonctionnalité IA sans devoir devenir ingénieurs
  • Concevoir l’UI d’une fonctionnalité qu’on n’a jamais testée soi-même expose au risque de créer une interface parfaite pour un cas idéal, mais déconnectée du comportement réel

L’avenir des outils de design pour l’IA

• L’outil qu’il attend le plus est celui qui permettra aux designers de manipuler et d’exécuter des cas d’évaluation dans une boucle de feedback rapide
  • Si une fonctionnalité IA ne marche pas sur un fichier Figma, il faut pouvoir l’ajouter immédiatement comme cas de test
  • Il faut aussi pouvoir ajuster le system prompt, essayer un autre modèle, etc., sur-le-champ
• Le problème actuel, c’est que la boucle de feedback est trop lente
  • Le cœur de tout bon outil de design, c’est d’éliminer ou de réduire la boucle de feedback
  • Une grande partie de la construction des jeux d’évaluation reste du travail manuel de nettoyage de données
• Il réfléchit aussi à la manière de différencier les fonctionnalités IA de Figma
  • Puisqu’il s’agit d’une plateforme de design, on s’attend à des sorties mieux conçues que celles de Claude Code ou Cursor
  • Tout repose sur une stratégie d’évaluation ciblée et sur la recherche de bons proxies du “bon design”
  • C’est aussi une question philosophique digne d’une école d’art

Les débuts de Barron dans l’IA

• Cours RISD Computer Utopias en 2014-2015 : avant l’ère des LLM, quand la recherche en machine learning était centrée sur les classifieurs
  • Les modèles de classification d’images étaient les plus fascinants, alimentant des filtres visage de Snapchat ou la recherche d’images Google
  • La modération de contenu et les systèmes de recommandation étaient au centre des discussions
  • C’était l’apogée de Facebook, Twitter et Cambridge Analytica, et l’invention du fil algorithmique créait un nouveau matériau à concevoir
• Google Creative Lab entre 2016 et 2018 : travail sur Google Lens, Google Assistant et Teachable Machine
  • Presque tous les projets appliquaient des innovations côté modèles
  • Les modèles servaient non pas à générer du texte, mais à trier ou annoter du contenu existant
  • Il a notamment promu le cas d’un agriculteur japonais qui classait des concombres avec TensorFlow

L’expérience chez Replit

• Plus de 3 ans chez Replit, avec un démarrage à une époque où il n’y avait pratiquement aucune fonctionnalité IA ; son rôle consistait à évaluer comment les exploiter
• Au fil de l’amélioration des modèles, il a cherché comment ajouter des fonctionnalités IA à la fois nouvelles et fiables
• Le point de départ, c’était des fonctions à déclenchement manuel très simples (sélectionner du code pour demander une explication à l’IA, générer du code dans un fichier existant)
• Après chaque lancement de fonctionnalité, un cycle récurrent de montée des attentes utilisateurs apparaissait
  • Autoriser la génération de snippets de code → les utilisateurs demandent des fichiers ou projets complets
  • Permettre la génération complète → ils demandent des modifications ciblées
  • Permettre des modifications ciblées → ils demandent de tout recommencer depuis zéro
• Schéma récurrent : tenter une fonctionnalité avec les modèles existants, attendre si ça ne marche pas, puis réessayer à la sortie d’un nouveau modèle fondamental
• Contraintes produit dans un environnement de programmation
  • Même si un modèle sait bien écrire du code, il faut encore savoir l’éditer au bon endroit
  • Jusqu’à Sonnet 3.5, les modèles géraient mal les numéros de ligne
  • Il a fallu développer des rustines pour la précision d’édition, éviter les duplications de contenu et remplacer des fonctions
  • Une grande partie de ce travail devenait obsolète 6 à 12 mois plus tard avec l’arrivée de nouveaux modèles

Le basculement vers la validation par l’utilisateur

• Quand l’agent Replit créait automatiquement des fichiers et écrivait du code, tester l’application construite par l’agent est devenu un gros problème technique
  • Exemple : vérifier qu’une page de connexion fonctionne
• L’approche côté ingénierie : lancer un sandbox, construire une fonction de capture d’écran, puis alimenter un modèle multimodal avec les captures pour décider où cliquer ou quoi saisir
  • En substance, il s’agissait de reproduire une forme d’usage de l’ordinateur par le modèle
• La proposition de Barron et d’un autre ingénieur : montrer le site à l’utilisateur et lui demander de le tester lui-même
  • En transférant la validation et le test à l’utilisateur, ils contournaient tout le problème technique
• Avoir quelqu’un qui se concentre non pas sur le problème technique, mais sur le problème utilisateur, permet souvent de sauter des étapes ou de simplifier radicalement

La découverte du product-market fit

• Avant l’IA, la stratégie produit classique consistait à établir un plan, s’appuyer sur une base d’utilisateurs existante, puis étendre le marché ou la catégorie
• Avec la rapidité des changements en IA, la stratégie de Replit est devenue beaucoup plus réactive
• Replit avait un fort product-market fit dans l’éducation, surtout après le Covid et l’enseignement à distance
• Mais l’amélioration des fonctionnalités IA a créé un dilemme
  • Les développeurs indés et les hackers adorent l’IA
  • Les enseignants, eux, y étaient opposés car cela permettait aux élèves de contourner l’apprentissage des bases
• Lors du lancement de l’agent Replit, la cible n’était pas claire
  • Mieux valait souvent lancer une fonctionnalité puis observer les réactions que mener un projet trop top-down
  • Les échanges post-lancement ont permis d’identifier des utilisateurs : des profils ops dans des entreprises tech, ayant besoin de collecter des données commerciales ou de créer des dashboards (proches des utilisateurs de Zapier ou Retool)

Le système d’évaluation (Evals)

• Pendant les deux premières années chez Replit, les évaluations ont été peu utilisées, car la pratique n’était pas encore largement répandue
• Pour l’agent, elles ont été exploitées plus activement, surtout comme métrique de développement produit
  • À la sortie d’un nouveau modèle, on regardait ses performances sur les évaluations de programmation pour décider s’il fallait tester aussi la création d’applications
• Chez Sandbar, beaucoup de temps a été investi dans l’écriture d’évaluations sur la personnalité du modèle
  • Au-delà des benchmarks sectoriels généraux, construire des évaluations propres au produit constitue un nouveau travail de design
• Workflow : écrire un prompt → l’ajuster → créer une évaluation → vérifier la performance → combiner avec des tests manuels et du feedback subjectif
• Sans évaluations, la quantité de travail manuel nécessaire pour vérifier le bon fonctionnement d’une IA augmente fortement
• Exemples d’évaluations chez Sandbar
  • Si le modèle ne connaît pas la réponse, il doit poser une seule question de clarification, précise et concrète, plutôt qu’halluciner
  • Il ne doit jamais poser plus de deux questions à la fois
  • Il doit garder des réponses concises (avec exceptions)

Les difficultés des évaluations

• La flatterie complaisante (sycophancy) est l’un des sujets les plus difficiles dans la rédaction d’évaluations
  • Autrement dit, le modèle doit parfois contredire l’utilisateur quand c’est justifié
  • Déterminer un taux d’échec acceptable devient une décision produit et design, donc une partie de la philosophie du produit
• Quand les résultats d’une évaluation sont mauvais, la cause est souvent une évaluation mal conçue plutôt qu’une baisse réelle de performance
  • Exemple : dans une évaluation exigeant une réponse “très concise”, si l’utilisateur dit « ma mère est décédée », répondre « désolé pour vous » pourrait obtenir un bon score, alors que ce n’est pas la bonne réponse en pratique
• Les évaluations servent surtout à éviter les régressions et à vérifier qu’une propriété est respectée
  • C’est proche de la couverture de tests en programmation
• L’équivalent du test-driven development (TDD) reste encore rare dans l’ingénierie IA
  • Écrire d’abord les évaluations, puis le code qui permet de les réussir
• On peut imaginer à l’avenir un métier de designer d’évaluations
  • Un rôle comparable à celui des design systems, mais pour concevoir des dashboards permettant à l’équipe de comprendre les performances de l’IA

Les idées de fonctionnalités IA chez Figma

• L’idée d’une « critique de design as a service » est à l’étude
  • Demander à l’IA une critique de design
  • Cela soulève des questions intéressantes sur la personnalité du système
• Faut-il proposer des attitudes sélectionnables (par exemple un style « Dieter Rams ») ou définir un comportement par défaut ?
• Faut-il se concentrer sur l’accessibilité ou les problèmes de contraste (feedback plus objectif), ou viser un champ plus large ?
• On ne sait pas encore à quel point cela se retrouvera dans l’expérience produit finale

L’évolution souhaitée des outils d’évaluation

• Il espère des outils qui réduisent le temps d’itération nécessaire pour créer des évaluations
• Aujourd’hui, toutes les personnes qui travaillent sur les évaluations doivent en pratique faire les mêmes choses
  • Relier dans une même interface le mapping, les formats, les pipelines et la visualisation des sorties
• Les outils pour le texte sont déjà assez bons, mais ceux pour d’autres formats restent insuffisants
• Il existe des plateformes proches comme Design Arena
  • Elles proposent des tests en aveugle côte à côte où les gens votent pour la meilleure sortie
• Il aimerait pouvoir faire quelque chose de similaire directement dans un fichier Figma
  • Avec la possibilité de laisser des commentaires et de signaler des problèmes
  • Il faudrait pouvoir générer rapidement un jeu de test, l’exécuter d’un coup, obtenir 100 réponses et itérer en moins de 30 secondes
  • Aujourd’hui, toutes les briques existent, mais cela prend encore trop de temps

Le rôle du designer dans la création des modèles

• Il a connu les deux approches : l’entraînement from scratch et le fine-tuning
• Dans le cas d’un entraînement depuis zéro : la plus grande contribution du designer consiste à faire remonter à l’organisation les endroits où le besoin utilisateur est le plus fort et la douleur la plus vive
  • Chez Replit, il a participé à l’entraînement d’un modèle sur des erreurs de code Python courantes et simples
  • Il s’est davantage impliqué dans la définition du problème et la manière d’intégrer le modèle entraîné au produit que dans l’entraînement lui-même
• Dans le cas du fine-tuning : on dispose déjà d’un modèle, d’un produit et d’évaluations, et on cherche à améliorer les performances
  • Les personnes qui écrivent les prompts, conçoivent les évaluations et parlent aux utilisateurs savent clairement si les attentes sont satisfaites ou non
  • Quand le prompt engineering atteint ses limites, le fine-tuning devient l’étape suivante
• Rôle de traduction essentiel du designer : garder en mémoire les hypothèses côté utilisateur
  • Les ingénieurs et designers qui travaillent de très près avec les modèles peuvent oublier que les utilisateurs n’en connaissent pas les détails
  • Il faut mobiliser son « idiot intérieur » pour expliquer ce qu’un utilisateur naïf, ignorant les spécificités du modèle, va tenter et où il va se bloquer

Conseils aux designers de produits IA

• Le plus durable et le plus impactant est de consacrer d’emblée beaucoup de temps à comprendre réellement les entrées et sorties du modèle
  • Qu’est-ce qu’un prompt ? Quelles informations utilisateur entrent dans le système ? Quels outils le modèle peut-il appeler ? Quelles évaluations existent ?
  • Il faut développer une intuition sur ce qui se passe lorsqu’on règle ces différents paramètres
• Il ne faut pas devenir un simple fabricant d’UI pour des sorties qu’on ne comprend pas en profondeur
  • Si l’on vous dit « le modèle produit ceci, conçois l’interface », vous pouvez le faire, mais vous ne pourrez pas proposer d’améliorations fondées sur une vraie compréhension utilisateur
  • Vous deviendrez aussi très dépendant des évolutions ultérieures du modèle
• Il faut être partie prenante des décisions sur le fait qu’une nouvelle fonctionnalité soit réellement souhaitable, et non simple exécutant
• Cela peut être difficile pour les designers peu à l’aise avec le code
  • Il faut soit disposer d’interfaces comme Langsmith, soit apprendre à exécuter directement l’environnement de développement

Les contributions les plus marquantes

• L’agent Replit : il a convaincu l’équipe de demander directement à l’utilisateur de vérifier si l’application générée fonctionne
  • En se concentrant sur la voie la plus simple de validation utilisateur, cela a permis d’économiser beaucoup d’efforts
• Le lancement de LaMDA (un LLM précoce de Google) : il a passé beaucoup de temps à essayer des modèles de différentes manières pour voir ce qui marchait le mieux
  • À l’époque, on n’appelait pas encore cela du « prompting », mais il s’agissait déjà de pousser le modèle à jouer d’autres rôles de manière fiable
  • Une démo permettant de parler à Pluton ou à ses lunes est née de très nombreux essais pour identifier ce qui fonctionnait le mieux
  • Sans cette expérimentation extensive, aucun choix stratégique n’aurait été possible

Le prompting chez les designers

• La question « les designers doivent-ils prompter ? » n’est pas de même nature que « les designers doivent-ils coder ? »
• Pour le code, la réponse est plus facilement falsifiable : peut-on construire XYZ avec la technologie ABC ? Demander à un ingénieur revient souvent presque à la même chose que le savoir soi-même
• Le comportement d’un modèle d’IA est intrinsèquement plus subjectif et plus subtil
  • Rien ne remplace une compréhension directe et profonde de cette matière

Est-ce encore du design ?

• Oui : il s’agit de concevoir des comportements, qui ne seront peut-être jamais parfaits, et ce n’est pas grave
• Cela demande un état d’esprit différent du design UI, où chaque pixel est totalement contrôlé et où la perfection est récompensée
• Il continue de faire des maquettes et d’utiliser des outils de design
• Chez Figma, il crée des cas d’évaluation, examine les sorties et corrige ce qui semble maladroit
• C’est presque thérapeutique, comme un fidget spinner
  • Donnez-lui une maquette de site web et 30 minutes, et il sera heureux à retoucher la typographie
• Tant que la fonctionnalité n’est pas supprimée, ce type de travail n’est jamais vraiment terminé : il y a toujours quelque chose à améliorer