Pour commencer, le point de départ pour avoir fait du prototypage produit avec Claude, c’était le cas de test utilisateur à réaliser avec des métiers sur un projet qui était très complet. On avait une partie front usager, mais on avait aussi la partie back pour les administrateurs. Le tout s’enveloppait dans un seul et même produit. Et on avait du coup plusieurs types de profils qui allaient réaliser ces tests.
On était aussi limités dans le temps, donc on allait leur faire tester que des bribes du parcours. On s’est donc posé la question si ça ne valait pas le coup de profiter du prototypage IA pour aller plus loin sur les prototypes qu’on avait l’habitude de proposer, pour pouvoir permettre aux utilisateurs d’être vraiment le plus libre possible pendant le test et de leur permettre de naviguer plus librement dans le produit, pour voir un petit peu naturellement quelles allaient être leurs interactions.
Ce qu’on faisait avant
Avant de tester le prototypage IA, on prototypait assez classiquement dans Figma, avec la création d’abord de nos scénarios de test. Et par rapport à ces scénarios de test, on allait prototyper uniquement les écrans qui étaient nécessaires à la réalisation de ces scénarios. Donc on se limitait vraiment à prototyper uniquement ce qu’on avait dans notre scénario et on laissait de côté tous les autres écrans.
Un premier test qui explose les tokens
On a commencé par faire plusieurs tests. Le premier test, ça a été tout simplement de donner à Claude tout notre fichier Figma, avec tous les écrans qui étaient posés et associés à chacun des scénarios. On lui demande de nous créer un prototype en artefact Claude. Et bien sûr, ça n’a pas trop fonctionné… En fait, ça a pris énormément de tokens. Ça nous a fait exploser notre limite de tokens sans voir aucun résultat. Donc on n’avait pas du tout la vue sur ce qu’il était en train de faire, s’il réussissait ou pas.
On trouve la meilleure approche : écran par écran
Au final, on a changé de technique et on est parti davantage sur la création du prototype écran par écran. C’est-à-dire qu’on lui donnait le lien vers l’écran Figma de démarrage. On le laissait ensuite recréer l’écran sans parler d’interaction. Notre objectif était de laisser Claude recréer l’écran en s’assurant que ce soit le plus pixel perfect possible, donc avec quelques allers-retours parfois pour bien s’assurer qu’il respecte nos espacements, qu’il respecte aussi le responsive, etc. Puis, quand le résultat nous satisfait, on passe à l’écran suivant et on s’assure que les différents liens entre les deux pages fonctionnent bien.
Plus on avançait dans le processus, moins on avait d’allers-retours à faire sur la création des écrans, puisqu’il gardait en mémoire les retours faits au fur et à mesure pour s’assurer d’avoir des écrans les plus pixel perfect possibles par rapport à nos maquettes dans Figma. Ce travail a finalement été assez rapide. C’était de plus en plus rapide au fur et à mesure qu’on intégrait des écrans.
Lorsqu’il y a des retours plus génériques, par exemple l’ajout de notifications toast à la fin d’un parcours, on a pu facilement lui dire d’appliquer cette logique de notification toast à tous les endroits où ça semblait être pertinent. Et donc en un seul prompt, on avait rajouté des notifications pour sept scénarios différents. Mais il gardait la logique de contextualisation. C’est ça qui est très intéressant, c’est le fait qu’il est en capacité de contextualiser, de lire le contenu des écrans pour être toujours très contextuel.
Ensuite, il y a eu évidemment de la vérification humaine, puisqu’il y avait des éléments qui n’étaient pas forcément présents dans notre Figma. Donc il lisait bien les annotations dans Figma, mais certains éléments n’étaient pas précisés, comme par exemple ce qu’on pouvait retrouver sous un drop-down, ou alors les filtres disponibles dans un menu filtre. Claude avait contextualisé, mais une petite passe humaine était quand même nécessaire pour s’assurer qu’il n’y avait pas d’erreur, notamment dans ce qu’il avait interprété.
Ce qui est aussi assez intéressant, c’est que pendant la création de ce prototype, il y a aussi eu du remaniement des maquettes. Quand c’était le cas, on a pu dire à Claude que tel ou tel écran avait été modifié. Il a ensuite été corrigé en conséquence dans sa version du prototype avec les nouveaux écrans.
Les bonnes pratiques
Ce qui est important, au final, c’est de bien cadrer la session de travail au début, c’est-à-dire de lui indiquer les dimensions sur lesquelles on va vouloir travailler. Également, si on souhaite du responsive, lui donner les indications sur les limites du responsive. Par exemple, on avait des tableaux. Et donc, dans ce tableau, le responsive n’était pas idéal dans la première version qui avait été choisie par Claude. Il était donc important de lui donner des indications sur quelles lignes du tableau devenaient responsives. Et au contraire, celles qui ne devaient pas le devenir, ou en tout cas, devaient être fixées à une taille maximale ou minimale.
Ce qui a aussi été important dans le processus, plus que de faire de l’écran par écran (car le multi-écran ne fonctionnait pas si mal), c’était le test des skills intégrés au MCP Figma. Le skill d’un collègue avait cramé tous nos tokens pour un résultat moyen, en un temps relativement très long et 1,5 milliard de tokens, contre le dernier test qu’on a fini par faire, qui a pris quelques minutes et divisé par 1000 le nombre de tokens. Et de tester les modèles, le plus gourmand n’étant pas forcément le plus efficace selon les tâches à faire.
Les retours des testeurs
Finalement, par rapport au test, ce qui est ressorti, c’était tout d’abord une liberté pour les utilisateurs. Ils n’ont pas du tout été contraints, puisque l’ensemble du prototype était fonctionnel. Ils avaient la possibilité de taper du texte, de faire du filtrage, de cliquer sur l’intégralité des boutons. Donc en fait, ça a créé une expérience très intuitive. Et ça a permis aux utilisateurs d’aller même au-delà de ce que nous attendions.
Il y avait des retours et des critiques qui étaient beaucoup plus spontanés, et sans a priori.
En revanche, étant donné que c’était un artefact Claude, on a quand même eu le retour par rapport au fait qu’on avait un message d’alerte qui était annoncé au tout début. Donc c’était important de bien préciser le fait qu’un outil d’IA avait été utilisé uniquement pour la création du prototype, mais pas pour le travail de maquettage. Et que finalement, le fond avait vraiment été pensé et créé par des humains. Et que c’était seulement la solution, on va dire, technique du prototype dynamique qui, elle, avait été assistée par IA.
Une économie de temps non négligeable
Le prototypage via IA nous a permis de faire plus dans le même ordre de temps que ça nous aurait pris en faisant uniquement nos sept scénarios simples. Là, finalement, on a pu, dans le même temps, réaliser le prototype complet, c’est-à-dire rajouter une quinzaine d’écrans et également s’assurer du côté vraiment dynamique de l’ensemble des composants. Ce qui nous aurait demandé facilement une à deux journées de travail complémentaires en phase UX, puisque tous les états des composants n’étaient pas forcément réalisés, comme par exemple le contenu de toutes les drop-downs, le fait de pouvoir avoir du filtrage dynamique, etc. Ce genre de choses prend beaucoup plus de temps. Et là, grâce à l’IA, on a pu avoir ces résultats-là extrêmement rapidement.
Au total, en mettant de côté notre première approche qui fut un échec, on a mis une journée pour réaliser le prototype complet, alors que ce même temps nous aurait permis uniquement de réaliser sept scénarios, mais avec une approche beaucoup plus superficielle, sans ajouter le filtrage dynamique, la possibilité de taper du texte dans les barres de recherche, etc.
Ce qu’on retient
On s’est rendu compte, par rapport à nos premières approches et par rapport au résultat final, que la meilleure façon de réaliser un prototype dynamique, c’était bien évidemment déjà d’avoir des écrans et des parcours qui étaient bien fixes au départ. On peut évidemment demander à l’IA de nous rajouter quelques petits écrans simples, comme des modales de validation, etc. Mais le fait que le travail a été rapide, c’était également parce que nos écrans étaient déjà maquettés, bien nommés, avec une bonne logique de parcours entre eux, et on savait aussi la manière dont un utilisateur allait devoir naviguer dans ces écrans. Donc on ne partait pas de zéro.
En revanche, on a besoin de guider Claude pas à pas pour que lui aussi il comprenne cette logique de parcours. Et c’est du coup une mauvaise chose de le laisser se débrouiller tout seul en lui donnant uniquement tous les écrans, parce que sans être guidé, il peut facilement faire des erreurs ou en tout cas prendre beaucoup plus de temps pour comprendre les parcours et pour comprendre la logique d’interaction entre les écrans.
On a l’intention de continuer à réaliser des tests pour voir si on est en capacité de gagner encore plus de temps pour obtenir un résultat fiable, pixel perfect par rapport à nos maquettes, et en réduisant constamment le temps nécessaire. Mais on a aussi comme réflexion le fait de se demander justement si la création de ces prototypes dynamiques, bien plus rapide, ne nous permettrait pas d’aller beaucoup plus loin, voire même de penser des interactions plus travaillées avec de la micro-animation, etc., qui pourraient peut-être servir aussi la passation aux équipes de développement.
On s’est aussi rendu compte que ce prototype très poussé a été un plus pour le partage des écrans à l’équipe projet. Les parties prenantes ont adhéré plus facilement aux maquettes, puisque très rapidement, elles pouvaient se rendre compte des interactions, se rendre compte de la réalité du produit, et donc aussi le tester de leur côté en intégralité. Ça avait plus de poids que des écrans mis côte à côte dans un Figma ou dans un fichier PDF.
