Tester un prototype Figma : trois tâches avant le développement

Pour tester un prototype, préparez quelques tâches précises et observez comment une personne cherche à les accomplir. Ne lui donnez pas la suite de clics attendue. Le but est de repérer une incompréhension du parcours, tout en distinguant ce que la simulation permet réellement de vérifier.

Délimiter ce que le prototype représente

Listez les écrans connectés, les actions simulées et les parties volontairement absentes. La documentation de prototypage Figma décrit les possibilités d'enchaînement et d'interaction. Leur présence dans une maquette ne prouve pas le fonctionnement de données réelles ou d'un serveur.

Vérifiez le lien de partage dans les conditions de la personne qui participera. Un accès qui fonctionne dans votre session de concepteur peut demander des droits supplémentaires ailleurs. N'utilisez pas de données personnelles réelles pour remplir les écrans de démonstration.

Formuler trois tâches observables

Choisissez un objectif principal, une recherche d'information et un retour après erreur. Par exemple : trouver un atelier adapté, vérifier les conditions d'annulation et corriger une date choisie. Pour chaque tâche, définissez le résultat attendu sans nommer le bouton à utiliser.

Le guide GOV.UK sur les tests modérés présente l'observation de tâches avec des participants. Dans votre journal, distinguez les actions vues, les propos recueillis et vos interprétations. Demandez l'accord nécessaire avant tout enregistrement et gardez les données recueillies proportionnées à l'objectif.

Exemple fictif : changer une date choisie

Imaginons un prototype de réservation dans lequel le récapitulatif affiche une date et un petit lien « Modifier ». La tâche consiste à changer cette date avant confirmation. Observez si la personne trouve l'action et comprend qu'elle conserve les autres choix.

Si elle retourne au début du parcours, notez la séquence sans lui attribuer une intention non exprimée. L'hypothèse pourrait être un lien trop discret ou un libellé ambigu. Préparez une modification limitée, puis rejouez la tâche avec un contexte comparable.

Ce cas fictif n'est pas un test utilisateur réalisé par la rédaction. Il fournit un scénario à adapter et un exemple de distinction entre observation et hypothèse.

Transformer les observations en décisions

Regroupez les problèmes selon leur effet sur la tâche. Distinguez un obstacle de compréhension d'un bouton volontairement non connecté dans le prototype. Si la simulation est trop incomplète pour répondre à la question, complétez-la ou réduisez le périmètre avant de conclure.

Réintégrez les décisions dans la préparation des maquettes de refonte. Conservez les éléments qui fonctionnent et reliez les nouveaux constats à l'audit UX du site existant lorsque les deux portent sur le même parcours.

La dernière étape est une liste de contrôles à reprendre sur le site développé : commandes, erreurs réelles, focus, annonces, chargement et conservation des données. Un prototype compréhensible ne valide pas ces comportements techniques à l'avance.

Questions fréquentes

Faut-il demander si la personne aime le design ?

Cette opinion peut compléter l'échange, mais elle ne remplace pas l'observation d'une tâche. Une interface appréciée visuellement peut rester difficile à utiliser pour un objectif précis.

Peut-on mesurer la performance web dans un prototype Figma ?

Il ne s'agit pas du code de votre futur site. Un délai observé dans l'outil ne doit pas être présenté comme la performance de l'application qui sera développée.

Doit-on corriger toutes les remarques reçues ?

Analysez leur lien avec la tâche et les observations disponibles. Une préférence individuelle n'a pas le même poids qu'un blocage reproductible. Notez les décisions et les raisons de leur priorité.