Tester un prototype avec une tâche concrète
Un exemple documentaire détaillé montre comment formuler une tâche neutre et distinguer observation, interprétation et modification suivante.
Un test de prototype nécessite une question à laquelle l’observation des actions permet de répondre. « Le portail vous plaît-il ? » guide peu. Une question plus utile est de savoir si les clients professionnels trouvent les conditions de livraison actuellement approuvées pour leur compte, sans indication du chemin.
L’exemple est entièrement fictif. Tâche, documents et notes ne proviennent pas d’une étude client réellement menée.
Définir le modèle et la réussite avant le test
Le portail contient le document archivé D-11 et la version actuelle approuvée D-12. L’équipe connaît cet état attendu. Réussir signifie trouver la version actuelle et expliquer sa validité avec les informations affichées.
Préparez le prototype pour permettre de suivre réellement ce parcours. Liens et états pertinents doivent permettre de répondre à la question. Un modèle sans ouverture de document fonctionnelle ne peut montrer la réussite complète.
Donner une tâche sans révéler le chemin
Une consigne possible :
Vous préparez une commande. Trouvez les conditions de livraison actuellement approuvées pour votre compte client. Montrez comment vous reconnaissez la version valide.
La tâche donne l’objectif, sans menu ni suite de clics. Choisissez des personnes pour lesquelles ce travail est plausible. Expliquez le test et la nature du modèle. Ne faites pas de démonstration préalable du chemin.
Observez les actions réelles. Notez questions et indices du modérateur. Trouver avec aide diffère d’une réussite autonome.
Séparer observation et explication
Ces entrées sont des exemples inventés d’analyse de notes.
Observation supposée | Interprétation possible | Changement ou vérification suivant |
|---|---|---|
La personne ouvre la première entrée sans vérifier l’approbation | Le statut peut passer inaperçu | Clarifier version et approbation, puis retester |
Le lien documentaire ne répond pas dans le modèle | Le prototype ne permet pas la tâche ici | Ajouter le lien ou modifier explicitement le périmètre |
Le bon document n’est trouvé qu’après un indice | La réussite autonome reste incertaine | Retester le parcours modifié avec une tâche neutre |
« La personne ne comprend pas le portail » serait déjà une interprétation large. Actions concrètes et état exact du modèle sont plus traçables. Un lien non raccordé relève d’abord du dispositif de test, sans prouver une erreur utilisateur.
Déduire l’étape suivante
Décidez quelle incertitude le changement doit lever. Testez ensuite la version revue avec le même objectif, sans donner la solution. Documentez personnes, conditions et parties du modèle examinées.
Un prototype cliquable ne prouve ni droits réels, ni stockage durable, ni performance en production. Une tâche réussie ne remplace pas non plus les contrôles d’accessibilité selon les standards. L’essai peut répondre à des questions précises ; ses limites doivent rester visibles dans la décision.
Sources
Écrit par
- Julia HoffmannRédactrice design et UXJulia Hoffmann est responsable chez ASES des contenus éditoriaux consacrés au design et à l’expérience utilisateur. Ses articles portent sur l’utilisation des sites web et des applications, la conception d’interfaces utilisateur et l’accessibilité numérique.
À lire aussi
Tous les articles
Design & UX avec ASES
Expérience utilisateur, interfaces et image de marque