4 points par GN⁺ 2024-01-11 | 1 commentaires | Partager sur WhatsApp
  • Les 8 principes de conception d’interface de Ben Shneiderman sont des critères pratiques applicables à la plupart des systèmes interactifs, mais ils nécessitent validation et ajustement selon chaque domaine de conception
  • Une terminologie et des comportements cohérents, une utilisabilité universelle et un feedback informatif sont des conditions de base pour permettre aux utilisateurs d’anticiper et de comprendre les changements d’état
  • Les flux de travail doivent être regroupés en unités avec un début, un milieu et une fin ; fournir une confirmation claire au moment de l’achèvement aide l’utilisateur à passer à l’action suivante
  • La prévention des erreurs est prioritaire ; lorsqu’elles surviennent, des instructions de récupération concrètes et une annulation facile doivent réduire l’anxiété de l’utilisateur
  • En plaçant le sentiment de contrôle et la faible charge de mémorisation au centre, on peut accroître la productivité et le sentiment de maîtrise dans les interfaces mobiles, desktop et web

Nature des principes et périmètre d’application

  • Ben Shneiderman a condensé un vaste corpus de connaissances sur la conception d’interfaces utilisateur en quelques Golden Rules, formulées comme des lignes directrices applicables à la plupart des systèmes interactifs
  • Ces principes sont issus de l’expérience et ont été affinés pendant plus de 30 ans, mais certains domaines de conception nécessitent une validation et un ajustement spécifiques
  • La liste initiale de 1985 a elle aussi été adoptée comme un ensemble de recommandations utiles pour les étudiants et les designers, puis Jakob Nielsen, Jeff Johnson et d’autres y ont apporté des variantes et des extensions
  • Cette version provient de la section 3.3.4 de Designing the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Edition

Les 8 règles d’or de la conception d’interface

  • Rechercher la cohérence

    • Dans des situations similaires, une séquence d’actions cohérente est nécessaire
    • Les invites, menus et écrans d’aide doivent employer les mêmes termes
    • Les couleurs, la mise en page, l’usage des majuscules et les polices doivent également rester cohérents dans l’ensemble
    • Les exceptions, comme la confirmation d’une commande de suppression ou le masquage de la saisie d’un mot de passe, doivent être compréhensibles et limitées
  • Viser une utilisabilité universelle

    • Il faut reconnaître les besoins d’utilisateurs variés et concevoir avec suffisamment de flexibilité pour faciliter la transformation du contenu
    • Les différences entre débutants et experts, les tranches d’âge, les handicaps, les différences internationales et la diversité des technologies élargissent le périmètre des exigences
    • Les explications pour débutants, les raccourcis et fonctions d’exécution rapide pour experts améliorent la perception de la qualité de l’interface
  • Fournir un feedback informatif

    • Toute action de l’utilisateur doit être suivie d’un feedback de l’interface
    • Pour les actions mineures et fréquentes, une réaction simple suffit ; pour les actions rares et importantes, une réponse plus substantielle est nécessaire
    • Présenter visuellement l’objet d’intérêt facilite la mise en évidence claire des changements
  • Concevoir des dialogues qui donnent un sentiment d’achèvement

    • Les séquences de tâches doivent être organisées en groupes ayant un début, un milieu et une fin
    • Le feedback informatif fourni à la fin d’un groupe de tâches donne un sentiment d’accomplissement, de soulagement et un signal de préparation pour la tâche suivante
    • Sur un site d’e-commerce, un exemple est le flux qui mène du choix du produit au paiement, puis conclut la transaction par une page de confirmation claire
  • Prévenir les erreurs

    • Dans la mesure du possible, l’interface doit être conçue pour empêcher l’utilisateur de commettre des erreurs graves
    • Par exemple, désactiver des éléments de menu inappropriés ou empêcher la saisie de lettres dans un champ numérique
    • Lorsqu’une erreur se produit, il faut fournir des instructions de récupération simples, constructives et concrètes
    • Il ne faut pas obliger l’utilisateur à ressaisir tout un formulaire de nom et d’adresse à cause d’un seul code postal incorrect ; il faut l’orienter vers la correction de la seule partie erronée
    • Une action incorrecte ne doit pas modifier l’état de l’interface, ou doit s’accompagner d’un moyen de restaurer l’état précédent
  • Permettre une annulation facile

    • Dans la mesure du possible, les actions doivent pouvoir être annulées
    • L’annulation rassure l’utilisateur en lui donnant la certitude qu’il peut corriger une erreur, réduit son anxiété et l’encourage à explorer des options inconnues
    • L’unité d’annulation peut être une action unique, une tâche de saisie de données ou un groupe de tâches comme un bloc nom-adresse
  • Maintenir l’utilisateur aux commandes

    • Les utilisateurs expérimentés veulent fortement sentir qu’ils contrôlent l’interface et que celle-ci réagit à leurs actions
    • Les changements inattendus, la modification d’actions familières, la saisie de données fastidieuse, la difficulté à obtenir les informations nécessaires ou l’impossibilité d’obtenir le résultat souhaité mettent l’utilisateur mal à l’aise
  • Réduire la charge de la mémoire à court terme

    • La capacité de traitement de l’information de la mémoire à court terme humaine est limitée ; selon une règle empirique, elle peut retenir environ « 7±2 chunks »
    • Il faut éviter les interfaces qui obligent l’utilisateur à mémoriser des informations sur un écran pour les utiliser sur un autre
    • Un téléphone mobile ne devrait pas demander de ressaisir un numéro de téléphone, la position sur un site web doit rester visible, et les longs formulaires doivent être condensés pour tenir sur un seul écran

