Comment gérer les utilisateurs qui ne lisent pas les boîtes de dialogue ?

Question

Un article récent sur Ars Technica traite d'une étude récente réalisée par le département de psychologie de l'université d'État de Caroline du Nord, qui montre que les utilisateurs ont tendance à faire tout ce qu'il faut pour se débarrasser d'une boîte de dialogue et revenir à leur tâche. La plupart d'entre eux cliquent sur OK ou oui, minimisent la boîte de dialogue ou la ferment, quel que soit le message affiché. Certaines des boîtes de dialogue affichées étaient réelles, d'autres étaient fausses (comme ces popups affichées par des pages Web se faisant passer pour un avertissement antivirus). Les temps de réponse indiquent que ces utilisateurs ne lisent pas vraiment ces boîtes de dialogue.

Sachant cela, comment cela affecterait-il votre conception, et que feriez-vous pour y remédier (le cas échéant) ?

Answer 1

J'essaie de concevoir des applications qui soient robustes face aux accidents -- qu'il s'agisse de dérapages (opérations involontaires, comme cliquer au mauvais endroit) ou d'erreurs (erreurs cognitives, comme cliquer sur Ok au lieu d'Annuler dans une boîte de dialogue). Voici quelques moyens d'y parvenir :

1. annuler / refaire à l'infini (ou du moins en plusieurs étapes)
2. intégrer la documentation à l'interface, par le biais d'infobulles dynamiques et d'autres moyens de communication sensibles au contexte (Un article particulièrement pertinent concerne Surprendre, expliquer, récompenser". (lien direct : SER ) -- utiliser les réactions psychologiques typiques à un comportement inattendu pour informer les utilisateurs)
3. Incorporer l'état du système dans ladite documentation (utiliser les données de l'utilisateur actuel comme exemples, et rendre la documentation concrète en utilisant des données qu'ils peuvent voir à l'heure actuelle )
4. Attendez-vous à erreur de l'utilisateur. S'il y a un risque que quelqu'un essaie d'écrire sur un:\ alors qu'il n'y a pas de disque en place, mettez en place un délai d'attente pour que le système puisse échouer avec élégance, et demandez un autre emplacement. Sauvegardez les données en mémoire jusqu'à ce qu'elles soient sécurisées sur le disque, etc.

Cela se résume à deux choses essentielles : (1) Programmer de manière défensive, et (2) Tenir l'utilisateur aussi bien informé que possible. Si l'interface du système est facile à utiliser et se comporte conformément aux attentes de l'utilisateur, il est plus probable que celui-ci connaître quel bouton cliquer lorsqu'une boîte de dialogue ennuyeuse apparaît.

J'essaie aussi très, très fort d'éviter tout ce qui est modal, donc les utilisateurs peut ignorent la plupart des dialogues que je dois utiliser, du moins pendant un certain temps (et quand ils doivent vraiment y prêter attention, ils ont suffisamment d'informations pour savoir quoi en faire).

Il est impossible de rendre un système complètement infaillible, mais j'ai constaté que les techniques ci-dessus vont dans la bonne direction. (et elles ont été intégrées dans les systèmes utilisés pour développer Surprise Explain Reward et d'autres outils qui ont été validés par des études approfondies auprès des utilisateurs).

Answer 2

Tout d'abord, l'utilisation de la couleur et des icônes doit permettre à l'utilisateur d'avoir une idée visuelle de la gravité du problème. Le rouge est un signe exceptionnel, le jaune un avertissement et le blanc une information.

Deuxièmement, l'utilisation de des verbes sur vos boutons de dialogue donne aux utilisateurs une idée de ce qu'ils demandent au système de faire, même s'ils ne lisent pas le texte de la boîte de dialogue.

Enfin, si vous êtes intéressé par un paradigme de notification complètement différent, consultez la barre d'information ou la barre de notification qui est mise en œuvre dans Firefox et Internet Explorer. StackOverflow utilise le même type de mécanisme pour avertir les utilisateurs lorsqu'ils ont obtenu un nouveau badge.

La barre d'information est non intrusive et reste en haut de l'écran en attendant l'attention de l'utilisateur. Je pense que c'est une excellente métaphore de conception.

Voici quelques tutoriels de mise en œuvre :

• C#
• JavaScript

Voici Conseils de Microsoft sur la conception des boîtes de dialogue Il aborde également le concept de la barre d'information.

Answer 3

Immédiatement, le livre de Steve Krug Ne me faites pas réfléchir me vient à l'esprit.

Dans la conception des boîtes de dialogue, des messages d'état renvoyés à l'utilisateur, etc., il est bon d'utiliser l'iconographie et les couleurs pour indiquer ce que les mots disent réellement.

Mettez donc les messages d'erreur en rouge, les avertissements en jaune, etc.

Answer 4

L'interface humaine, par Jef Raskin vaut la peine d'être lu. Une boîte de dialogue est le dernier recours, et un signe de mauvaise conception. La plupart sont inutiles, et comme vous l'avez découvert, elles sont toutes ignorées par les utilisateurs.

Pourquoi y a-t-il une boîte de dialogue ? Résolvez ce problème - ne demandez pas aux utilisateurs de confirmer une opération, mais faites en sorte qu'il soit facile d'annuler l'opération. Ne faites pas apparaître une boîte de dialogue annonçant une erreur - faites la récupération que vous allez faire de toute façon (ou ce qui est possible). N'affichez surtout pas de boîtes de dialogue qui n'ont qu'une seule issue (les boîtes de type "OK" sont diaboliques), présentez les informations dans l'application de manière discrète.

Answer 5

Quelques suggestions

1. N'utilisez les boîtes que lorsque cela est absolument nécessaire.
2. Toujours définir l'option par défaut comme l'option la moins dangereuse.