Préparer un prototype Figma avant de le tester : la liste à vérifier
Partage par lien, point de départ du flow, noms de frames, écrans reliés et culs-de-sac : cinq réglages Figma qui rendent les résultats d'un test lisibles.
Par Thomas Cescousse, product designer et créateur de DASHUND
Avant de partager un prototype Figma, vérifiez cinq choses : le fichier est partagé par lien en lecture, le flow a un point de départ clair, les frames portent des noms lisibles, chaque écran utile est relié par une interaction, et aucun écran n'est un cul-de-sac involontaire. Sans ces vérifications, les testeurs voient un écran blanc, les parcours s'arrêtent là où vous n'aviez rien prévu, et les chiffres racontent votre fichier plutôt que leur comportement.
Je les vérifie avant chaque test, parce que chacun peut suffire à gâcher des sessions. Voici la méthode, dans l'ordre où je la suis.
1. Le fichier est-il partagé par lien ?
Vos testeurs voient le prototype à travers le lecteur de Figma. Le fichier doit donc être ouvert à toute personne qui a le lien. Dans Figma : Partager, puis « Toute personne ayant le lien » et « peut voir ».
Le piège : ce réglage porte sur le fichier, pas seulement sur le prototype. Rendre public le seul prototype ne suffit pas : Figma demande alors une connexion, ou montre un écran blanc à une personne déjà connectée. Le testeur ferme l'onglet, et vous ne saurez jamais qu'il est venu.
Un mot de passe Figma reste possible, mais vos testeurs verront l'écran de mot de passe de Figma avant le prototype. À réserver aux tests vraiment confidentiels.
Avec DASHUND, tant qu'aucune session n'est arrivée, le partage est vérifié après la publication : si Figma demande une connexion, la vue d'ensemble vous le dit et explique quel réglage changer.
2. Le flow a-t-il un point de départ ?
En mode Prototype, chaque flow commence par un écran de départ. C'est l'écran que tout le monde voit en premier, et c'est aussi celui où l'on revient après un rechargement de la page. Choisissez-le comme un vrai point d'entrée : un accueil, une page produit arrivée depuis une publicité, un premier écran d'onboarding.
Quelques conseils :
- Un flow, une question. Si votre fichier contient l'onboarding et le paiement, créez deux flows et testez-les séparément.
Un flow trop large dilue les parcours.
- Pas d'écran technique au départ. Un écran « sommaire » qui liste toutes les pages, pratique en revue de design, devient
le premier écran de chaque session et fausse le premier clic.
- Restez sous la centaine d'écrans. Au-delà, l'import peut échouer à cause des limites de Figma. Mieux vaut un flow court,
centré sur ce que vous voulez apprendre.
Le plugin DASHUND propose les flows du fichier : sans point de départ, il n'y a rien à publier.
3. Les frames ont-elles des noms lisibles ?
« Frame 1427 » et « Frame 1428 » sont illisibles dans un diagramme de parcours. Renommez vos frames avec ce qu'elles représentent : « Panier », « Paiement », « Confirmation ».
Les noms comptent deux fois :
- Pour lire les résultats. Le Flow, le Sitemap et les heatmaps affichent ces noms. Un nom clair vous fait gagner du temps,
et rend les captures présentables à une équipe.
- Pour comparer deux versions. Quand vous publierez une version 2, Compare appariera les écrans des deux versions par leur
identité Figma, puis par leur nom Figma d'origine. Gardez donc les mêmes noms de frames d'une version à l'autre. Sinon, l'appariement se corrige à la main.
Dans DASHUND, vous pouvez aussi renommer un écran pour l'affichage, sans toucher au fichier. Mais le plus simple reste de bien nommer dans Figma, à la source.
4. Chaque écran utile est-il relié ?
DASHUND retient l'écran de départ et tous les écrans et overlays qu'on peut atteindre depuis lui par les interactions du prototype. Un écran qui n'est relié à rien n'est pas importé.
Pour le vérifier, parcourez le flow dans le mode présentation de Figma, en cliquant comme un testeur pressé :
- Partez de l'écran de départ.
- Suivez le chemin principal jusqu'au bout.
- Revenez et essayez chaque bouton visible, même secondaire.
- Notez chaque écran que vous n'atteignez pas : il manque une interaction.
L'onglet Sitemap de DASHUND montre ensuite tous les écrans importés, avec les liens prévus dans Figma. Une flèche en pointillés est un lien que personne n'a emprunté ; une flèche grise, un chemin suivi qui n'était pas prévu, comme un retour en arrière.
5. Y a-t-il des culs-de-sac ?
Un cul-de-sac, c'est un écran sans aucune interaction sortante. Certains sont voulus : la confirmation de commande, l'écran « Compte créé ». D'autres sont des oublis : une page « Mentions légales » dessinée mais jamais reliée en retour, une fiche produit sans bouton pour revenir à la liste.
Ils comptent pour deux raisons.
Ils arrêtent les parcours. Un testeur coincé ferme l'onglet, ou utilise la barre de Figma pour revenir en arrière. Ces navigations par la barre de Figma ne sont pas des choix du design : DASHUND les enregistre, mais les exclut du Flow et des parcours cibles. Votre diagramme montrera une sortie là où il y avait en fait un mur.
Ils deviennent des objectifs par défaut. À la publication, DASHUND choisit comme écrans objectifs les écrans sans interaction sortante, c'est-à-dire les fins de parcours probables. Un cul-de-sac oublié peut donc être compté comme une réussite. Un bandeau vous invite à vérifier ces objectifs dans les Réglages du prototype : faites-le à chaque publication.
| Écran sans sortie | Voulu ? | Que faire |
|---|---|---|
| Confirmation de commande | Oui | Le garder comme écran objectif |
| Page d'aide jamais reliée en retour | Non | Ajouter un retour dans Figma, ou le retirer des objectifs |
| Écran de fin avec un bouton « Retour » | Oui, mais il a une sortie | L'ajouter à la main comme objectif |
| Prototype d'une seule page | Pas de fin | Choisir l'objectif à la main, ou s'en passer |
Deux derniers réglages
- L'appareil. Le cadre choisi dans les réglages du prototype Figma (téléphone, tablette, ordinateur) est celui que verront
vos testeurs. Les écrans plus longs que l'appareil défilent normalement.
- La version. À la publication, le plugin crée une version nommée dans l'historique du fichier. C'est elle que voient vos
testeurs, même si vous continuez à modifier le design. Aucun calque n'est touché.
Et ensuite ?
Une fois ces cinq points vérifiés, publiez avec le plugin, puis ouvrez vous-même votre lien DASHUND une fois pour voir ce que verront vos testeurs. Cette session compte comme celle d'un testeur : supprimez-la ensuite depuis l'onglet Sessions. L'aperçu des Réglages, lui, ne collecte jamais.
Le pas à pas complet est dans le guide pour tester un prototype Figma, et chaque réglage est détaillé dans les ressources.
Questions fréquentes
Pourquoi mes testeurs voient-ils un écran blanc ?
Le plus souvent, le fichier Figma n'est pas partagé à « Toute personne ayant le lien » avec « peut voir ». Rendre public le seul prototype ne suffit pas : le réglage porte sur le fichier.
Faut-il renommer toutes les frames ?
Toutes celles du flow testé, oui. Leurs noms apparaissent dans le Flow, le Sitemap et les heatmaps, et servent à apparier les écrans quand vous comparez deux versions.
Un écran non relié est-il importé ?
Non. Seuls l'écran de départ et les écrans et overlays atteignables par les interactions du prototype sont retenus.
Puis-je modifier le design après la publication ?
Oui, dans Figma. Vos testeurs continuent de voir la version publiée. Pour tester la nouvelle version, publiez un nouveau prototype et comparez les deux.