Voulez-vous vraiment répondre à cette question?
Nous avons tous vu ces types d'avertissements: "Êtes-vous sûr de vouloir fermer Windows?"
J'entends beaucoup de gens répondre avec frustration: "Oui, bien sûr, sinon je ne l'aurais pas cliqué!"
Ces types de messages d'avertissement peuvent être très ennuyeux, mais ils peuvent également vous éviter de perdre des données.
Dans les versions Windows modernes, Microsoft a supprimé ce message d'avertissement. Mais dans de nombreux logiciels et sur de nombreux sites Web, nous voyons toujours ces types d'avertissements:
- "Voulez-vous sauvegarder votre travail?"
- "Voulez-vous fermer tous les onglets?" (ce que certains navigateurs demandent, contrairement à certains navigateurs).
La façon utilitariste de résoudre ce dilemme serait de dire:
" de nombreuses personnes cliquent délibérément sur un bouton et seulement quelques personnes cliquent sur un bouton par accident, donc le message d'avertissement doit être supprimé. " (dont j'entends un lot). Mais est-ce la bonne façon de penser?
La question est donc:
Existe-t-il des études ou des heuristiques sur quand et où utiliser un message d'avertissement et comment pouvons-nous empêcher de les utiliser (si cela est préférable)? Je suis aussi curieux de lire votre avis!
La réponse
Pour le moment, la réponse de steveverrill à propos d'une case à cocher "Ne plus afficher ce message" est la solution la plus simple et la plus sûre.
Dans certains cas (peut-être à l'avenir lorsque les ordinateurs seront plus avancés), les boutons d'enregistrement et/ou de restauration automatiques pourraient être une meilleure solution. Vérifiez également ces autres réponses bien pensées!
Oui. Il existe une heuristique très simple et efficace qui s'adapte aux préférences de chaque utilisateur.
Cochez la case dans la boîte de dialogue du message d'avertissement qui indique:
Ne plus afficher ce message
Ce qui peut être encore amélioré en indiquant où cette boîte de dialogue peut être réactivée.
Ce sont des messages de confirmation - Windows a un page assez détaillée sur leurs directives . L'ensemble de cette page est assez utile mais voici quelques extraits (soulignement le mien):
Les confirmations sont plus utiles lorsque l'action nécessite que l'utilisateur fasse un choix pertinent et distinct qui ne pourra pas être fait ultérieurement. Ce choix implique souvent un élément de risque qui n'est pas évident pour l'utilisateur, mais le risque n'est pas essentiel aux confirmations. Ces éléments sont nécessaires pour justifier l'interruption de la réponse à un dialogue modal.
(Aucun accent supplémentaire de ma part pour ce qui suit):
Est-ce la bonne interface utilisateur?
Pour décider, considérez ces questions:
- Est-ce qu'une question est posée à l'utilisateur pour effectuer une action comportant deux réponses ou plus? Sinon, le message n'est pas une confirmation.
- L'interface utilisateur présente-t-elle une erreur ou un problème qui s'est produit? Si c'est le cas, utilisez plutôt un message d'erreur.
- La poursuite de l'action nécessite-t-elle que l'utilisateur fasse un choix qui n'a pas de valeur par défaut appropriée? Dans l'affirmative, une confirmation peut être appropriée.
- Existe-t-il une conception alternative qui élimine le besoin de confirmation? La nécessité d'une confirmation indique parfois un défaut de conception. Il existe souvent une meilleure alternative de conception qui n'a pas besoin de confirmation.
- L'utilisateur est-il sur le point d'effectuer une action risquée? Dans l'affirmative, une confirmation est appropriée si l'action a des conséquences importantes ou ne peut pas être facilement annulée.
- L'utilisateur est-il sur le point d'abandonner une tâche? Si oui, ne confirmez pas. Supposons que les utilisateurs comprennent les conséquences de ne pas terminer une tâche.
- L'action a-t-elle des conséquences dont les utilisateurs pourraient ne pas être conscients? Dans l'affirmative, une confirmation peut être appropriée.
- Compte tenu du contexte actuel, les utilisateurs sont-ils susceptibles d'effectuer une action par erreur? Dans l'affirmative, une confirmation peut être appropriée.
- Les utilisateurs effectuent-ils fréquemment l'action? Si c'est le cas, envisagez une conception alternative. Les confirmations fréquentes sont ennuyeuses et ont peu de valeur car les utilisateurs apprennent à répondre sans réfléchir.
- L'action a-t-elle des implications sur la sécurité? Dans l'affirmative, une confirmation peut être requise même si les tests précédents indiquent le contraire.
...
Considérez les alternatives de conception
Voici quelques alternatives de conception qui éliminent le besoin de confirmations de routine:
- Empêchez les erreurs. Concevez les tâches de manière à ce que les erreurs importantes soient difficiles à faire accidentellement. Par exemple, séparez physiquement les commandes destructrices des autres commandes et nécessitez plusieurs actions.
- Fournir l'annulation. Fournir la possibilité d'annuler des actions. Par exemple, la suppression d'un fichier dans Microsoft Windows ne nécessite généralement pas de confirmation car les fichiers supprimés peuvent être récupérés à partir de la corbeille. Notez que si une action est très facile à exécuter, le simple fait de refaire l'action peut suffire.
- Fournissez une rétroaction. Rendez les résultats indésirables évidents. L'annulation seule ne suffit pas si les utilisateurs ne se rendent pas compte lorsqu'ils font une erreur. Par exemple, l'effet d'une manipulation directe (comme une opération de glisser-déposer) doit toujours être évident.
- Supposons le résultat probable, mais facilitons le changement. Si vous n'êtes pas sûr de ce que veulent les utilisateurs mais qu'il existe un choix probable, sûr et sécurisé , supposez ce choix, expliquez clairement ce qui s'est passé et simplifiez la modification à l'aide d'un menu contextuel. Par exemple, Microsoft Word suppose que les utilisateurs souhaitent épeler correctement les mots. S'il reconnaît un Word mal orthographié et qu'il connaît l'orthographe probablement correcte, Word effectue automatiquement la correction mais permet aux utilisateurs de revenir en arrière.
- Éliminez complètement le choix. Si le choix n'est pas important, les utilisateurs ne s'en soucieront pas. Mieux vaut simplifier votre programme et éliminer le choix.
Modifier:
Plus loin, qui, je pense, mérite également d'être mentionné dans une page distincte sur principes de l'interface utilisateur tiré de divers livres parle des utilisateurs novices :
10. Le principe de sécurité
...
Les utilisateurs novices doivent être assurés qu'ils seront protégés de leur propre manque de compétences. Un programme sans filet de sécurité rendra ce type d'utilisateur mal à l'aise ou frustré au point de ne plus pouvoir utiliser le programme. Le message "Êtes-vous sûr?" La boîte de dialogue et les fonctionnalités d'annulation à plusieurs niveaux sont essentielles pour ce type d'utilisateur.
Apple Guidelines ne semble pas avoir de directives sur le moment, juste "ne pas trop utiliser" :
Lorsqu'il est possible que les utilisateurs ne sachent pas que leur action pourrait avoir des conséquences négatives, il peut être approprié de formuler le message d'alerte sous forme de question. Par exemple, une question telle que "Êtes-vous sûr de vouloir effacer l'historique?" identifie les actions entreprises par les utilisateurs et les invite à considérer les résultats. Cependant, n’abusez pas de ce type d’alerte; les utilisateurs se fatiguent rapidement lorsqu'on leur demande s'ils sont sûrs de vouloir faire quelque chose.
Google Material Design suggère que vous ne devez les utiliser que pour les situations à haut risque et utiliser une question claire plutôt que 'êtes-vous sûr ? (c'est évidemment quoi vous devriez écrire, plutôt que quand):
Alertes avec barres de titre
Utilisez les alertes de la barre de titre uniquement pour les situations à haut risque, telles que la perte potentielle de connectivité. Les utilisateurs doivent être en mesure de comprendre les choix en se basant uniquement sur le titre et le texte du bouton.
Si un titre est requis:
- Utilisez une question ou une déclaration claire avec une explication dans la zone de contenu, telle que "Effacer le stockage USB?".
- Évitez les excuses, l'ambiguïté ou les questions telles que "Attention!" ou "Êtes-vous sûr?"
Je suis surpris que personne n'ait fait apparaître la boîte de dialogue d'arrêt de Mac OS X. Il vous présente un "Êtes-vous sûr?" fenêtre, mais dispose d'une minuterie de sorte que si l'utilisateur s'éloigne, s'attendant à ce que l'ordinateur se soit éteint, il laissera à l'utilisateur le temps d'annuler.
Il y a 3 cas.
L'action destructrice
Voulez-vous supprimer ce fichier?
Non. Faites juste l'action, et affichez une confirmation snackbar (petit widget non bloquant quelque part où il est visible mais pas dans la manière de fonctionner) qui permet d'annuler (alors, soit retarder l'action, soit faire vous pouvez le revenir facilement).
La question ne peut être répondue que par l'utilisateur. par exemple.
Voulez-vous autoriser cette application à accéder à quoi que ce soit?
Première fois, affichez une fenêtre contextuelle. Si vous utilisez la fonction "Ne plus me demander", assurez-vous qu'il est super facile de changer d'avis. Google suggère un snack-bar pour autoriser discrètement l'utilisateur de modifier ce paramètre par la suite.
L'action engageante
Éteindre l'ordinateur? Envoyer cet e-mail? Publier cet article?
Cela dépend de votre capacité à annuler l'action. Plusieurs options sont disponibles. Dans l'ordre de préférence:
- Retardez l'action pour donner à l'utilisateur le temps d'annuler.
- Assurez-vous que vous pouvez annuler tout ce qui a été fait. (par exemple, redémarrage rapide d'un logiciel et restauration de l'état précédent)
- Demandez confirmation. Essayez d'éviter cela. C'est ennuyeux la plupart du temps et rarement utile.
Je suis un grand partisan de pas montrant des messages empêchant les utilisateurs de faire ce qu'ils avaient l'intention de faire. La solution UX avec des popups de confirmation est venue de l'âge de pierre des pratiques UX informatiques. Il part d'une supposition correcte que si nous avons une ressource critique, nous ne devons pas laisser les utilisateurs l'endommager par accident. Cependant, un accident est appelé ainsi car il arrive rarement . Cela signifie dans la majorité des cas que la confirmation n'est qu'un gaspillage d'un clic.
Cependant, nous devons protéger les utilisateurs contre les accidents. Ainsi, la bonne façon de procéder consiste à enregistrer l'état actuel dans la pile d'annulation, à poursuivre l'opération, puis à laisser l'utilisateur l'annuler ou l'annuler. Je considérerais cette solution plus comme une directive que comme une règle, mais je suis sûr qu'elle peut être appliquée à de nombreux cas.
Par exemple, en cas d'arrêt Apple enregistre l'état actuel de toutes vos applications. Lorsque vous redémarrez, vous revenez à votre travail comme si vous ne l'aviez pas arrêté.
Si une opération peut détruire irréversiblement une ressource critique (par exemple, supprimer quelque chose dans une application 3D via une API), planifiez l'action pour qu'elle démarre dans un avenir proche, disons dans 60 secondes, mais laissez l'utilisateur l'annuler, s'il le souhaite.
Cela dit, je pense que dans la plupart des cas, ce genre de confirmations n'est pas nécessaire.