Tester un prototype Figma sans tâches ni script : pourquoi et comment
Sans consigne, les gens utilisent votre prototype comme un vrai produit. La méthode : un objectif défini, un lien par audience, puis lire parcours et abandons.
Par Thomas Cescousse, product designer et créateur de DASHUND
Tester un prototype Figma sans tâches, c'est partager un lien et laisser les gens l'utiliser comme un vrai produit, sans consigne, sans script et sans questionnaire. On y gagne un comportement plus proche de la réalité : les testeurs cherchent leur propre chemin au lieu de suivre le vôtre. La méthode tient en quatre étapes : définir ce qu'est une session réussie, préparer le prototype pour qu'il tienne seul, le diffuser par des liens séparés, puis lire les parcours et les abandons.
Pourquoi retirer les tâches ?
Une tâche, c'est une phrase du type « Achetez une paire de baskets en taille 42 ». Elle a un avantage : elle concentre le test sur ce que vous voulez vérifier. Elle a aussi un coût, moins visible.
- Elle donne la destination. La personne sait qu'un achat est possible, qu'il y a des tailles, et qu'on attend d'elle
qu'elle aille au bout. Le prototype n'a plus à le lui faire comprendre.
- Elle donne souvent les mots. Si la consigne dit « panier » et que le bouton dit « panier », vous testez la lecture,
pas la navigation.
- Elle change la motivation. Quelqu'un qui a une mission persévère là où un vrai visiteur aurait abandonné. Les
abandons, justement, sont ce que vous cherchez.
Le contraste peut être frappant : avec une consigne, presque tout le monde finit, et on repart rassuré. Sans consigne, on découvre parfois que l'écran d'accueil ne dit pas assez clairement ce que le produit fait, ou qu'une partie du parcours n'est jamais vue.
Retirer les tâches ne veut pas dire tester au hasard. La question change : on ne demande plus « savent-ils faire X ? », mais « que font-ils quand personne ne leur dit quoi faire ? ».
Ce que l'on peut mesurer, et ce que l'on ne peut pas
| Avec des tâches | Sans tâches |
|---|---|
| Réussite d'une consigne précise | Part des sessions qui atteignent l'objectif d'elles-mêmes |
| Temps pour réaliser la tâche | Temps passé, écran par écran, là où les gens s'attardent |
| Réponses à des questions | Aucune question : seulement des comportements |
| Peu de participants, recrutés | Autant de personnes que votre lien en touche |
| Le parcours est guidé | Les parcours réels, y compris ceux que vous n'aviez pas prévus |
La limite est claire : sans tâche ni question, vous voyez quoi et où, pas pourquoi. Si beaucoup de sessions s'arrêtent sur l'écran de livraison, vous savez où regarder ; il faudra peut-être un entretien pour comprendre la raison. Les deux méthodes se complètent. Des outils de test à tâches existent pour vérifier une consigne précise : c'est le bon choix quand la question est « telle fonction est-elle trouvable ? ».
Étape 1 : définir ce qu'est une session réussie
Sans consigne, il faut quand même savoir ce qui compte comme un succès. Choisissez-le avant de diffuser :
- Un écran objectif : la confirmation de commande, l'écran « Compte créé ».
- Plusieurs fins possibles : « Commande payée » ou « Rendez-vous réservé », chacune vaut une réussite.
- Des points de passage : les quatre écrans d'un onboarding, vus dans n'importe quel ordre.
Ce choix ne guide pas les testeurs, qui n'en savent rien. Il sert à vous : c'est lui qui donne le taux de complétion. Dans DASHUND, il se règle dans les Réglages du prototype et peut changer à tout moment, l'historique est alors recalculé.
Étape 2 : préparer un prototype qui tient seul
Un test à tâches pardonne un prototype incomplet, parce que la consigne évite les zones vides. Sans consigne, les gens vont partout. Avant de publier :
- Un point de départ clair. L'écran d'entrée doit dire ce qu'est le produit et ce qu'on peut y faire, sans vous.
- Pas de culs-de-sac involontaires. Un écran sans aucune sortie est une fin de parcours. Si ce n'en est pas une,
ajoutez un retour.
- Des noms de frames lisibles. « Panier », « Livraison », « Paiement » : vous lirez vos résultats avec ces noms.
- Un contenu crédible. De vrais libellés, des prix plausibles. Un « Lorem ipsum » fait sortir les gens du jeu.
Les zones non terminées ne sont pas un problème en soi : les clics dessus vous diront ce que les gens attendaient.
Étape 3 : diffuser par des liens séparés
Comme il n'y a pas de recrutement, la diffusion fait le panel. Un lien par audience permet de séparer les comportements : newsletter, clients existants, post LinkedIn, équipe interne. Par exemple, une audience qui connaît déjà le produit ira souvent plus vite qu'une audience qui le découvre ; mélangées, les deux brouilleraient vos chiffres.
Présentez le lien simplement : « Voici la nouvelle version de notre application, essayez-la. » Évitez de glisser une mission dans le message (« essayez de réserver un créneau ») : vous réintroduiriez la consigne par la porte de derrière.
Avec DASHUND, chaque audience a son lien DASHUND vers le même prototype, et l'onglet Segmentation compare leurs sessions, leur durée médiane, leur complétion et leur rebond. Les testeurs n'ont ni compte à créer ni rien à installer : ils ouvrent le lien sur leur téléphone ou leur ordinateur.
Étape 4 : lire les résultats dans le bon ordre
Sans consigne, les données sont plus riches et plus dispersées. Un ordre de lecture aide :
- La complétion et le rebond. Combien de sessions atteignent l'objectif ? Combien partent sans un seul clic ? Un rebond
élevé parle souvent de l'écran d'entrée.
- Le Flow. Les chemins réels, écran par écran, et l'endroit où les sessions s'arrêtent. Une grosse sortie juste avant
l'objectif mérite d'être regardée en premier.
- Les heatmaps. Sur les écrans où l'on sort, où clique-t-on ? Les clics hors des zones cliquables montrent une attente
que le design ne comble pas.
- Quelques sessions, une par une. Une fois un problème repéré, revoyez trois ou quatre sessions qui l'ont rencontré.
C'est là que l'hypothèse se forme.
Gardez en tête que les premières sessions sont des indices, pas des preuves. DASHUND signale « Échantillon faible » sous 30 sessions ; un blocage net se voit souvent bien avant.
Les pièges d'un test sans tâches
- Tester vous-même avec le lien. Votre session compte comme celle d'un testeur. Utilisez l'aperçu, ou supprimez vos
essais ensuite.
- Conclure sur un parcours que personne n'a vu. Si un écran n'est presque jamais atteint, ce n'est pas qu'il fonctionne :
c'est peut-être qu'on ne le trouve pas.
- Confondre exploration et échec. Quelqu'un qui visite cinq écrans et part n'a pas forcément échoué : il a peut-être eu
ce qu'il cherchait. D'où l'importance de l'étape 1.
- Changer le prototype pendant le test. Un prototype publié doit rester figé, sinon vos chiffres mélangent deux designs.
Une nouvelle version se publie à part et se compare à l'ancienne.
Le guide Tester un prototype Figma avec de vrais utilisateurs reprend la mise en place pas à pas, et la page Fonctionnalités montre chaque vue de DASHUND.
Questions fréquentes
Un test sans tâches remplace-t-il un test utilisateur classique ?
Non. Il montre ce que beaucoup de gens font, à grande échelle. Un entretien ou un test à tâches explique pourquoi, ou vérifie un point précis. Les deux se complètent.
Comment savoir si une session a réussi sans consigne ?
En définissant à l'avance un écran objectif, plusieurs fins possibles ou des points de passage. Le taux de complétion se calcule sur ce choix, sans que les testeurs le connaissent.
Que dire aux testeurs en partageant le lien ?
Présentez le produit, pas une mission : « Voici la nouvelle version, essayez-la. » Une phrase qui suggère une action précise redevient une tâche.
Combien de sessions faut-il pour un test sans tâches ?
Quelques sessions suffisent pour repérer un blocage évident. Pour comparer deux versions ou deux audiences, visez au moins 30 sessions de chaque côté.
Le prototype doit-il être terminé ?
Non, mais il doit tenir seul : un point de départ clair, pas de cul-de-sac involontaire. Les clics sur les zones non terminées sont même instructifs : ils montrent ce que les gens attendaient.