Repères pratiques pour les concepteurs

  • Ces principes doivent être interprétés, affinés et étendus en fonction de chaque environnement
  • Malgré leurs limites, ils constituent un bon point de départ pour les designers mobile, desktop et web
  • La saisie de données simplifiée, les affichages compréhensibles et un feedback rapide et informatif visent à augmenter la productivité des utilisateurs
  • Une bonne interface doit aider l’utilisateur à ressentir compétence, maîtrise et contrôle face au système

1 commentaires

 
GN⁺ 2024-01-11
Avis sur Hacker News
  • On considère souvent que cela ne fait pas forcément partie du « design » d’une UI, mais les performances sont elles aussi fréquemment négligées
    Une UI lente enfreint en pratique toutes ces règles de design. Ma smart TV Sony Android a une apparence superbe, mais son UI est tellement lente qu’elle en devient pratiquement inutilisable
    Une UI instable qui change en permanence viole elle aussi la plupart de ces principes. Les smart TV sont particulièrement mauvaises sur ce point : la disposition de l’écran d’accueil et la position des icônes d’app changent souvent sans raison apparente
    Et, de plus en plus, mon grief personnel est les icônes sans libellé. Souvent, il n’y a même pas d’infobulle, et si je dois googler la documentation pour savoir comment s’appelle un bouton, alors le design de cette UI est mauvais

    • Depuis que Snapchat est devenu extrêmement populaire, j’en suis venu à penser qu’une mauvaise UI était une fonctionnalité Gen Z
      Les jeunes se ruent sur des interfaces difficiles à utiliser, et cette opacité fonctionne comme un marqueur d’initié qui exclut la génération des parents
    • Les performances font partie du design
      Un bon designer discute avec les développeurs de l’impact sur les performances de l’UI qu’il propose, et aide à arbitrer quand l’ingénierie prend des décisions techniques visibles par l’utilisateur
    • Côté icônes sans libellé, le pire logiciel que j’aie utilisé était CATIA V5
      Non seulement l’UI contenait des centaines de petites icônes, mais la documentation réutilisait aussi ces mêmes icônes telles quelles. Le manuel disait des choses du genre : « cliquez d’abord sur [], puis appuyez sur [], et enfin allez sur [] pour faire [] »
      Je parle des toutes premières versions de V5, donc c’était il y a longtemps ; j’espère que cela s’est amélioré depuis
    • La principale cause des échecs de design UI, c’est l’isolement vis-à-vis des utilisateurs et des exigences
      Tout le reste relève presque du codage
    • Spotify change lui aussi souvent la disposition de l’écran d’accueil et la position des icônes d’app
      J’écoute les mêmes deux podcasts d’actualité tous les matins, mais les recommandations de l’app sont mélangées sans raison chaque matin
      Ce qui est encore plus agaçant, c’est qu’au démarrage l’app affiche brièvement la disposition de la veille, se fige environ une seconde le temps de charger, puis réorganise les éléments. À ce moment-là, j’appuie presque toujours sur l’élément en train de bouger par erreur, et c’est extrêmement frustrant
  • Un designer avec qui j’ai travaillé il y a quelques années m’a brillamment expliqué pourquoi la cohérence est importante
    Ce n’est pas une question de palette de couleurs limitée ou de choix de police que personne ne remarquera. À poursuivre des règles de détail, on finit avec un logiciel affreux. Certaines personnes s’imaginent à tort que moins il y a de variété dans une UI, plus elle est cohérente
    L’essentiel, c’est de permettre à l’utilisateur de devenir expert de ce logiciel
    Ce designer prenait Microsoft Office comme exemple. Les gens sont fiers de « connaître » Microsoft Office, et comme ils ressentent l’inertie propre à « Office », ils passent naturellement d’une app à l’autre. J’ai exactement la même sensation avec Vim. On sait simplement comment quelque chose est censé fonctionner, et un nouveau plugin bien conçu respecte généralement ces schémas
    Office et (Neo)Vim ne sont pas forcément des exemples d’UI exceptionnelles, mais ils sont remarquablement stables

    • Je ne suis pas designer, mais j’insiste toujours sur la puissance qu’il y a à amorcer la maîtrise en s’appuyant sur des éléments et concepts d’UI que les utilisateurs ont déjà appris ailleurs
      Par exemple, pour présenter quatre options, on peut utiliser une combobox de cases à cocher avec recherche issue de [Insert UI Library], relookée aux couleurs de la marque, ou simplement afficher des boutons radio ou des cases à cocher ordinaires avec des libellés. La seconde solution est meilleure à tous points de vue
      Rien qu’en voyant des cercles et des carrés, l’utilisateur sait s’il faut choisir une seule option ou plusieurs, il peut voir les quatre options d’un coup, le clavier mobile ne s’affiche pas pour « rechercher » en masquant davantage le petit écran, et l’accessibilité est presque toujours proche de 100 %
      Mais cette option échoue au critère « ça s’accorde joliment avec notre design system », donc les designers choisissent généralement la première, et pire encore, ils standardisent cette approche au point de transformer l’usage de widgets ordinaires en « bug »
      Au final, beaucoup trop de « UX designers » vouent un culte à l’esthétique et au branding au détriment de tout le reste. Les widgets d’UI ne sont pas l’endroit où exprimer une marque ou de la créativité. C’est comme fabriquer une police maison qui forcerait toutes les lettres à ressembler à un logo. Les clients se soucient davantage de pouvoir terminer leur travail que de la marque
    • Cela explique peut-être en partie pourquoi tant de gens se sont énervés quand Microsoft a introduit le ruban adaptatif, censé « aider » en n’affichant que les options les plus plausibles
      Cela a fortement dégradé la capacité à trouver les fonctions dont on a besoin
    • La formule selon laquelle il faut permettre à l’utilisateur de devenir expert du logiciel est vraiment excellente
      Voir quelqu’un qui ne se considère pas comme technique aller incroyablement vite dans Excel est toujours impressionnant
      Les règles de design UI de Microsoft sont assez remarquables. Grâce à des années de cohérence, les gens peuvent continuer à utiliser le logiciel même en ne faisant des mises à niveau que tous les 1 ou 2 ans. Je ne dis pas ça en fan de Microsoft
      Le cœur d’une mise à niveau, ce sont des changements progressifs qui améliorent l’UX. En revanche, je ne comprends pas pourquoi l’équipe design n’a pas rejeté l’idée introduite par Win 95 selon laquelle « un clic droit partout donne accès aux propriétés et à des réglages plus profonds / informations détaillées ». C’était une fonctionnalité invisible, qui n’indiquait pas à l’utilisateur où un clic droit était possible. J’ai l’impression que lors des premières utilisations de Win 95, personne ne comprenait le clic droit
    • Je conçois des langages de programmation, donc je réfléchis à ce genre de questions tous les jours
      Je suis d’accord sur l’importance de la maîtrise, mais il manque peut-être un maillon pour expliquer pourquoi la cohérence mène à cette maîtrise
      La cohérence, c’est faire fructifier de manière cumulative ce que les utilisateurs savent déjà du système vers d’autres parties du système. Si un système est cohérent, l’effort investi pour apprendre X et Y permet aussi de connaître Z et W, parce qu’ils fonctionneront de la même manière. Dans un système incohérent, la valeur tirée de cet investissement d’apprentissage antérieur chute considérablement
    • Je suis d’accord sur l’importance de la cohérence, mais pas avec l’idée que « Office et (Neo)Vim ne sont pas des UI exceptionnelles, mais sont remarquablement stables »
      Office n’est pas stable, du moins pas sur le long terme. Le tristement célèbre ruban a été une triste rupture avec l’UI de Word, qui était stable et efficace, et les régressions incompréhensibles de Microsoft sur l’ensemble de la plateforme Windows ont encore aggravé le problème. Par exemple, supprimer la barre de menus des applications. Je n’ai jamais compris pourquoi
  • Une « règle » supplémentaire qui mériterait d’être ajoutée est de rendre visible le modèle conceptuel à l’utilisateur
    Si l’on ne comprend pas le modèle conceptuel du produit, même des icônes parfaitement étiquetées restent source de confusion. Par exemple, imaginons un produit avec une commande « New Configuration » : déjà, on ne sait pas clairement ce qu’est une « Configuration ». Est-ce un modèle qui permet de définir un autre objet ? Un moyen de basculer rapidement entre plusieurs groupes d’options ? Un conteneur comme un dossier ?
    L’UI devrait être conçue de façon à ce que l’utilisateur puisse déduire le modèle conceptuel simplement en explorant l’interface. Ce n’est pas toujours facile

    • Le but d’une bonne interface est de masquer les détails d’implémentation tout en guidant l’utilisateur vers son objectif
  • Le passage disant qu’« en cas de code postal invalide, il ne faut pas forcer l’utilisateur à ressaisir tout le formulaire nom-adresse, mais seulement corriger la partie erronée » est pour moi le plus gros point de frustration, et on le voit encore très souvent
    Ce principe devrait aussi être respecté dans les formulaires en plusieurs pages quand on navigue d’avant en arrière
    Le point « une action invalide ne doit pas modifier l’état de l’interface, et si elle l’a modifié, il faut indiquer comment revenir à l’état initial » est également important
    Sur les petits écrans comme les téléphones et les montres, les designers cherchent de plus en plus à économiser l’espace en s’appuyant davantage sur les icônes. Mais beaucoup d’icônes sont peu familières ou difficiles à interpréter, et parfois il faut appuyer dessus pour comprendre. Ces icônes devraient impérativement offrir un moyen de revenir à l’état initial en cas d’erreur

    • Exact. Si on saisit « Corvallis », il suffit de demander « Oregon ou Montana ? », et si on a saisi « 97330 », on peut simplement ignorer le reste
    • C’est vraiment agaçant
      C’est déjà pénible quand on essaie de se connecter avec son adresse e-mail et son mot de passe, mais si on clique sur « Mot de passe oublié », on ne devrait pas être envoyé vers un formulaire qui redemande l’adresse e-mail qu’on vient juste de saisir
  • La recommandation « grisez les éléments de menu inadaptés » a ses conditions
    Si la raison pour laquelle c’est grisé n’est pas évidente, il ne faut pas le faire. Il vaut mieux laisser la commande active et, si l’on clique dessus alors qu’elle n’est pas disponible dans le contexte actuel, afficher un message d’erreur expliquant pourquoi. Obliger l’utilisateur à deviner pourquoi une commande est désactivée est frustrant
    L’exception, c’est quand il y a de fortes chances que l’utilisateur perde beaucoup de temps avant d’apprendre au bout du compte qu’elle n’est pas disponible
    À lire aussi : https://medium.com/@vedranio/james-bond-and-the-design-of-di...

    • Pourquoi ne pas griser l’élément de menu tout en affichant le même message explicatif au clic ?
      Ça semble combiner les avantages des deux approches
    • Il faut malgré tout un indice visuel cohérent pour indiquer avant le clic que l’action est désactivée
    • Il y a une exception : les fonctionnalités premium payantes
      Une application de tâches fait ça. Les commandes premium ne sont pas visuellement distinguées des commandes gratuites, donc on clique souvent dessus, et à chaque fois cela interrompt tout le flux avec une boîte de dialogue incitant à s’abonner
      Pour moi, c’est une grave erreur d’UI
    • Pourquoi ne pas griser le bouton, avec un tooltip au survol pour expliquer pourquoi il n’est pas cliquable ?
    • Je ne suis pas d’accord. Désactiver une action impossible dans le contexte actuel est utile. Mais il faut expliquer pourquoi
      Une UI qui désactive certaines actions sans en donner la raison me met toujours en colère
  • Les 10 heuristiques d’utilisabilité de Nielsen constituent un excellent cap

    1. Visibilité de l’état du système
    2. Correspondance entre le système et le monde réel
    3. Contrôle et liberté de l’utilisateur
    4. Cohérence et standards
    5. Prévention des erreurs
    6. Reconnaissance plutôt que mémorisation
    7. Flexibilité et efficacité d’utilisation
    8. Design esthétique et minimaliste
    9. Reconnaissance, diagnostic et récupération des erreurs
    10. Aide et documentation
      https://www.nngroup.com/articles/ten-usability-heuristics/
    • La différence entre cette page de Nielsen-Norman et la page d’origine est frappante
      La page NN est beaucoup plus facile à assimiler, plus concise, et sa mise en page est bien meilleure
      Les deux textes contiennent des informations et des orientations à écouter, mais il est ironique que la page d’origine adopte ces anciennes conventions de même taille de police et de paragraphes que la page NN a abandonnées
      C’est aussi frustrant que Hacker News n’applique pas certains de ces principes. Quand on modifie un message existant, après avoir cliqué sur le bouton « update », le retour n’est pas assez clair. J’imagine que la page est rechargée
  • Il faut arrêter avec les UI qui provoquent des clics involontaires en insérant autre chose exactement à l’endroit que j’allais sélectionner
    C’est peut-être une violation de certaines règles précédentes, ou un problème qu’on peut atténuer, mais personnellement c’est quelque chose qui me rend fou, et je considère ça comme une erreur particulièrement grave

    • Ça me fait surtout penser au choix Unassigned/Automatic qui apparaît quand on veut changer l’assigné d’une story dans Jira
  • Il manque une règle importante. À une époque, elle paraissait tellement évidente : il faut distinguer l’information statique des éléments interactifs
    De plus, les éléments interactifs qui ne s’appliquent pas ne doivent pas être cachés, mais grisés. Ainsi, l’utilisateur apprend que cette fonctionnalité existe, où elle se trouve, et quelles conditions il doit remplir pour pouvoir l’utiliser
    À ce sujet, il ne faut jamais dépendre d’une UI cache-cache où quelque chose n’apparaît que lorsque l’utilisateur passe le curseur dessus par hasard. Le but est de terminer son travail, pas d’explorer un calendrier de l’Avent

  • Une règle d’or que j’ai apprise est qu’une fois l’interface affichée, les éléments ne doivent pas se déplacer de manière inattendue
    Google est particulièrement mauvais sur ce point, avec des boutons qui bougent entre le moment où on lève le pouce et celui où on touche l’écran, mais Google n’est pas le seul

    • J’aimerais que cela soit géré au niveau du système d’exploitation
      Si la cible est apparue moins de 0,25 seconde avant d’être touchée, aucun événement tactile ne devrait être généré. Vu le temps de réaction humain, on ne peut pas viser et appuyer volontairement sur un bouton aussi vite
  • Ce sont clairement des règles d’or utopiques
    La plupart des gens ne s’opposeront pas à ce type de règles.
    Pourtant, la plupart des développeurs ont déjà eu affaire à des interfaces qui enfreignent souvent ces règles. Ce n’est pas parce qu’ils ne les comprenaient pas ou n’en voulaient pas, mais parce que le coût, à ce moment-là, était trop élevé.
    Par exemple, la possibilité d’annuler est très difficile à mettre en œuvre, et elle n’est possible que si les structures de données sous-jacentes de l’application ont été conçues dès le départ dans cette optique. Il en va de même pour la prévention des erreurs : savoir précisément ce qui constitue une erreur est en soi difficile et coûteux, et fournir un retour parfaitement formulé dans la langue de l’utilisateur est encore bien plus complexe.