Les règles d’or du design d’interface (2013)

Les huit règles d’or du design d’interface

• Rechercher la cohérence : dans des situations similaires, la même séquence d’actions doit être requise, et il faut utiliser de façon uniforme les mêmes termes dans les invites, les menus et les écrans d’aide, ainsi que des couleurs, mises en page, usages des majuscules/minuscules et polices cohérents dans l’ensemble.
• Rechercher une utilisabilité universelle : il faut reconnaître les besoins de divers utilisateurs et concevoir en tenant compte des débutants comme des experts, des tranches d’âge, du handicap, des différences internationales et de la diversité technologique.
• Fournir un retour d’information utile : l’interface doit fournir un retour pour chaque action de l’utilisateur ; pour les actions fréquentes et mineures, une réponse simple suffit, tandis que pour les actions rares et importantes, une réponse plus approfondie est nécessaire.
• Offrir une sensation d’achèvement grâce à un design dialogué : il faut organiser les séquences d’actions en groupes et, grâce à un retour sur l’achèvement de chaque groupe, procurer à l’utilisateur un sentiment d’accomplissement et de soulagement.
• Prévenir les erreurs : l’interface doit être conçue pour empêcher l’utilisateur de commettre des erreurs graves et, lorsqu’une erreur survient, fournir des consignes de récupération simples et précises.
• Permettre un retour en arrière facile des actions : il faut permettre autant que possible d’annuler les actions afin d’encourager les utilisateurs à explorer de nouvelles options sans craindre de se tromper.
• Maintenir le contrôle de l’utilisateur : les utilisateurs expérimentés veulent que l’interface réagisse à leurs actions et que les comportements familiers ne changent pas ; ils ressentent de la frustration lorsqu’il est difficile d’obtenir les informations nécessaires ou le résultat souhaité.
• Réduire la charge de la mémoire à court terme : comme la quantité d’informations que les personnes peuvent traiter dans leur mémoire à court terme est limitée, il faut éviter les interfaces où l’utilisateur doit mémoriser des informations d’un écran pour les utiliser sur un autre.

L’avis de GN⁺

• Cet article présente les principes fondamentaux du design d’interface proposés par Ben Shneiderman, et ces principes constituent un bon point de départ pour les designers mobile, desktop et web.
• Ces principes, qui visent à améliorer l’expérience utilisateur, aident les utilisateurs à mieux comprendre le système et à l’utiliser plus efficacement.
• Cet article fournit des repères utiles aux ingénieurs logiciel débutants lorsqu’ils conçoivent des interfaces conviviales.

[GN⁺]

Commentaires sur Hacker News

• Les performances ne font pas partie du design de l’UI, mais elles sont souvent négligées. Une UI lente enfreint tous les principes de design.

  • Par exemple, les smart TV Android de Sony ont l’air élégantes, mais leur UI est tellement lente qu’elles sont pénibles à utiliser.

• Une UI instable et qui change souvent enfreint elle aussi la plupart des principes. Les smart TV sont particulièrement mauvaises dans ce domaine, avec des dispositions d’écran d’accueil et des icônes d’apps qui changent fréquemment sans raison.

• Les icônes sans libellé (parfois même sans infobulle) sont un problème de plus en plus grave. Si vous devez chercher sur Google pour savoir à quoi sert un bouton, c’est que le design de l’UI est mauvais.

• Explication de l’importance de la cohérence.

  • Il ne s’agit pas de rechercher des détails précis comme une palette de couleurs limitée ou le choix d’une police discrète.
  • Il s’agit de permettre à l’utilisateur de maîtriser le logiciel avec aisance.
  • Microsoft Office et (Neo)Vim ne sont pas des exemples exceptionnels d’UI, mais ils sont uniques par leur stabilité.

• Il est important de transmettre clairement à l’utilisateur le modèle conceptuel.

  • Si l’on ne comprend pas le modèle conceptuel du produit, on restera toujours perdu, même si les icônes sont bien libellées.
  • L’UI doit être conçue pour que l’utilisateur puisse déduire le modèle conceptuel en explorant l’interface.

• Lorsqu’un utilisateur saisit un mauvais code postal, il faut l’amener à corriger uniquement la partie erronée, sans lui faire ressaisir tout le formulaire nom-adresse.

  • Cela devrait aussi s’appliquer lorsqu’on remplit un formulaire sur plusieurs pages.
  • Une action incorrecte ne devrait pas modifier l’état de l’interface, ou alors il faut fournir des indications sur la manière de rétablir cet état.

• Au lieu de désactiver des éléments de menu, il faut afficher un message d’erreur expliquant pourquoi la commande n’est pas disponible lorsque l’utilisateur clique dessus.

  • Devoir comprendre pourquoi une commande a été désactivée peut être très frustrant pour l’utilisateur.

• Les 10 heuristiques d’utilisabilité de Nielsen fournissent de bonnes lignes directrices pour le design d’UI.

  • Elles incluent la visibilité de l’état du système, la correspondance avec le monde réel, le contrôle et la liberté de l’utilisateur, la cohérence et les standards, la prévention des erreurs, la reconnaissance plutôt que la mémorisation, la flexibilité et l’efficacité d’utilisation, le design minimaliste, l’identification et la récupération des erreurs, ainsi que l’aide et la documentation.

• Depuis 2013, la cohérence a commencé à se dégrader, et avec l’arrivée des UI basées sur CSS, chaque site et application implémente sa propre UX.

  • La « navigation mystery meat », critiquée par la communauté UX lors de la mode de Flash au début des années 2000, a fait son retour.

• Faire apparaître soudainement autre chose à la place de l’élément que l’utilisateur essaye de sélectionner, provoquant ainsi une mauvaise sélection, est une erreur particulièrement grave.

• Les éléments d’interface ne devraient pas bouger de manière inattendue une fois l’interface affichée.

  • Google est particulièrement fautif sur ce point, sans être un cas isolé.

• Discussion sur ces règles d’or manifestement utopiques.

  • La plupart des développeurs ont déjà travaillé sur des interfaces qui enfreignent fréquemment ces règles.
  • Ce n’est pas parce qu’ils ne les comprennent pas, mais parce que le coût était trop élevé à ce moment-là.
  • Par exemple, une fonction d’annulation n’est possible que si les structures de données sous-jacentes de l’application ont été conçues dans cette optique. Prévenir les erreurs est également difficile, car il est compliqué de définir précisément ce qu’est une erreur, et fournir un retour parfait dans la langue de l’utilisateur est encore plus complexe.