Faisons revivre le design idiomatique

• Les idiomes de design immédiatement compréhensibles par l’utilisateur réduisent la charge d’apprentissage et permettent des interactions cohérentes
• À l’époque des logiciels de bureau, les interfaces étaient unifiées — structure des menus, raccourcis, etc. — grâce aux systèmes d’exploitation et à leurs guidelines
• En revanche, à l’ère des logiciels basés sur le navigateur, la généralisation des frameworks et des implémentations sur mesure a entraîné un effondrement de la cohérence des interfaces
• Apple et Substack montrent, avec une personnalisation limitée et des systèmes de design unifiés, des exemples réussis d’idiomes modernes
• Les concepteurs de produits devraient suivre les idiomes existants et donner la priorité à la clarté et à la cohérence afin d’aller vers une expérience utilisateur standardisée sur l’ensemble du web

---

Idiomes de design

• La case à cocher est présentée comme un idiome de design représentatif, que l’utilisateur comprend immédiatement sans apprentissage particulier
  • Pour demander s’il faut rester connecté, de nombreux modes de saisie seraient possibles, mais en pratique on utilise toujours une case à cocher
  • Elle fonctionne comme un modèle d’interaction standardisé familier à la fois pour les utilisateurs et pour les développeurs

Interfaces homogènes

• L’interface est le moyen par lequel l’utilisateur interagit avec un système, et moins elle demande de réflexion, meilleure elle est
  • Par exemple, la fonction de copie via le raccourci Command+C devrait fonctionner de la même façon partout
• Pourtant, dans l’environnement logiciel web actuel, la cohérence des interfaces a disparu
  • Même des fonctions de base comme le choix d’une date ou la saisie d’un numéro de carte sont implémentées différemment selon les sites
  • Les raccourcis et les modes d’interaction varient d’une application à l’autre, si bien que l’utilisateur doit réapprendre à chaque fois « où cliquer et quoi faire »

L’ère des logiciels de bureau

• Les logiciels de bureau de l’époque Windows 95 à 7 conservaient une forte cohérence d’interface
  • La structure de menu « File, Edit, View » existait à l’identique dans tous les programmes
  • Les éléments soulignés dans les menus indiquaient des raccourcis clavier, utilisables via ALT+F, N, etc.
  • La barre d’état (status bar) en bas affichait clairement l’état courant (page, nombre de mots, mode, etc.)
  • Les menus textuels étaient au centre de l’interface, les icônes n’étant utilisées que lorsqu’elles avaient une signification claire
• Ces idiomes étaient uniformes non seulement dans Microsoft Word, mais dans tout l’écosystème Windows
  • Même sur l’écran de déconnexion de Windows XP, tous les boutons étaient visuellement identifiables comme des boutons et les raccourcis y étaient indiqués
• Cette cohérence était rendue possible par les contraintes du système d’exploitation et des bibliothèques GUI, et Microsoft distribuait des guidelines de design de plusieurs centaines de pages pour inciter les développeurs à les suivre

L’ère des logiciels dans le navigateur

• L’époque actuelle des applications web est décrite comme celle des interfaces hétérogènes
  • Même d’excellentes web apps comme Figma et Linear n’ont ni icônes ni raccourcis communs
  • Chaque application est bien conçue en elle-même, mais adopte des modèles d’interaction différents
  • Même au sein d’une même entreprise, l’expérience diffère entre Gmail, GSuite et Google Docs
  • En conséquence, l’utilisateur passe son temps non pas dans un flux de travail productif (flow), mais à chercher où agir

• Impact du basculement vers le mobile

  • L’arrivée des écrans tactiles a conduit à réinventer les modèles de design centrés sur la souris et le clavier
  • Le besoin de prendre en charge à la fois mobile et bureau a favorisé la diffusion d’interfaces incomplètes, de type intermédiaire
  • Exemple : le menu hamburger conçu pour le mobile est repris tel quel sur desktop
  • La culture de réutilisation de composants modulaires a répliqué de mauvais modèles et entraîné une baisse de qualité
  • Le résultat cumulé de plus de dix ans est une érosion générationnelle de la qualité UI/UX

• Le manque d’idiomes au-delà du HTML

  • Aux débuts du web, il existait des idiomes clairs comme les liens bleus soulignés, mais aujourd’hui chaque site a son propre style
  • Les standards HTML/CSS sont stricts, mais dans la pratique la plupart utilisent des systèmes de build basés sur React et TypeScript
  • En conséquence, les implémentations personnalisées prolifèrent à la place des éléments HTML standard, avec en plus des problèmes d’accessibilité
  • Exemple : utiliser un <span> avec un onclick au lieu d’un <a> casse le fonctionnement des lecteurs d’écran
  • Il existe aussi des applications comme Figma, basées sur WebAssembly, qui sortent complètement du HTML
  • Les fonctions natives du navigateur — bouton retour, raccourcis, etc. — sont ignorées, et un nouveau paradigme d’interaction homme-machine est recomposé
  • Le développement frontend ayant évolué avec une priorité donnée à la vitesse et aux possibilités, il est devenu difficile de faire émerger des idiomes cohérents
  • La multitude de frameworks et de formats d’interaction rend structurellement difficile l’établissement d’un standard unique

Exemples réussis de design idiomatique

• Apple est cité comme un exemple emblématique de marque qui maintient encore aujourd’hui de forts idiomes de design
  • La police, les boutons, les couleurs et plus largement le système de design sont unifiés, offrant une expérience d’interaction cohérente dans tout iOS
  • Cette cohérence nourrit la confiance associée au « it just works »
• Substack offre lui aussi une expérience utilisateur stable grâce à une personnalisation limitée et à des valeurs esthétiques par défaut prédéfinies
  • Les principes de design d’Apple et de Substack, validés par leur succès, se diffusent comme standards de l’industrie et finissent par devenir de nouveaux idiomes

Principes à suivre pour les concepteurs produit

• Pour les équipes produit, suivre autant que possible les idiomes de design existants est présenté comme le meilleur moyen d’améliorer l’utilisabilité et la compatibilité
  • Respecter les idiomes de base du HTML/CSS : un lien doit être implémenté avec soulignement, couleur, curseur pointeur et la balise <a>
  • Ne pas réimplémenter en JavaScript les éléments HTML natifs, par exemple utiliser <button> plutôt qu’un React Button
  • Respecter les idiomes du navigateur : le bouton retour doit fonctionner, copier l’URL doit permettre d’accéder à la même interface, CTRL+clic doit ouvrir un nouvel onglet
  • Si l’on s’écarte d’un idiome courant, il faut au moins conserver des règles cohérentes en interne à l’organisation
  • Le texte d’abord, les icônes au minimum ; les icônes ne devraient être utilisées que lorsqu’elles sont universellement compréhensibles
  • Pour les éléments visuels, la clarté doit primer sur la beauté esthétique
  • En cas de doute, s’inspirer de bons exemples de sites web et de livres anciens sur le design d’interface
• En définitive, l’objectif est un futur où les sélecteurs de date et les formulaires de saisie de carte fonctionnent de la même manière partout sur le web, avec pour horizon un environnement web convergeant vers des idiomes optimaux après des décennies de répétition et d’amélioration