Mesurer les gains de temps grâce à Figma Make

Les outils d'IA tels que Figma Make ont raccourci les cycles de conception, en gérant le travail répétitif et mécanique qui ralentit les équipes afin qu'elles puissent se concentrer sur le travail qui compte le plus. Pourtant, de nombreuses équipes ne savent pas vraiment combien de temps elles économisent, ni où elles réalisent les plus grands gains en efficacité. L'équipe de science des données de Figma a entrepris de trouver les réponses, mais les méthodes de recherche courantes telles que les tests A/B et l'inférence causale ne pouvaient pas tenir compte de toutes les complexités de l'IA.

Nous avons donc conçu un essai contrôlé randomisé dans lequel nous avons demandé à 100 participants d'effectuer des tâches avec et sans Figma Make. Nous présentons ici plus de détails sur la conception de l'étude et sur les résultats obtenus.

Contrôler les facteurs de confusion

Mesurer le gain de temps lié à l'utilisation de l'IA est délicat en raison de facteurs de confusion : d'autres variables qui influencent également la durée d'exécution d'une tâche. L'ancienneté dans l'emploi, l'expérience professionnelle et la complexité des tâches en sont autant d'exemples. Chacun peut influencer la rapidité à laquelle une personne travaille, indépendamment de l'IA. La plupart des méthodes statistiques courantes ne peuvent pas prendre en compte de tels facteurs de confusion. Ainsi, sans les prendre en compte, nous ne pouvons pas déterminer dans quelle mesure un changement de productivité est réellement dû à l'IA par rapport aux autres facteurs en jeu.

Défis liés aux méthodes courantes

