Test des boutons OK / Annuler
Connexes: OK/Annuler à gauche/à droite?
J'ai cherché à savoir si OK/Cancel devrait être à gauche ou à droite, et après avoir regardé beaucoup de vues de chaque côté, il semble qu'il y ait de bonnes raisons pour les deux. Je ne veux pas commencer à en parler ici, car cela a déjà été traité en détail dans la question ci-dessus.
Alors que j'essaie de faire de l'UX le meilleur possible, tout ce qui m'importe vraiment, c'est l'utilisateur, et je veux placer les boutons où j'en ai besoin pour qu'il soit aussi utilisable que possible. Dans cet esprit, je voudrais effectuer des tests UX.
Quels types de tests faut-il effectuer? Dois-je effacer les boutons et faire un sondage sur quel bouton devrait être lequel? Dois-je supprimer la coloration rouge/vert et demander aux utilisateurs d'effectuer les tâches à la hâte et voir ce qui génère le plus d'erreurs?
Je suis ouvert aux suggestions sur la meilleure façon de tester cela et j'espère que les résultats pourront nous aider tous!
Ne faites pas de sondage. Ce que les gens disent aimer ne correspond pas toujours à ce qu'ils font. Si vous allez adopter l'approche du bouton vierge, placez les utilisateurs dans une situation où ils doivent cliquer sur OK (et dans une autre situation où ils doivent cliquer sur Annuler) et les forcer à deviner lequel cliquer.
Il est probablement préférable d'avoir une interface utilisateur plus réaliste avec les étiquettes. Cependant, je ne compterais pas uniquement sur la mesure des taux d'erreur. La vérité est les utilisateurs cliquent très rarement sur le mauvais bouton dans une boîte de dialogue d'une application de bureau, quel que soit le bouton gauche et droit. C’est une raison pour laquelle le débat sur ce sujet n’a pas encore été résolu - dans un sens, il ne surclasse pas de façon flagrante l’autre. En plus de mesurer les taux d'erreur, mesurez également le temps de réponse à la milliseconde. Si les utilisateurs sont le moins confus par la position des boutons, cela apparaîtra comme une légère hésitation. Cela vous évite d'avoir à précipiter vos utilisateurs de manière irréaliste (mais il est normal de fournir une pression réaliste). En outre, la performance efficace de l'utilisateur est son propre avantage en termes d'utilisation, en plus de la précision.
Pour le test, essayez de trouver une tâche où le choix entre OK et Annuler est naturaliste mais vous pouvez dire définitivement quand l'utilisateur a raison ou tort (juste au cas où il y aurait des problèmes de précision). Par exemple, vous pourriez avoir une fonction de vérification orthographique qui passe par un corps de texte et présente séquentiellement via une boîte de dialogue chaque mot qui peut avoir besoin d'être corrigé. De par leur conception, certains mots doivent être corrigés (l'utilisateur doit sélectionner OK) et d'autres non (l'utilisateur doit sélectionner Annuler). Des orthographes correctes et incorrectes devraient être évidentes pour toute personne ayant une bonne formation en anglais afin de minimiser les écarts.
Essayez de recruter des utilisateurs avec différents niveaux de Apple OSX par rapport à une autre expérience de plate-forme, et enregistrez l'expérience de chaque utilisateur avec Apple et d'autres (à quelle fréquence et à quelle fréquence récemment), et utilisez ces informations comme covariables dans votre analyse.
Analysez vos résultats avec des statistiques inférentielles. Si personne dans l'équipe n'est à l'aise pour faire des statistiques inférentielles, demandez à quelqu'un de le faire. Parce que la position du bouton peut ne pas faire beaucoup de différence, sélectionnez une différence de précision et de temps de réponse qui mérite d'être prise en compte et déterminez la taille de l'échantillon dont vous aurez besoin pour détecter de manière fiable cette différence en effectuant une analyse statistique de la puissance en utilisant la variance de quelques pilotes. tester les utilisateurs. Soyez prêt à exécuter de nombreux utilisateurs.
Publiez vos résultats, de préférence dans une revue à comité de lecture. Je pense que nous voudrions tous connaître la réponse.
Devez-vous mettre 'OK' et 'Annuler' sur les boutons?
L'un des problèmes avec OK/Annuler dans les boîtes de dialogue (et de même, mais pire, Oui/Non) est que l'utilisateur doit se référer à la question d'origine pour comprendre ce que les boutons feront réellement. C'est probablement plus un problème que si OK ou Annuler est à gauche ou à droite. Par exemple:
- Voulez-vous vraiment annuler vos modifications? [OK/Annuler]
- Voulez-vous vraiment enregistrer et remplacer ce fichier? [OK/Annuler]
Dans ces exemples, les significations de "OK" et "Annuler" sont plus ou moins opposées l'une à l'autre.
Pire encore, la question négative parfois vue:
- Voulez-vous vraiment ne pas enregistrer vos modifications? [Oui Non]
Une meilleure solution consiste à mais le verbe de l'action qui sera réellement effectuée sur au moins l'un des boutons, sinon les deux. Par exemple:
[Enregistrer/Annuler], [Supprimer/Annuler], [Attribuer/Annuler]
Lorsque la "seconde" option est plus que l'annulation de la première, je serais enclin à étiqueter les deux boutons de cette façon. Par exemple:
- Vous n'avez pas intitulé votre e-mail. Voulez-vous l'envoyer quand même? [Envoyer/continuer l'édition]
Maintenant, les options auront généralement un sens selon leurs propres termes, sans référence à la question d'origine.
Je voudrais effectuer un test utilisateur et voir si l'utilisateur rencontre des problèmes au stade où il travaille avec la boîte de dialogue. Il existe d'autres méthodes de recherche, mais elles peuvent ne pas être fiables.
Demander directement à un utilisateur où il s'attendrait à voir quelque chose est semé d'embûches. Les utilisateurs ne sont généralement pas conscients des décisions qu'ils prennent en parcourant une interface et leurs réponses peuvent être soumises à des préférences culturelles et linguistiques (la réponse "OK/Annuler" semble plus "correcte" dans le texte que "Annuler/OK" car elle est plus courante, et convention typique pour mettre des mots plus longs vers la fin des constructions anglaises).
Les tests A/B peuvent fonctionner, mais seulement si vous savez contre quoi vous mesurez. Les utilisateurs ont-ils cliqué plus sur "Annuler" à droite parce que c'est là qu'ils l'attendaient? Ou s'attendaient-ils vraiment à un bouton "OK" et vous leur avez juste fait perdre leur travail? Vous pouvez suivre le temps jusqu'à l'achèvement (afin que vous puissiez voir des preuves de confusion chez les utilisateurs), mais à cette échelle de conception, les délais impliqués peuvent être légers et voir une variation statistiquement significative nécessiterait de grands échantillons.
En fin de compte, je pense qu'il n'y a pas de véritable substitut à parler avec de vrais utilisateurs dans un environnement de test.
Un bon argument pour placer le bouton "Ok" à droite se trouve à X Movement, pourquoi les boutons ok dans les boîtes de dialogue fonctionnent mieux à droite .