Comment guider pour supprimer quelque chose de non critique
Lorsqu'un utilisateur souhaite supprimer quelque chose, nous avons tendance à le protéger en:
- demander une confirmation, oui | non
- en leur donnant la possibilité d'annuler
Cela vaut pour le contenu qui est réellement supprimé. Un e-mail que vous supprimez ou la corbeille d'une photo. Mais qu'en est-il des actions moins critiques? Comme supprimer une balise d'un article, ou ne pas amener quelqu'un? Dans de tels cas, aucun contenu n'est supprimé, c'est juste une relation qui n'existe plus. Mais l'ajouter à nouveau est trivial.
Une approche consiste à ne pas guider du tout. Juste une croix rouge, et en cliquant dessus, la balise de l'article a été supprimée. Existe-t-il des moyens de guider les utilisateurs dans ce domaine? (Sauf pour faciliter la recréation.)
Que diriez-vous de fournir un bref message qui s'affiche juste après l'action, vous donnant une chance de reconsidérer? "Vous n'êtes pas ami Jack. Vous ne recevrez plus de mises à jour de sa part. Annuler?" Si le message n'ouvre pas une boîte de dialogue mais apparaît sur la page elle-même, et qu'il disparaît automatiquement une seconde plus tard, alors il peut être très subtil et sans interférence. C'est un peu différent de "le rendre facile à recréer", parce que c'est plus proche de "n'avoir jamais désamorcé Jack en premier lieu" que de "re-friending Jack". Cela peut même provoquer des comportements différents - comme si Jack n'était pas vraiment amical jusqu'à ce que l'option d'annulation immédiate ait disparu.
Alternativement, vous pouvez prouver ces informations en survolant/info-bulle sur le bouton, avant que l'action ne soit effectuée.
Annuler
Si cela est possible de quelque manière que ce soit, offrez une fonction d'annulation décente du fonctionnement de la session/page en cours. Au cours de la dernière décennie, le modèle utilisateur est passé de "l'utilisateur lit le manuel et sait ce qu'il fait, généralement" à "les expériences utilisateur jusqu'à ce qu'il comprenne comment les choses fonctionnent".
Cela n'est pas toujours possible en fonction des données impliquées (ou des restrictions). Mais pour ces changements mineurs, cela s'applique certainement.
Vous pouvez embellir cela par une bulle/barre d'informations non modale pour indiquer la fonctionnalité d'annulation aux utilisateurs novices (avec une option pour les désactiver, bien sûr). Je ne ferais cela que pour les applications/environnements où l'annulation est inattendue ou non prise en charge pour tous les éléments.
Histoire
Encore mieux (mais nécessitant encore plus de travail) est un historique variable, qui permet à l'utilisateur de voir au moins les anciennes données, afin qu'elles puissent être recréées.
Pour vos exemples: Un "historique des tags" ou une liste "d'anciens amis" pourrait même vous inciter à "retag" ou "re-friend".
Cela nécessite de conserver plus de données, à la fois en quantité et en complexité. Mais l'expérience de l'utilisateur final est bien meilleure que "Voulez-vous vraiment supprimer cette balise?"
Nous parlons d'actions "destructives" comme Supprimer et Supprimer comme si elles se trouvaient dans une classe spéciale nécessitant une protection spéciale. En réalité, presque toutes les actions créent et détruisent. Changer la vue de mon document pour imprimer en contour "détruit" une présentation d'informations pour le plaisir d'une autre. La question à se poser est: "Quelle est la gravité des conséquences si l'utilisateur fait cette action par accident?" Ajouter accidentellement un "ami" indésirable à une liste peut être aussi mauvais que supprimer un "ami" recherché.
Les conseils que vous recherchez sont les suivants:
L'utilisateur doit être en mesure d'annuler toute action discrète avec la même quantité ou moins de travail qu'il faut pour terminer l'action.
S'il existe un moyen clair d'annuler une action qui prend moins de 20 secondes de travail, alors l'action ne doit pas avoir une confirmation.
S'il est techniquement impossible de fournir un moyen d'inverser une action avec moins de 20 secondes de travail, l'action doit avoir une confirmation.
Inverser une action peut signifier sélectionner Annuler, et c'est certainement une bonne façon de le faire. Cependant, il pourrait être n'importe quelle manière clairement apparente pour inverser l'action, y compris la refaire à partir de zéro. Si l'utilisateur peut ajouter un ami en 20 secondes, sa suppression ne devrait pas avoir de confirmation.
Notez que cela signifie que les confirmations ont tendance à être surutilisées. Peu importe que l'utilisateur supprime un roman de 500 pages qui a pris 3 ans à écrire. S'il peut être récupéré en le retirant du recyclage (ou en appuyant sur Ctrl-Z), il n'a pas besoin de confirmation. Personnellement, j'exécute l'Explorateur Windows avec la confirmation de suppression désactivée, et je ne le regrette pas encore.
Cela s'applique à toutes les actions , pas seulement destructrices. Devriez-vous confirmer la fermeture de l'application lorsque tout est enregistré? Si vous entrez à nouveau, cela signifie simplement double-cliquer sur une icône et faire défiler, non. Si cela signifie passer par un processus de connexion élaboré de 45 secondes, alors oui.
Quelle est la particularité des 20 secondes? Il faut environ 2 secondes pour cliquer sur une confirmation. Je pense que 10% de toutes les actions sont des erreurs (c'est probablement généreux). Si vous ajoutez une confirmation à une action qui prend moins de 20 secondes à inverser, alors en moyenne vous créez plus de travail que vous n'enregistrez l'utilisateur .
Ajoutez à cela le fait que les confirmations n'aident généralement pas l'utilisateur de toute façon. L'utilisation abusive et la surutilisation des confirmations ont entraîné les utilisateurs à rejeter puis par habitude, généralement sans les lire (j'en ai plus à ce sujet sur Of Dialogs and Detritus ). De plus, les utilisateurs ne se rendent souvent compte qu’ils font une erreur qu’après la validation de l’action et voient les résultats. Les confirmations sont principalement utiles pour attraper des glissements de souris ou de doigt. Sinon, il vaut mieux fournir:
Des indications claires de ce que fait chaque commande.
Rétroaction claire et immédiate des conséquences de chaque commande.
Des moyens clairs et rapides pour inverser la commande.
L'étiquette sur le bouton/lien est votre meilleur guide. Un x pourrait être un peu déroutant car il pourrait signifier "fermer", "masquer" ou "supprimer", alors utilisez plutôt des mots. Quoi que vous fassiez, cela ne devrait pas ajouter de charge supplémentaire à l'utilisateur (donc une boîte de dialogue est hors de question). Si l'utilisateur fait quelque chose de simple et de non critique, il n'y a pas besoin de longues explications qui ne seront pas lues de toute façon.
Il semble que nous soyons tous d'accord ici. Je ne savais pas, jusqu'à ce que je raisonne comme ceci:
Il s'agit de supprimer quelque chose de non critique, et l'hypothèse que Lode y met est: l'utilisateur VEUT le supprimer. Si cette hypothèse est vraie, alors l'acte nécessaire pour la suppression doit être précisé (comme le X, ou le "survol" ou quelque chose avec la souris) et cela devrait suffire. Cependant, l'hypothèse ne pourrait pas être vraie: l'utilisateur ne veut pas supprimer, mais néanmoins il vient de faire une action qui aurait pour conséquence la suppression. Maintenant, le même texte X ou "supprimer" fonctionnera comme un avertissement. Et puisque l'élément supprimé n'est pas critique (dans la question de Lode), cela devrait également suffire.