Lorsqu'il s'agit de facteurs de confusion, deux méthodes courantes en science des données (les tests A/B en ligne et l'inférence causale sur les journaux de données) présentent des limites.

Imaginez que nous mettions Figma Make à la disposition d'un groupe test d'utilisateurs et que nous le désactivions pour un autre groupe. Nous mesurons ensuite le temps qu'il faut au groupe A pour accomplir des tâches de conception par rapport au groupe B. Toutefois, bien que cette méthode permette théoriquement de neutraliser les facteurs de confusion, le problème majeur est que nous ne pouvons pas contrôler les tâches spécifiques effectuées par chaque utilisateur pour garantir qu'elles présentent un niveau de complexité équivalent.

Dans un autre scénario, imaginez que nous souhaitions examiner les données de journalisation pour déterminer combien de temps les utilisateurs consacrent en moyenne aux tâches de conception lorsqu'ils utilisent des fonctionnalités d'IA, par rapport aux moments où ils ne les utilisent pas. Nous pourrions utiliser plusieurs méthodes d'inférence causale pour essayer de déterminer dans quelle mesure l'utilisation de l'IA a influencé le résultat, tout en contrôlant les facteurs de confusion. Mais aucune ne convient véritablement à nos besoins.

L'appariement par score de propension (PSM) est une méthode permettant d'estimer des effets causaux à partir de données observationnelles. Pour chaque point de données (dans notre cas, chaque tâche de conception figurant dans les journaux), vous estimez le « score de propension » : la probabilité qu'il ait appartenu à l'expérience de traitement (dans notre cas, l'utilisation de l'IA), compte tenu de ses caractéristiques observées. Toutefois, cela suppose que tous les facteurs de confusion soient inclus dans les données des journaux. Or, ce n'est pas le cas pour nous ; par exemple, les identifiants d'utilisateurs anonymisés ne nous renseignent en rien sur l'expérience subjective de conception de la personne.

La méthode des variables instrumentales (VI) est une technique d'estimation des effets causaux lorsqu'un facteur de confusion ne peut être ni directement mesuré ni contrôlé. Pour l'utiliser, il nous faut identifier dans les données une nouvelle variable – un « instrument » – qui influence le recours à l'IA. Cet instrument ne peut pas affecter la vitesse d'exécution de la tâche d'une autre manière et doit être indépendant des facteurs de confusion. Si ces deux conditions sont remplies, nous pouvons utiliser l'instrument pour isoler une fraction de l'utilisation de l'IA/de la non-IA qui est essentiellement aléatoire par rapport aux facteurs de confusion. Le problème est qu'il n'existe pas d'instrument valide pour nous : rien, dans les données de journalisation, n'incite à utiliser les fonctionnalités d'IA pour des raisons étrangères à l'expérience de conception ou à la tâche elle-même.

Choisir de mener un essai contrôlé randomisé

Les essais contrôlés randomisés (ECR) constituent la référence en matière de mesure valide de l'impact causal, et c'est l'approche que nous avons retenue pour cette étude. Ces essais permettent de contrôler pleinement les facteurs de confusion au début de la collecte des données en combinant l'assignation aléatoire, la conception standardisée des tâches et la modération de l'essai :

• La répartition aléatoire des participants entre le groupe de traitement et le groupe témoin garantit que les facteurs de confusion sont répartis de manière approximativement égale entre les deux groupes.
• Faire en sorte que les participants effectuent les mêmes tâches élimine l'incidence des différentes caractéristiques des tâches sur notre variable de résultat, à savoir le temps d'exécution.
• La modération des essais par une équipe de recherche formée réduit la variabilité supplémentaire dans les travaux réalisés après la répartition en groupes et protège contre d'autres violations statistiques potentielles.

Nous avons collaboré avec des chercheurs en expérience utilisateur, au sein de Figma et en dehors, pour concevoir et mener un essai contrôlé randomisé visant à déterminer le temps que Figma Make permet aux designers produit et aux product managers de gagner dans leurs tâches de conception quotidiennes.

Nous avons choisi Make en raison de sa popularité auprès des utilisateurs de Figma et de son large éventail d'applications. Plus les participants pouvaient utiliser d'outils d'IA dans le cadre de l'étude, plus nous introduisions de variables susceptibles de contribuer au gain de temps ; nous avons donc souhaité limiter l'étude à un seul outil.

Nous savions que nous mesurerions le gain de temps pour les designers produits – utilisateurs intensifs de Make, mais nous étions également curieux de savoir si les product managers gagnaient eux aussi du temps. Grâce aux études utilisateurs, nous savions déjà que Make avait ouvert la voie du design aux PM, et nous souhaitions mieux comprendre leur expérience.

Concevoir l'expérience

La conception fondamentale de l'expérience consistait à faire réaliser les mêmes tâches de conception aux participants des groupes expérimental et témoin. La seule différence entre les groupes était que le groupe expérimental aurait accès à Make, tandis que le groupe témoin n'aurait accès à aucun outil d'IA.

Lors de la conception des tâches à accomplir par les participants, notre première considération a été la familiarité. Nos tâches devaient être largement comprises par tous les participants, quelle que soit leur expérience réelle en conception. Nous avons fini par nous concentrer sur la modification des publications pour les réseaux sociaux.

Nous souhaitions tester un éventail de workflows de conception courants dans le cadre de cette étude afin d'obtenir de multiples indicateurs sur l'impact de Make à travers diverses tâches de conception, ce qui nous permettrait d'aboutir à une mesure cumulative plus robuste du gain de temps. Nous avons identifié les thèmes suivants comme étant des workflows de conception clés à tester : modification de l'interface utilisateur et de l'apparence, création de nouvelles vues à partir d'un design de base et ajout d'interactivité et de réactivité ; au total, nous avons élaboré trois scénarios.

Enfin, et c’était là le défi le plus ardu, nos exercices d’étude devaient se situer dans la « zone idéale » : ni trop faciles pour les designers produits, ni trop difficiles pour les product managers. Nous avons mené des projets pilotes en interne avec des designers Figma et des product managers pour tester nos tâches auprès de participants réels. Nous avons appris ce qui fonctionnait et ce qui ne fonctionnait pas dans nos scénarios, et nous avons remanié les tâches elles-mêmes à trois reprises avant d'aboutir à leurs versions finales.

Modérer l'étude

Notre prochain défi : nous devions former une équipe de modérateurs à la conduite de l'étude auprès de 100 participants. Les différences dans la modération risquant de constituer un autre facteur de confusion, nous avons élaboré un script que tous les modérateurs ont suivi pour guider les participants à travers le déroulement de l'étude selon une procédure standardisée.

Cependant, nos modérateurs avaient tous des niveaux de maîtrise de Figma différents, ce qui signifiait que le niveau d'accompagnement qu'ils pouvaient offrir aux participants bloqués en cours d'étude variait. Nous avons rédigé un guide de dépannage que les modérateurs pouvaient consulter pour aider les participants, et nous l'avons révisé au fil de l'étude à mesure que de nouveaux problèmes survenaient.

Le résultat ?

L'identification des participants, la conception de l'expérience et la préparation de la modération ont mis au jour des complexités dont la résolution a nécessité de multiples itérations de la part de l'équipe. Mais malgré ces défis, les 100 participants ont réussi à terminer l'étude avec succès. Nous sommes parvenus à ces conclusions clés :

• Dans l'ensemble, les participants ont constaté une réduction de 20 % du temps cumulé pour accomplir les tâches, une amélioration de 16 % de la facilité d'exécution des tâches et une amélioration de 15 % de la convivialité perçue de Figma.
• Les product managers ont fait état de gains systématiquement plus importants que les designers produit sur l'ensemble des dimensions évaluées. Selon notre modèle de régression des interactions, le gain de temps pour les product managers disposant d'un accès à Make a été de 23 % en cumulé sur l'ensemble des tâches de l'étude. Au final, dans le cadre de l'expérience, un product manager utilisant Make s'est révélé presque aussi efficace qu'un designer produit n'utilisant pas Make.
• La dernière conclusion clé concerne le type de tâche de conception permettant aux designers produit de réaliser des gains de temps par rapport aux product managers. Les product managers ont fait état de gains concernant les deux tâches de l'étude les plus simples et les plus rapides, mais n'ont pas constaté d'améliorations statistiquement significatives pour la tâche la plus complexe et la plus vaste. L'inverse est vrai pour les designers produit : ils ne signalent des améliorations statistiquement significatives du temps d'exécution que pour la tâche la plus complexe, et non pour les deux scénarios plus simples. En d'autres termes, Make permet aux designers de concevoir plus rapidement des interactions complexes et de passer plus vite de l'idée à la première version, tandis qu'il sert davantage d'outil de base aux product managers pour leur permettre d'apporter rapidement des contributions au design.

En raison de la conception de notre étude, nous pouvons affirmer avec certitude que Make entraîne ces améliorations. Cette approche s'est révélée robuste face aux facteurs de confusion et aux autres formes de biais, et nous prévoyons de continuer à recourir aux essais contrôlés randomisés pour répondre aux questions prioritaires concernant les produits.

Nous lançons déjà des projets de recherche supplémentaires qui viendront approfondir ces travaux initiaux. Nous allons mener un essai contrôlé randomisé similaire pour le nouvel agent de conception Figma, en nous intéressant tout particulièrement à la manière dont les capacités d'exécution en parallèle de l'agent peuvent encore accroître le gain de temps. Nous visons également à explorer de nouvelles hypothèses portant sur l'impact de l'IA sur la qualité de la conception, sur la manière dont elle favorise la collaboration multijoueurs, et bien plus encore.

Téléchargez l'étude complète pour en savoir plus sur le gain de temps offert par Figma Make.