Évaluer les formulaires sur une tâche complète
Un comparatif fictif montre les questions ouvertes après validation du design : correction, conservation des saisies et réception confirmée.
Un formulaire peut paraître compréhensible lors d’une revue de design et créer du travail supplémentaire pendant la correction d’une saisie. La validation doit donc préciser quelle partie du parcours a réellement été évaluée et quelles questions restent ouvertes.
Même demande, parcours différents
Le tableau décrit les comportements supposés de deux formulaires de projet fictifs. Leurs vues initiales semblent aussi bien organisées. Tous deux indiquent le téléphone comme facultatif ; la personne souhaite déposer une demande permettant des questions par e-mail.
Cas vérifié | Version A | Version B |
|---|---|---|
Champ de téléphone laissé vide | Traité malgré tout comme obligatoire à l’envoi. | Reste facultatif. |
E-mail incomplet | Simple cadre rouge, sans aide à la correction. | Message compréhensible permettant de rejoindre le champ. |
E-mail corrigé | L’objectif du projet déjà saisi disparaît. | L’objectif reste présent. |
Transmission non confirmée | Succès affiché immédiatement après le clic. | Réception indiquée comme encore non confirmée. |
Une discussion limitée à la vue initiale ne révèle pas ces différences. Apparence et comportement pendant la tâche doivent donc être examinés ensemble. W3C WAI traite explicitement les retours près des champs et sur le résultat de l’envoi comme des éléments du parcours.
Distinguer observation et contrôle fonctionnel
GOV.UK décrit les tests d’usage avec des tâches concrètes et des consignes claires et neutres. Ici, le but pourrait être : « Déposez une demande de projet permettant à l’équipe de vous contacter par e-mail. » On observe si la personne atteint le but, où elle hésite et quelle aide lui est nécessaire. La consigne ne révèle pas quel bouton choisir ensuite.
Un contrôle fonctionnel préparé vise en complément une saisie incomplète et une confirmation serveur absente. Il peut montrer si les valeurs restent présentes. Un cas d’erreur joué techniquement ne constitue pas encore une observation d’utilisateurs réels. Ces constats répondent à des questions différentes.
Ce qu’une validation précoce du design peut établir
Une maquette visuelle aide à évaluer tôt le texte, la hiérarchie de l’information et la proximité des aides. Si les parcours ne sont pas développés, un prototype cliquable peut rendre les corrections compréhensibles. L’acceptation serveur doit alors être signalée comme un état supposé.
Pour une validation ultérieure, le parcours complet jusqu’à la réception confirmée devient important, avec les cas d’erreur convenus. Une note claire nomme donc la tâche vérifiée, le dernier état confirmé et les points ouverts.
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