Effrayer les utilisateurs pourrait-il être une bonne expérience utilisateur?
Je travaille sur une application conçue pour être utilisable par les nouveaux utilisateurs, mais qui a beaucoup de configuration compliquée pour les utilisateurs avancés. Notre approche pour éloigner les utilisateurs des paramètres délicats consiste à les rendre "effrayants". Ils sont cachés dans un menu "Expert" et les paramètres de configuration reçoivent des noms "effrayants" (par opposition à Nice, lisibles) tels que UseBxfrMethod, et aucune indication de ce qu'ils font (en dehors de notre documentation en ligne)./page man).
Pour les applications qui seront utilisées à la fois par les "novices" et les "experts", l'approche "d'effarouchement" est-elle une bonne UX? Ou une autre approche serait-elle meilleure?
Remarque: Mozilla utilise une approche similaire d'effarouchement, mais avec un peu plus d'humour:
Divulgation progressive
Le report de fonctionnalités avancées sur un écran secondaire est l'un des meilleurs moyens de satisfaire les exigences contradictoires de puissance et simplicité. C'est ce qu'on appelle divulgation progressive . Vous semblez en être conscient.
Intimidation des utilisateurs
Un exemple de divulgation progressive est une zone de recherche . La zone de recherche contient généralement un lien vers une page de recherche avancée, car l'inclusion d'options avancées sur la même page va très probablement dérouter les utilisateurs novices. Jakob Nielsen recommande d'utiliser un nom intimidant :
Il est important d'utiliser un nom intimidant comme "recherche avancée" pour empêcher les utilisateurs novices d'accéder à la page et de se blesser. La recherche est l'un des rares cas où je recommande de façonner le comportement de l'utilisateur par intimidation.
Communication du risque
Considérez ceci, un utilisateur avec de nombreuses années d'expérience dans l'utilisation d'autres applications est toujours un novice en ce qui concerne l'application votre. Je comprends que vous craigniez que les utilisateurs novices intrépides ignorent un nom intimidant comme "paramètres avancés". Cependant, des noms tels que UseBxfrMethod et obligeant les utilisateurs experts à lire les manuels seront probablement "désactivés", surtout s'ils ne sont pas des utilisateurs fidèles.
Une meilleure approche serait d'avoir plusieurs écrans secondaires. Par exemple, vous pouvez regrouper des paramètres inoffensifs dans un écran et des paramètres dangereux dans un autre et indiquer clairement le risque lié à la progression vers l'ensemble dangereux d'options tout en offrant un moyen facile d'accéder aux parties pertinentes de la documentation.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Conclusion Effrayer les utilisateurs novices pendant la progression de l'écran "novice" initial vers l'écran "expert" secondaire est bien pour vous, mais au-delà n'est pas recommandé.
Mise à jour du 13 janvier Je viens de remarquer que GitHub a appliqué ce concept dans la page des paramètres du référentiel.
Oui, mais je ne suis pas sûr que l'exécution fonctionne pour moi. Vous placez un panneau, facilement ignoré, à l'avant. Ensuite, ils entrent et feront un changement et oublient le signe.
J'aime l'utilisation de l'humour, mais je l'utilise généralement plus près d'une action dangereuse.
De plus, cela ne devrait pas être uniquement du texte. Trouvez un moyen de faire PENSER à l'utilisateur. Trop d'erreurs se produisent parce que les gens ne lisent pas. Ne permettez pas de faire l'action sans comprendre le choix. J'ai blogué sur ce modal particulier .
En général, le renforcement négatif comme l'effarouchement des utilisateurs doit être considéré comme une mauvaise idée. Les théories sur la publicité et la conception de produits (en dehors d'Halloween) ont trouvé l'utilisation de telles tactiques pour généralement se retourner contre elles et sont même citées dans des campagnes autour de la Première Guerre mondiale par des experts en publicité de l'époque comme Claude Hopkins (cite: Ma vie dans la publicité ).
Dans ma propre expérience, je n'ai vu que des réactions négatives en essayant d'effrayer les utilisateurs avec des noms complexes et hostiles et même une touche d'humour. Dans les tests, j'ai vu des utilisateurs répéter qu'ils avaient l'impression que le développeur/concepteur leur parlait et qu'ils préféraient être encouragés afin qu'ils puissent améliorer le produit. Un expert d'un produit a tendance à être plus fidèle qu'une personne qui ne le connaît pas et, par conséquent, continue d'être un client.
Donc, si vous avez des fonctionnalités expertes, j'essaierais de les rendre aussi utilisables que possible. Les noms que vous citez et la façon dont ils n'ont aucun sens pour un utilisateur, à moins qu'ils ne consultent une documentation distincte, constituent davantage une restriction et un obstacle à la formation de votre public qu'à l'aide de quelque manière que ce soit. Si vous êtes vraiment inquiet, cachez la section "expert" dans une section de configuration qui a le choix entre "activer les fonctionnalités expertes" et fournir un moyen convivial d'apprendre et d'utiliser ces fonctionnalités expertes qui ne représentent peut-être que 10 à 20% de vos utilisateurs. se soucient réellement. Il vaut mieux se concentrer sur les 80% que d'essayer de leur faire peur de ne PAS utiliser une partie de votre produit dans laquelle vous mettez beaucoup de temps.
Les avertissements sérieux sont corrects mais vous devez faire attention à ne pas les faire paraître enfantins. Si vous allez traiter vos utilisateurs comme des tout-petits, cela leur donnera l'impression qu'ils ne veulent pas du tout utiliser votre programme.
À l'école, nous avons récemment reçu un cours sur la conception d'interface utilisateur avec quelques principes qui devraient être maintenus pour une bonne expérience utilisateur. L'un d'eux est que si vous faites en sorte que l'utilisateur se sente stupide (par exemple en lui lançant une trace de pile lorsque vous ne gérez pas une erreur fatale, ou utiliser aveuglément quelque chose comme messagebox(exception.message) partout), c'est l'une des principales raisons pour lesquelles ils sont effrayés par votre programme. Ce n'est pas le cas de leur lancer des avertissements en soi, mais si vous les faites apparaître comme "vous ne comprendrez pas cela, partez". Si vous devez mettre un avertissement dans votre programme, dites simplement à l'utilisateur que au cas où il ne comprend pas ce que fait un paramètre, que c'est = recommandé pour les conserver à par défaut.
Donner aux utilisateurs des choix est un bon principe, mais ce n'est pas le cas s'ils ne comprennent pas le choix. Jetez un oeil à n dialogue stupide
Si vous regardez les preuves des systèmes d'exploitation Microsoft Windows vs Linux PC - De nombreux paramètres "experts" du système d'exploitation Linux sont cachés dans les commandes Shell (accordées, les versions récentes ont parcouru un long chemin pour incorporer des interfaces graphiques conviviales pour les tâches courantes ).
En 2011, on estimait que Linux détenait au total moins de 2% de part de marché, contre 92% pour Microsoft ( Part de marché - Wikipedia ).
Essentiellement, les systèmes d'exploitation essaient de faire la même chose. Vous pouvez attribuer la disparité d'utilisation à l'accessibilité des paramètres avancés. Oui, il existe de nombreux paramètres avancés dans MS Windows qui ne peuvent être modifiés que via le registre, mais beaucoup moins par rapport à Linux.
Bien sûr, vous pouvez également attribuer la disparité à un certain nombre d'autres facteurs. Mais je vous suggère que le Joe Public moyen trouve Linux effrayant et Windows pas ainsi. Par conséquent, en réponse à votre question - UX effrayant est mauvais UX.
Si quoi que ce soit, demander à l'utilisateur s'il veut effectuer une action dangereuse XXX, s'il est sûr, s'il est sûr d'être sûr, ad absurdum est tout à fait inutile. La réponse de Glen Lipka est une bonne idée, mais certains utilisateurs ne comprendront pas vraiment ce que la boîte de dialogue veut, et penseront que les données sont irréversiblement en place, et commenceront à harceler le développeur pour créer des boîtes de confirmation pour l'ajout de données. Bien que si l'utilisateur ne peut pas le comprendre, lui faisons-nous même confiance avec l'application?
Cela ne leur fait pas vraiment peur. C'est juste un sérieux avertissement et nous les utilisons dans le cadre d'interfaces dans toutes sortes de produits ménagers. Si vous ouvrez le boîtier du disjoncteur, il y avait mieux un avertissement sérieux indiquant que vous pourriez être sur le point de toucher suffisamment d'électricité pour vous tuer instantanément. Je pense qu'il y a des situations logicielles qui sont analogues.