Faisons revivre le design idiomatique

 (essays.johnloeber.com)
1 points par GN⁺ 21 일 전 | 1 commentaires | Partager sur WhatsApp
  • 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

À lire aussi

1 commentaires

 
GN⁺ 21 일 전
Commentaires sur Hacker News

  • Dans certaines applis, Enter envoie le message et Ctrl+Enter fait un retour à la ligne (ex. : Slack), ailleurs c’est l’inverse (ex. : GitHub).
    Ce manque de cohérence est assez déroutant du point de vue des utilisateurs. On dit souvent « ramenons le design idiomatique », mais le vrai problème est justement l’absence d’idiomes communs.

    • Autrefois, Return et Enter étaient deux touches distinctes. Return servait au retour à la ligne, Enter à la validation de l’entrée.
      Aujourd’hui, les deux ont fusionné en une seule touche et, en général, dans les champs de saisie multilignes, Enter fait un retour à la ligne et Ctrl+Enter envoie.
      À l’inverse, les applis de chat manipulent surtout des messages courts, donc le comportement est souvent inversé. Les bonnes applis permettent de changer cela dans les réglages.
    • Teams propose deux modes. Par défaut, Enter envoie et Shift+Enter fait un retour à la ligne, mais si on ouvre les outils de mise en forme, cela s’inverse.
      La combinaison pour le retour à la ligne est bien indiquée, mais cela reste confus.
    • Slack est encore plus compliqué. Avec Markdown activé, Shift+Enter fait un retour à la ligne, mais dans un bloc de code (```), Enter fait un retour à la ligne et Shift+Enter envoie.
      L’intention se comprend, mais l’utilisabilité est catastrophique.
    • La solution idéale serait sans doute : Ctrl+Enter envoie toujours, Shift+Enter fait toujours un retour à la ligne, et Enter suit la valeur par défaut selon le contexte.
    • Moi aussi, je pensais que Shift+Enter signifiait retour à la ligne, ce qui montre bien à quel point cette UX fragmentée est problématique.

  • Les logiciels d’aujourd’hui ne sont plus conçus comme avant par des concepteurs attentifs.
    À la place, le pilotage revient souvent à des PM ou responsables produit promus à la hâte, dans une réalité où l’on encourage même des dark patterns pour maximiser les revenus.

    • En tant qu’ingénieur mobile, quand j’explique aux parties prenantes qu’on ne peut pas « simplement construire l’idée telle quelle », je récolte souvent des regards vides.
      Il faut insister sur l’importance de la cohérence UX et de l’architecture de l’information (IA). Il ne faut pas oublier que les designers sont aussi des résolveurs de problèmes.
    • Cette critique est trop fragmentaire. En pratique, construire un simple formulaire en ligne peut déjà être un enfer.
      Par exemple, pour un formulaire de carte bancaire, il faut gérer une multitude de variables : autoriser ou non le copier-coller, prendre en charge les anciens navigateurs, équilibrer accessibilité et sécurité, etc.
      À ce sujet, le texte de Steve Yegge sur les plateformes explique très bien cette complexité.
    • Dans les années 2010, beaucoup de designers UX expérimentés sont partis, remplacés en masse par des designers non spécialistes venus de l’imprimé ou du graphisme, ce qui a fait baisser la qualité.
    • Bien sûr, il y a aussi de mauvaises incitations et des délais intenables, mais il est difficile de tout réduire à l’incompétence ou à la malveillance. Le système lui-même a changé.
    • Quand on voit encore aujourd’hui des PM vouloir concevoir eux-mêmes l’architecture globale et jusqu’à la feuille de route des releases, on se dit que ce constat n’est pas faux.

  • Les frameworks système servaient de base à la création d’interfaces idiomatiques.
    Win32, AppKit et UIKit géraient les détails les plus fins, poussant naturellement les développeurs vers une UX cohérente.
    À l’inverse, sur le web, il n’y a pas cette base : il faut tout implémenter soi-même, ce qui aboutit souvent à des interfaces à moitié finies.

    • Mais l’auteur se trompe en attribuant les incohérences au web de cette manière. « L’ère du desktop » était en réalité surtout l’ère de Windows, et comme Win32 était la norme par défaut, tout le monde s’y conformait.
      Le web, lui, était centré sur le document dès le départ, sans approche standard pour ce type d’interface ; plus tard, des outils comme Bootstrap ont créé une sorte de standard temporaire.
    • HTML et CSS existaient, mais aujourd’hui on les contourne avec WebAssembly et autres.
      En réalité, pour des éléments comme le sélecteur de date ou la saisie de carte bancaire, il faudrait utiliser les contrôles HTML natifs.
      Le navigateur peut alors fournir la sécurité et le confort au niveau de l’OS (par exemple, Safari avec Apple Wallet, Android avec Google Pay).
    • Les développeurs habitués au comportement cohérent d’un OS cherchent naturellement à reproduire cet environnement.
      Mais le web et le mobile sont des environnements cloisonnés complètement différents, ce qui a brisé cette cohérence.
      Par exemple, il y avait une occasion d’unifier le clic droit du desktop avec le long press sur mobile, mais cela n’a jamais été mené de façon cohérente.
    • Le problème fondamental du web est qu’il reste ancré dans un paradigme centré document.
      Pour construire une UI d’application, il faut la superposer à une UI de document, ce qui crée des conflits.
      Les navigateurs atténuent un peu cela, mais sans résoudre le problème de fond.
    • À noter qu’avec AppKit aussi, on peut modifier la hauteur d’un bouton. Ce n’est simplement pas évident.

  • Les sélecteurs de date sont vraiment un cauchemar UX.
    Ils empêchent souvent l’utilisateur de saisir lui-même une date et le forcent à cliquer partout.
    Il suffirait pourtant de bloquer les erreurs de saisie, au lieu de rendre l’expérience pénible sans raison.

    • Faire défiler des décennies de calendrier pour saisir une date de naissance donne presque un sentiment de vanité de l’existence.
    • Les sélecteurs d’heure sur mobile sont eux aussi incohérents. Parfois un seul défilement fait passer de 12:00 à 11:50, parfois non.
      Un sélecteur en forme d’horloge analogique paraît plus intuitif ; ce serait bien que cela devienne le standard.
    • Le format de date pose aussi problème. 03/04/2026, est-ce le 4 mars ou le 3 avril ?
      Pour des utilisateurs internationaux, le format YYYY-MM-DD est plus sûr.
    • Les sites qui utilisent pour la date de naissance le même sélecteur de date que pour planifier un événement futur sont les pires.
      Ils vous obligent à remonter 50 ans en arrière et vous font sentir votre âge au passage.
    • Être forcé de ressentir son âge à chaque saisie de date de naissance via un scroll, c’est presque de la torture.

  • La baisse de qualité de l’UX est frappante aujourd’hui, surtout sur les sites bancaires.
    Barres de défilement cachées, espaces perdus, boutons plats, icônes ambiguës : c’est bien plus inconfortable que les anciennes interfaces desktop.

    • Cacher les barres de défilement est vraiment incompréhensible. On dirait un choix purement esthétique pour « faire plus joli ».
    • J’ai le sentiment que Material UI a eu un effet néfaste sur plusieurs secteurs.
      GCP et les outils Google sont devenus inutilement complexes, et des champs de saisie sans contour, entre autres, ont dégradé l’UX.
      Heureusement, ce style commence aujourd’hui à paraître daté.

  • Un ancien principe venu du Mac d’autrefois : quand le texte d’un bouton se termine par des points de suspension (…), cela signifie qu’une saisie supplémentaire est nécessaire.
    À l’inverse, un bouton sans points de suspension exécute l’action immédiatement au clic.

  • Je suis d’accord avec l’idée qu’il faut « préférer les mots aux icônes ».
    Pour la plupart des gens, la reconnaissance des mots est plus rapide que celle des icônes.

    • Bien sûr, les icônes représentant des objets réels peuvent fonctionner, mais aujourd’hui il y a trop d’icônes abstraites et linéaires.
      Sans libellé texte, on doit cliquer un peu au hasard pour comprendre leur sens, comme à la roulette russe.
    • Il y a aussi des cas comme les boutons « unvote/undown » de HN, où le préfixe commun entretient la confusion. On est obligé de revérifier à chaque clic.
    • Si les icônes sont petites ou changent souvent de place, les mots sont préférables ; en revanche, dans un environnement stable, les icônes peuvent parfois être plus rapides.

  • J’ai récemment découvert une nouvelle technologie appelée CSS : elle permet de définir des layouts de façon déclarative et d’appliquer des styles hiérarchiques basés sur le DOM.
    Cela réduit la charge côté client et serveur, et facilite aussi le partage de feuilles de style ou la création de thèmes personnalisés.
    J’aimerais appeler cela le paradigme UI « no-framework ».
    Image d’exemple

    • Je l’ai essayé et c’était un cauchemar absolu. Impossible de savoir quel style s’applique où, et dès que la structure du DOM change, tout casse.
      En plus, la « charge client minimale » n’est qu’un mythe. En réalité, c’est plus lent.
    • Il faudrait peut-être proposer cette idée à l’équipe du framework vanilla-js.

  • Parmi les fonctionnalités communes que nous avons perdues :
    Undo/Redo, l’aide (F1), les infobulles au survol, la personnalisation des raccourcis, le menu principal, les fichiers/répertoires, la fermeture par ESC, le drag-and-drop, etc.
    Des fonctions autrefois innovantes ont aujourd’hui presque disparu du mobile et du web.

  • Beaucoup de problèmes viennent du fait que des designers visuels sont passés à la conception produit.
    La confusion entre les rôles dans les métiers du design n’est toujours pas résolue, et en réalité, on mobilise encore trop de « designers » même sur des projets qui n’en ont pas besoin.