Existe-t-il un terme pour "l'utilisateur ne peut pas utiliser quelque chose de mal"?
Je suis d'avis que l'utilisateur utilise toujours correctement le logiciel ou le matériel et impliquer le contraire est impoli, condescendant et philosophiquement erroné. Par exemple, moi et tout le monde que je connais tire les clés USB d'un ordinateur sans prendre la peine de cliquer sur éjecter. Les développeurs de système d'exploitation devraient voir cela et construire leur logiciel pour s'adapter à cela au lieu de déranger les utilisateurs avec des messages "vous avez fait ce mauvais".
Est-ce une opinion largement répandue parmi les concepteurs/développeurs UX? Y a-t-il un terme officiel pour cette philosophie?
edit: Il semble que je doive clarifier ce que je veux dire par "l'utilisateur ne peut rien utiliser de mal". Je ne dis pas que l'utilisateur devrait être empêché d'utiliser quelque chose de mal, mais qu'il n'y a pas de "mauvaises" façons d'utiliser quelque chose. Si un grand pourcentage d'utilisateurs utilisent un microphone comme un marteau (comme le Shure SM57 l'est vraiment), les concepteurs devraient adopter cela et améliorer les capacités du marteau lors de la prochaine itération.
edit 2: Je tiens à vous remercier tous d'avoir prouvé mon point. J'ai posté ici un point (l'utilisateur ne peut rien utiliser de mal) que j'ai interprété d'une manière et que vous avez tous interprété d'une autre manière. Mon intention était qu'il n'y ait pas de mauvaises actions à prendre, et votre interprétation générale était qu'il y a effectivement de mauvaises actions, et nous devrions travailler pour les prévenir.
Vous avez tous raison. En tant que concepteur de l'article, je suis en faute ici, et je pense que vous seriez d'accord. J'aurais dû préciser plus clairement ce que je voulais faire de cet article. Je n'ai pas le droit d'essayer de discuter avec l'un de vous de mes intentions car seule l'interprétation de l'utilisateur compte. Merci pour cette discussion si vivifiante!
Non. Ce n'est pas une opinion largement répandue parmi les concepteurs UX. Malheureusement.
Encore moins parmi ceux qui utilisent SO et se considèrent comme des concepteurs UX.
Je soupçonne que c'est principalement parce que la conception UX n'est pas un domaine rigoureux, et ses partisans ne pratiquent pas la patience et la compréhension de leurs utilisateurs potentiels. Pire encore, ils semblent croire que le `` design '' UX idéal existe et peuvent être discernés à partir des données, sans se rendre compte que cela se fait par la subjectivité d'eux-mêmes et de leurs pairs. Cela aggrave, car ils sont souvent les moins qualifiés pour définir des critères d'analyse, manquant à la fois de perspicacité et d'intuition. Souvent, ne valorise pas du tout ces choses.
UX Design est l'un des rares domaines à souffrir davantage de problèmes de biais d'auto-sélection que de programmation. Tout un exploit.
Oui, il y a un terme pour cela ("l'utilisateur ne peut pas faire quoi que ce soit mal"):
infaillible
Mais comme le soulignent d'autres réponses, il n'est pas possible de réaliser quelque chose de totalement infaillible. Sur wikipedia, j'ai trouvé une citation de Douglas Adams Mostly Harmless :
une erreur courante que les gens font en essayant de concevoir quelque chose de complètement infaillible est de sous-estimer l'ingéniosité des imbéciles complets
Il existe également un terme pour minimiser ce qu'un utilisateur peut faire de mal:
Conception défensive
Dans la conception défensive, vous essayez de concevoir de manière à ce que les utilisateurs puissent faire le moins de mal, sans s'attendre à le rendre complètement infaillible. Certaines techniques comprennent:
- Test aléatoire automatique: laisser un script donner des entrées aléatoires à votre application, en espérant le faire planter
- Test de singe: test de l'utilisateur, mais demandant aux utilisateurs d'essayer de casser le système ou d'essayer d'agir aussi inconsciemment que possible sur le fonctionnement du système.
L'hébergement pour chaque interaction utilisateur possible est impossible.
Prenons votre exemple, mais basculez l'USB sur un ordinateur entier. Un utilisateur peut tirer le cordon d'alimentation et s'attendre à ce que l'ordinateur s'éteigne en toute sécurité avec toutes les données enregistrées dans le lecteur comme par magie. Tout comme un USB. Comment un concepteur UX doit-il s'y préparer?
- Verrouillez le cordon en place afin que l'utilisateur ne puisse pas le retirer. Difficile à entretenir et à remplacer, plus d'argent est nécessaire pour une fonctionnalité que presque personne ne voudrait utiliser quand il suffit d'appuyer sur le bouton d'alimentation. Également beaucoup plus lent si vous devez déplacer plusieurs ordinateurs à la fois, par exemple lorsque votre entreprise change d'emplacement.
- Supprimez les caches informatiques. Les données ne sont jamais retardées, et vous n'avez même pas besoin d'appuyer sur Enregistrer lors de la mise à jour d'un composant. La vitesse de l'ordinateur ralentit maintenant à une exploration. Une myriade de problèmes de sécurité devront également être pris en compte.
- Utilisez une source d'alimentation de secours obligatoire. L'utilisateur est maintenant obligé d'acheter l'onduleur/la batterie du fabricant et doit payer pour le faire changer même s'il a déjà une pièce de rechange à la maison.
Toutes les solutions ci-dessus sont pires qu'un simple avertissement manuel des utilisateurs sur le danger de débrancher un ordinateur en marche.
Si vous ne vous attendez pas à ce qu'une scie électrique s'arrête comme par magie lorsqu'elle touche votre doigt, alors ne vous attendez pas à ce que les ordinateurs fassent tout le travail pour vous. C'est pourquoi les concepteurs et les programmeurs ont l'acronyme RTFM .
Conception centrée sur l'utilisateur
Ce que vous décrivez est une conséquence de ser-Centered Design (inventé par Don Norman lui-même ). J'ai entendu votre principe exprimé comme " l'utilisateur a toujours raison " et " ce n'est pas la faute de l'utilisateur ".
Comme cela a été souligné, ce type de réflexion n'est pas assez courant, même chez les professionnels de l'UX. Le problème est que nous essayons de "corriger" le comportement des utilisateurs, plutôt que de faire correspondre le modèle mental de l'utilisateur.
Dans votre exemple, le modèle mental de l'utilisateur est que le lecteur flash est prêt et peut être supprimé si aucun fichier n'est copié vers ou depuis celui-ci. Par conséquent, nous devons concevoir nos logiciels et notre matériel pour qu'ils correspondent à cela et pour éviter toute erreur qui pourrait en résulter. Voici quelques suggestions pour y parvenir:
- Ne gardez jamais un disque externe dans un état sale plus longtemps que nécessaire. Lorsque l'écriture sur le lecteur est terminée, placez le système de fichiers dans un état où il peut être débranché en toute sécurité.
- Toujours afficher une indication ou une notification lorsqu'un lecteur est en cours d'utilisation, par exemple lorsqu'un fichier est enregistré (ce qui devrait également être fait automatiquement!). Le système doit informer les utilisateurs de ce qui se passe exactement, afin qu'ils savent que le lecteur ne soit pas encore débranché.
- Idéalement, les ports USB devraient être repensés de sorte qu'il soit possible pour l'ordinateur de maintenir physiquement l'appareil en place; le système d'exploitation libère alors le disque lorsqu'il est sûr de pouvoir le débrancher. Cela rendrait ces problèmes impossibles. (C'est ainsi que fonctionnent les lecteurs de CD/DVD-RW lorsqu'un disque est en cours de gravure.) Je ne sais pas si cela est possible d'un point de vue technique, mais je pense que cela aurait dû être pris en compte lors du processus de conception de l'USB-C.
- Annuler . Si un lecteur a été débranché pendant son utilisation, il est possible de résoudre le problème en le rebranchant afin que le système puisse reprendre exactement là où il s'était arrêté.
Je me demande si le concept que vous recherchez est Poka-Yoke ( https://en.wikipedia.org/wiki/Poka-Yoke ). Ceci est souvent plus associé à la conception mécanique (par exemple, les doubles portes de la cage du zoo qui ne peuvent pas être ouvertes en même temps), mais vous pouvez faire une analogie avec la conception UX (par exemple, ne pas proposer de bouton de suppression lorsqu'il n'y a rien de disponible pour supprimer).
Il s'agit d'un principe de conception UX commun. Le meilleur message d'erreur est d'éviter un message d'erreur en premier lieu. Il existe de nombreux exemples de principes de conception, mais aucun ensemble standard.
Jacob Neilson a utilisé le terme "prévention des erreurs" dans ses 10 heuristiques d'utilisabilité. https://www.nngroup.com/articles/ten-usability-heuristics/
"Encore mieux que de bons messages d'erreur est une conception soignée qui empêche un problème de se produire en premier lieu. Éliminez les conditions sujettes aux erreurs ou vérifiez-les et présentez aux utilisateurs une option de confirmation avant de s'engager dans l'action."
Apple l'appelle "Contrôle utilisateur" dans leurs directives IOS: https://developer.Apple.com/design/human-interface-guidelines/ios/overview/themes /
"Les meilleures applications trouvent le juste équilibre entre permettre aux utilisateurs et éviter les résultats indésirables."
En abordant cette question d'un point de vue analytique, vous verrez cette mentalité dans certains environnements UX et pas dans d'autres. Si les utilisateurs sont très limités quant à ce qu'ils peuvent faire, vous verrez plus de préférence pour l'UX qui suit les principes que vous décrivez. Plus les utilisateurs sont libres de liberté, moins ces principes sont populaires.
Je ne dirais pas que c'est un vrai nom pour cet effet, mais je l'appellerais "avec une grande puissance vient une grande responsabilité".
C'est le problème avec l'exemple USB qui est apparu plusieurs fois dans ce fil. Un utilisateur qui peut modifier physiquement le matériel dispose d'un remarquable liberté. Ils ont un grand pouvoir sur le système et ont donc plus de responsabilité dans ce qui se passe. Bien sûr, je peux créer un périphérique USB qui se verrouille en place jusqu'à ce que les fichiers soient copiés. Cela fonctionnera tant que vous limitez leur puissance à de légers coups sur le matériel le long de l'axe du périphérique USB. Un utilisateur avec un Sawzall peut très certainement faire quelque chose de mal à mon périphérique USB s'il n'est pas suffisamment responsable et ne sait pas ce que peut couper un périphérique USB en deux lorsqu'il est connecté.
Ne parlons même pas de la mise en œuvre de PSU pour répondre à cette exigence Sawzall ...
Tout système doté d'un compilateur doit faire face à cette réalité. Je peux et vais faire quelque chose de mal avec mon compilateur. Je vais casser quelque chose. Je peux supprimer des fichiers que je ne devais pas supprimer. Heck, j'ai avoir supprimé de tels fichiers! Je les ai même supprimés en parallèle avec un glorieux annonciateur multithread de Doom! C'était une mauvaise nouvelle, et c'était certainement "mon erreur".
Comparez cela à la conception d'une application iPhone. iOS limite sévèrement ce que les utilisateurs peuvent faire et comment ils peuvent interagir avec les applications par conception. C'est le but d'un bon OS mobile. De même, les développeurs d'applications autorisent souvent très peu d'opérations. Cela rend votre UX simple. Dans ces situations, il est très facile de capturer la petite gamme d'opérations qu'un utilisateur peut effectuer et de prouver que l'utilisateur ne peut en effet rien faire de mal. Dans de tels contextes, il est très logique, du point de vue de l'expérience utilisateur, de soutenir cette mentalité.
En particulier, les applications professionnelles sont conçues dans cet esprit. Vous vraiment ne voulez pas laisser un travailleur débutant à bas salaire faire une erreur catastrophique avec votre application. Les dispositifs de point de vente sont conçus pour vous assurer de ne pas envoyer accidentellement un numéro de carte de crédit à un agent malveillant dans un pays étranger. Vous ne pouvez tout simplement pas le faire!
Nous pouvons donc voir les deux extrêmes. Dans certaines situations, vous voulez vous assurer que l'utilisateur ne peut vraiment rien faire de mal. Dans d'autres situations, vous ne pouvez pas. Je pense qu'il est assez raisonnable de dire qu'il n'y a pas de ligne de démarcation entre les mentalités. C'est un spectre fluide de "l'utilisateur ne peut pas faire de mal" à "oh mon dieu, le singe a un couteau!"
Nous l'avons toujours appelé l'épreuve des utilisateurs, et c'est généralement l'aspect le plus long du développement logiciel. Ce n'est pas tant que l'utilisateur ne peut rien faire de mal, mais plus que ce que l'utilisateur fait ne plantera pas ou ne cassera pas le logiciel. Ce terme remonte au moins à 1997 lorsque j'ai commencé à me développer professionnellement, et probablement beaucoup plus tôt.
Je suis choqué de voir que personne n'a évoqué le fait que tout dans la conception et l'ingénierie a un coût. Vous pouvez toujours concevoir une meilleure version de tout ce que vous faites, qui couvre plus de cas d'utilisation et offre plus de fonctionnalités que les utilisateurs veulent, mais chaque fois que vous sacrifiez quelque chose d'autre. La chose que vous sacrifiez peut être le coût littéral et augmenter le prix ou réduire les bénéfices, ou cela peut être un compromis d'une autre manière.
Pour utiliser votre exemple d'usb retiré sans éjection, il existe quelques coûts associés à différentes approches.
Si vous mettez le verrou USB en place, vous ajoutez des coûts de fabrication et de la complexité aux lecteurs et aux ports, et vous diminuez la convivialité car cela les rend plus encombrants à installer ou à retirer. Même si quelqu'un pouvait faire un tel lecteur, je ne l'achèterais jamais et continuerais d'acheter des usb normaux sans serrures.
Si au contraire vous vous assurez que l'USB est maintenu dans un état éjectable autant que possible, vous perdrez les performances (car l'ordinateur devra faire un nettoyage constant et limiter les temps d'écriture à de courtes rafales). Étant donné que l'un des principaux arguments de vente des lecteurs flash est la vitesse de lecture/écriture, cela signifie également que personne ne voudrait l'acheter.
De toute façon, en essayant de couvrir ce problème de niche UX, ils ont perdu beaucoup de clients potentiels.
Fondamentalement, ce que je dis, c'est que vous devez faire une analyse coûts/avantages et décider quelles fonctionnalités valent le coup et lesquelles dépassent la portée de ce que vous essayez d'accomplir. Oui, nous devons regarder et écouter les utilisateurs et découvrir comment affiner nos produits pour être plus utiles dans des scénarios réels, mais il y a toujours une limite.
Les développeurs de systèmes d'exploitation [et de tous les logiciels] devraient voir cela et créer leur logiciel pour s'adapter à cela au lieu de déranger les utilisateurs avec des messages "vous avez fait ce mauvais".
Oui, vous avez totalement, complètement, absolument raison.
Les ingénieurs et les entreprises qui font ce que vous dites gagnent énormément d'argent.
Certains des plus grands produits clés de notre ère sont entièrement basés sur ce que vous décrivez.
Est-ce une opinion largement répandue parmi les concepteurs/développeurs UX?
Oui, c'est l'une des idées centrales.
il est constamment et largement discuté comme l'un des problèmes centraux de l'UX.
La BMW série 7 était un cauchemar car vous deviez vous battre et rechercher toutes les fonctions parmi des centaines de choix. Alors que le chef-d'œuvre du cockpit Renault Espace était (voir ci-dessous) piloté par l'utilisateur et incarnation de cela.
Y a-t-il un terme officiel pour cette philosophie?
Bien sûr que ça l'est
Conception orientée utilisateur
Il n'y a pas 10 minutes Je criais à certaines personnes de "faire en sorte que ce soit axé sur l'utilisateur". Ils avaient des interrupteurs, etc. qui "devaient être" réglés par un client avant utilisation, ce qui est une idée de merde. Au lieu de cela, j'ai crié à tout le monde de le faire "à la Pascal". J'ai littéralement dit "Rendez ceci piloté par l'utilisateur , débarrassez-vous des putains de commutateurs."
Hier J'ai littéralement traité toute la journée de travail avec précisément le "problème Pascal" par rapport à un produit et aucun autre problème.
Il y a deux ans J'ai passé quatre mois à inventer personnellement/ingénierie/quelque chose d'un nouveau type d'algorithme pour une interface graphique inhabituelle où le résultat final complet éliminait deux mauvaises actions "de style anti-Pascal". (Le résultat a fait des zillions.)
Notez que dans une certaine mesure, la phrase de tous les jours
BAISER.
équivaut à une approche similaire.
Remarque - puisque le "problème Pascal" est en effet si omniprésent, il existe
beaucoup, beaucoup termes spécifiques pour des sous-ensembles du concept:
Par exemple, dans l'exemple littéral que vous avez donné, qui est connu comme
brancher et utiliser
ou
remplaçables à chaud
Notez qu'une entreprise dont nous avons entendu parler, Apple, a sans doute gagné environ 10 milliards de dollars en étant la première à commercialiser des imprimantes plug-and-play ("plus") et d'autres périphériques que les concurrents de l'époque, avant votre naissance.
Ainsi, "plug and play" ou "hot swappable" est en effet un sous-ensemble spécifique particulier de la conception globale pilotée par l'utilisateur, KISS-UX, "Pascal-issue".
Je dois clarifier ce que je veux dire par "l'utilisateur ne peut rien utiliser de mal". Je ne dis pas que l'utilisateur devrait être empêché d'utiliser quelque chose de mal, mais qu'il n'y a pas de "mauvaises" façons d'utiliser quelque chose. Si un grand pourcentage d'utilisateurs utilisent un microphone comme un marteau (comme le Shure SM57 l'est vraiment), les concepteurs devraient adopter cela et améliorer les capacités du marteau lors de la prochaine itération.
Cela change presque entièrement la signification de votre titre. Cela va de l'évitement des erreurs à "le bug est une fonctionnalité".
La chose la plus proche à laquelle je peux penser est X Agile/Lean. C'est là que vous avez une courte boucle de rétroaction. Vous construisez votre produit, que ce soit un microphone ou une application mobile et le mettez entre les mains des utilisateurs. Ensuite, selon la façon dont ils l'utilisent, vous améliorez ces fonctionnalités.
Aussi dans la mesure où les choses ne sont pas utilisées dans leur but d'origine - je pense que le mot-buzz "pivot" entre en jeu. C'est là que les gens du microphone se rendent compte ils ont construit un meilleur marteau par accident et commencent à vendre des marteaux dans lesquels vous chantez.
Il y a aussi un autre domaine similaire mais lié où vous avez des erreurs qui s'avèrent extrêmement utiles - les accidents fortuits semblent être un terme pertinent ici. Je crois que le plus célèbre d'entre eux est pénicilline , mais il y a aussi la découverte de Blu tack au Royaume-Uni:
Fleming a raconté que la date de sa découverte de la pénicilline était le matin du vendredi 28 septembre 1928. La version traditionnelle de cette histoire décrit la découverte comme un accident fortuit : dans son laboratoire au sous-sol de l'hôpital St Mary à Londres (qui fait maintenant partie de l'Imperial College), Fleming a remarqué qu'une boîte de Pétri contenant des staphylocoques qui avait été laissée ouverte par erreur était contaminée par de la moisissure bleu-vert provenant d'une fenêtre ouverte, qui formait un croissance visible. Il y avait un halo de croissance bactérienne inhibée autour du moule. Fleming a conclu que la moisissure libérait une substance qui réprimait la croissance et provoquait la lyse des bactéries.
La phrase qui me vient à l’esprit est
"Le client a toujours raison."
Les utilisateurs sont vos clients en tant que développeur.
Passé ça ... à l'épreuve des balles.
UCD est proche
Centré sur l'utilisateur est le principe général et, IME, il est largement accepté parmi les équipes de produits logiciels modernes et de nombreuses équipes de produits matériels.
UCD est conduit par l'observation des utilisateurs dans le contexte le plus réaliste possible. Le concepteur étudie les réactions et les interactions avec les produits et les prototypes afin d'apprendre comment un utilisateur non guidé dans son environnement quotidien utilisera les outils fournis par l'équipe produit.
Le problème avec l'UCD est qu'il a tendance à être trop pris dans les observations des utilisateurs étroitement liées et perd la vue d'ensemble et le potentiel de la technologie.
ACD est plus proche
Je pense que Conception centrée sur l'activité traite directement de ce problème. ACD traite l'intégralité du flux de travail de l'utilisateur et le travail qui doit être accompli.
ACD change la perspective de
"Comment l’utilisateur souhaite-t-il que cette chose exécute une fonction"
"Comment pouvons-nous rendre l'utilisateur fondamentalement plus performant dans ce travail".
Quand l'utilisateur le voit différemment
Si l'utilisateur regarde votre produit et décide de l'utiliser à des fins non voulues ou d'une manière non voulue, l'UXD est obligé de poser une question à l'entreprise:
Sommes-nous totalement déterminés à résoudre le problème d'origine ou voulons-nous pivoter pour répondre à cette opportunité imprévue?
Généralement, vous voulez rester concentré sur le problème d'origine (en supposant que vos tests montrent qu'il est même pertinent). Sur la base de votre observation des activités de l'utilisateur, l'UXD a maintenant des preuves à intégrer dans le prochain prototype.
C'est là que le prototypage rapide et les tests utilisateurs gagnent leur vie - il n'y a pas de moyen plus efficace et efficient de savoir si vous avez résolu le bon problème de la bonne manière. Consultez le livre "Sprints" pour en savoir plus sur ce modèle.
Non vous êtes faux
Si l'UXD conçoit des produits sans incorporer une "erreur" d'utilisateur, alors ils le font mal. Il est temps d'envoyer votre équipe à l'école ou d'en trouver une nouvelle.
Falling Into The Pit of Success est un terme utilisé dans la communauté du développement. Il est plus axé sur la conception du langage ou de la bibliothèque, mais peut également être appliqué à l'interaction frontale. C'est certainement du vocabulaire que j'utiliserais lorsque j'examinerais l'UX avec d'autres développeurs pour les mettre sur la même page.
La conception "l'utilisateur ne peut rien utiliser de mal" n'existe pas parce qu'elle ne devrait pas. C'est une chose de "prévenir" la conception, d'éviter les erreurs conscientes et les erreurs de l'utilisateur, mais supposer que "l'utilisateur ne peut rien faire de mal" peut avoir des conséquences négatives.
Nielsen Norman Group, dans Prévention des erreurs des utilisateurs: éviter les glissements inconscients , explique:
Le concepteur est en faute pour avoir rendu trop facile à l'utilisateur de commettre l'erreur. Par conséquent, la solution aux erreurs des utilisateurs n'est pas de gronder les utilisateurs, de leur demander de faire plus d'efforts ou de leur donner une formation plus approfondie. La réponse est de repenser le système pour qu'il soit moins sujet aux erreurs.
Lignes directrices générales pour prévenir les glissades:
- Inclure des contraintes utiles
- Suggestions d'offre
- Choisissez de bonnes valeurs par défaut
- Utiliser la mise en forme pardonnante
D'un autre côté, si vous êtes trop indulgent lorsque vous collectez une adresse utilisateur, comment pouvez-vous l'utiliser pour livrer un produit? Le traquer parce que vous ne voulez pas le stresser pour fournir une adresse correcte ne peut pas être la solution.
Un autre exemple peut être lorsque vous informez un utilisateur que s'il supprime son compte, celui-ci ne sera plus disponible. Il est acceptable de prévoir un intervalle de 30 jours lorsqu'il peut changer d'avis, mais après cela, il n'est plus autorisé de stocker les données, simplement parce que l'utilisateur pourrait supprimer le compte par accident.
Je ne pense pas que l'UX en tant que communauté ait un terme pour "l'utilisateur ne peut rien faire de mal". en soi. Mais il existe diverses philosophies de conception d'autres disciplines qui peuvent s'appliquer, telles que "à toute épreuve", "à sécurité intégrée" ou "à l'épreuve des enfants".
Par exemple, mes filles de 5 et 6 ans utilisent l'application YouTube Kids depuis plus d'un an et n'ont eu qu'une seule difficulté technique mineure pendant tout ce temps (juste pour référence, elles n'ont pas pu faire disparaître les aperçus vidéo lorsqu'une vidéo était Je leur ai montré comment glisser vers le bas et ils sont partis. Cependant, si vous attendez une minute, ils disparaissent d'eux-mêmes). C'est une réalisation incroyable.
Une bonne ressource à ce sujet est Don't Make Me Think par Steven Krug.
Venant du monde Mac, j'ai été personnellement étonné que quelque chose d'aussi simple que de faire glisser le document d'une application depuis le bureau vers l'icône de l'application dans la barre des tâches n'ouvre pas le document. Nous sommes sur Windows version 10 et cela ne fonctionne toujours pas. Jusqu'à Windows 7, il afficherait une erreur.
Votre philosophie peut ne pas être applicable à tout - certains processus nécessiteront toujours une courbe d'apprentissage - mais vous êtes à la hauteur.
Lorsque je me perds dans un site Web de banque en ligne, j'utilise pour dire aux personnes de soutien:
Si I ne peut pas le trouver (en tant que professionnel informatique qualifié), yo le fait mal.
Toutes les expériences ne doivent pas nécessairement être délicieuses ou faciles. La facilité cognitive peut aider les gens à s'amuser et à se sentir plus créatifs, mais à l'inverse, ils peuvent également être sujets à des erreurs de jugement intuitif.
À l'inverse, il est prouvé que la tension cognitive mobilise un mode de pensée plus prudent et délibéré qui peut corriger les erreurs intuitives.
Cela semble particulièrement pertinent dans les situations où il y a relativement plus en jeu, comme l'achèvement d'un emploi ou d'une école important ou d'une demande de subvention ou de permis gouvernemental, ou dans un contexte médical ou pharmaceutique, ou même lorsque l'on envisage un achat en ligne très coûteux.
Je ne suis pas convaincu que le " Don't Don't Make Me Think ", souvent répété, ne soit pas simplement un mauvais conseil. Ma propre expérience de conception pour les utilisateurs des sciences de la vie m'a poussé à m'éloigner de facile et davantage vers approprié comme cible.