Quelles sont les idées fausses et les inconvénients courants de l'interface utilisateur?
J'utilise souvent des applications et des appareils électroniques pour lesquels je pense: "Pourquoi diable ont-ils conçu cette chose telle qu'elle est? Ils ont dû savoir que c'est une douleur dans le cou de travailler avec".
D'un autre côté, j'ai souvent observé que j'avais créé une interface (G) dont j'étais convaincu, que cela ravirait mes clients et que c'était un jeu d'enfant. Bien que mes clients aient pensé cela aussi, il est devenu évident qu'il n'était pas du tout facile de travailler avec dans le travail quotidien.
Pour cette raison, je pense qu'il existe de nombreux développeurs et concepteurs qui sont vraiment convaincus que leur produit a l'interface utilisateur parfaite, mais ce n'est pas le cas!
C'est pourquoi j'ai écrit cette question: pour recueillir certaines des idées fausses courantes que les développeurs ont sur les interfaces utilisateur et pour empêcher d'autres développeurs (y compris moi) de faire les mêmes erreurs.
Qu'est-ce qui vous ennuie le plus dans les interfaces utilisateur des applications, des sites Web, des appareils électroniques, etc., mais qui a vraisemblablement été créé pour le bénéfice de l'utilisateur? Qu'est-ce que vous étiez convaincu que ce serait une excellente idée, mais au final n'a-t-il pas ennuyé vos clients?
Veuillez écrire un seul exemple par réponse.
Je suggérerais que l'idée fausse la plus courante de l'interface utilisateur est la suivante:
Que mes utilisateurs sont intéressés par mon application.
La plupart des utilisateurs ne sont pas du tout intéressés par votre application.
Dans la plupart des cas, si vos utilisateurs pouvaient remplacer votre application par un gros bouton rouge marqué "Go", ils le feraient. Et puis ils entraînaient un singe à appuyer sur le bouton encore et encore, rentraient chez eux et se détendaient.
Les utilisateurs ne sont pas intéressés par les applications. Ils sont intéressés à faire avancer les choses. Les applications ne sont qu'un moyen de parvenir à une fin.
"Mes utilisateurs sont d'autres développeurs de logiciels qui souhaitent être informés de chaque détail technique comme je le ferais."
:)
La croyance que les utilisateurs ne savent pas comment faire défiler (tout doit être au-dessus du pli).
Il y a une GRANDE collection de mythes sur l'expérience utilisateur à http://uxmyths.com/ avec de merveilleuses preuves à l'appui également. Je viens de trouver cela la semaine dernière.
"Tout devrait avoir des options"
Si j'utilise des coins arrondis dans ma conception, tout ira mieux.
Une chose qui m'agace - et qui est à l'origine de nombreux ennuis que vous verrez sur cette page - est que les organisations pensent qu'elles peuvent comprendre comment leurs clients utiliseront leur produit sans réellement amener leurs clients à utiliser leur produit!
Je suis étonné du nombre d'entreprises qui n'investissent toujours pas dans des tests d'utilisabilité rapides et bon marché de la guérilla. Passer une demi-journée et obtenir un peu de feedback leur ferait économiser un baril plein de douleur plus tard.
L'interface utilisateur est toujours GUI. Dans le sens où l'interface utilisateur ne doit pas être graphique.
Si je crée une interface utilisateur flashy/cool/colorée, les utilisateurs ne remarqueront pas à quel point l'application est vraiment terrible
"L'ajout de texte descriptif aidera l'utilisateur"
"Les utilisateurs sont des crétins. Ils n'utiliseront jamais cela."
Rendre quelque chose accessible aux personnes handicapées est difficile. De plus, aucun de nos visiteurs (utilisateurs) n'a de handicap.
Étant donné que d'autres le font, cela devrait signifier que c'est simplement mieux.
Quelque chose typiquement dans les projets où nous développons des logiciels pour remplacer les anciens logiciels, et quand je demande des spécifications, j'entends souvent:
"Il devrait fonctionner exactement de la même manière que dans notre ancien logiciel."
Je déteste quand les gens prennent ça comme une réponse. Je préfère répondre:
- Alors pourquoi développons-nous de nouveaux logiciels?
- Le but de ce projet n'était-il pas parce que nous étions mécontents de l'ancien logiciel?
- Pourquoi ne sommes-nous pas autorisés à le faire mieux que dans notre logiciel précédent?
Assistants non amortissables ou en général des interfaces utilisateur qui vous forcent à définir des étapes, mais vous interdisent d'interrompre ces étapes à certains points.
Je sais pourquoi il peut y avoir des raisons techniques pour une telle solution, mais il y a peu de choses qui me dérangent autant qu'un assistant ou une boîte de dialogue que j'ai par erreur entré qui me force à le terminer, ou à attendre n unités de temps pendant il termine une ou plusieurs de ses étapes.
L'installation d'applications sur Mac OS X en est parfois un parfait exemple.
Plus de couleurs == mieux
Dans une interface graphique, si l'utilisateur appuie sur un bouton un dixième de seconde après son apparition, l'utilisateur signifiait pour appuyer sur ce bouton.
Si le bouton est apparu comme un résultat direct de l'action de l'utilisateur, c'est probablement une hypothèse décente. Mais s'il est apparu en raison d'un événement asynchrone que l'utilisateur n'a pas déclenché, il est probable que l'utilisateur ait l'intention d'exploiter ce qui était à l'écran précédemment.
Si vous modifiez ce qui est à l'écran, n'activez pas les commandes tant que l'utilisateur n'a pas eu la possibilité de voir le nouvel écran.
"Mes utilisateurs sont comme moi (donc ce qui est évident pour moi le sera pour eux)."
"Nous devons à tout prix éviter le jargon, même lorsque la recherche montre que nos utilisateurs le comprennent et l’utilisent régulièrement à la place d’alternatives plus maladroites, ambiguës et plus difficiles à lire"
Que les utilisateurs connaissent ou même se soucient beaucoup des interfaces utilisateur ou des ordinateurs ou de la technologie ou de tout ce qui intéresse les concepteurs d'interface utilisateur. Ils veulent juste faire quelque chose sans se sentir misérable.
Le long de la ligne des "utilisateurs sont intéressés" est l'idée fausse que plus les gens voient du travail acharné que j'ai mis, mieux c'est. Je me rends compte, en tant que développeur de logiciels, que je dois justifier mon temps, et pouvoir montrer quelque chose à mon patron est utile, mais je sais aussi, en tant que développeur de logiciels intéressé par HCI, que le meilleur travail que je fais est le un travail que personne ne voit, qui a très peu d'impact sur l'utilisateur, qu'il remarque à peine.
Pour moi, le résultat le plus satisfaisant est quand je fais des jours de travail et que les utilisateurs ne sont au courant d'aucun changement, sauf que "les choses semblent mieux fonctionner maintenant". Lorsque l'utilisateur se concentre sur la réalisation de sa tâche réelle, cela permet une bonne conception de l'interface utilisateur. Lorsque l'accent est mis sur la quantité de travail que nous avons accompli, cela fait des cauchemars.
"Nos utilisateurs finaux sont des ingénieurs, ce sont des gars intelligents, ils n'auront aucun problème à comprendre comment cela fonctionne".
Le nombre de fois où j'ai entendu ça ...
Ce que je vois souvent, c'est que les développeurs pensent que moins vous devez cliquer sur le bouton de la souris pour accéder à une fonction, plus l'application est conviviale. Une conséquence directe est qu'autant d'éléments d'interface utilisateur et d'informations que possible sont placés sur l'écran principal de l'application.
L'interface utilisateur n'est pas importante. L'application doit être stable et fiable, c'est plus important.
Pour les sites Web/applications, etc., etc.
Les liens (ancres) doivent aller quelque part (aller à l'écran utilisateur) et les boutons doivent faire quelque chose (mettre à jour les informations, etc.).
Pour forcer les utilisateurs à effectuer des actions dans un seul sens (généralement les concepteurs de logiciels).
Idée fausse:
- Si le sous-menu volera en survolant le menu principal, ou je dois cliquer dessus.
Ne donnant aucune indication sur les règles appliquées pour votre mot de passe.
Si vous me rappelez qu'il devait y avoir au moins huit caractères avec deux chiffres, je saurai lequel j'ai utilisé. Sinon, je vais devoir en utiliser tous les possibles jusqu'à ce que je comprenne enfin.
Il est normal que lors de l'ajout de fonctionnalités à l'application, l'interface utilisateur devienne plus complexe.
La version 1.0 peut être exécutée sur 800 * 600 La version 2.0 nécessite 1024 * 768 La version 3.0 nécessite 1920 * 1200
Parfaitement OK. De plus, les écrans deviennent de plus en plus grands.
En fait, j'ai entendu un chef de produit dire: "Avec l'application de plus en plus complexe, il est normal que l'interface utilisateur devienne également plus complexe."
Scénario: un développeur crée un formulaire qui, selon les cases cochées, certaines actions auront lieu. Alors qu'une personne devra faire une pause pour examiner l'impact de ses sélections, le développeur estime que le formulaire est simple, car il n'a que quelques options à sélectionner, et les étiquettes de texte dans le formulaire semblent rationnelles pour lui.
Idées fausses des développeurs:
(1) le chemin le plus court pour le développeur pour obtenir le formulaire sur la page et le faire fonctionner s'avère justement être le meilleur moyen de présenter le formulaire à l'utilisateur
(2) le formulaire aurait du sens pour les autres développeurs avant même que je ne leur explique
(3) quand j'ai fait une démo du formulaire, c'était assez clair pour tout le monde, même si c'était moi qui faisais tous les clics et expliquais
(4) le formulaire aurait du sens pour n'importe qui; en fait, tu serais idiot si tu ne le comprenais pas
(5) les utilisateurs ont une puce dans leur cerveau qui joue un .mp3 du processus de pensée que le développeur a utilisé pour créer le formulaire; ils jouent chaque fois qu'ils se demandent ce que signifient précisément les implications de leurs sélections, car cela n'est expliqué nulle part ailleurs
L'interface utilisateur doit être testée ainsi que les fonctionnalités.
Mais le test doit être effectué par des utilisateurs finaux non impliqués dans la définition technique du projet. Dans mes projets, j'ai souvent remarqué que les applications sont testées par des personnes qui ont aidé à les concevoir afin qu'elles aient déjà une connaissance utilisateur "habituée".
Et quand c'est possible, vous devez être un utilisateur de votre propre application! (vous pourriez alors remarquer quelques problèmes avec l'utilisation quotidienne)
"Lotus Notes le fait aussi comme ça, donc c'est bien".