Publié par

Il y a 8 années -

Temps de lecture 5 minutes

Devoxx – Rules for Good UI Design

La conception des interfaces utilisateur tient une place importante, même dans une conférence très technique comme Devoxx. En témoigne l’affluence à cette session où Joe Nuxoll, principalement connu en tant que membre du célèbre Java Posse, se propose d’inculquer aux développeurs quelques notions issues du monde du design.

Joe a débuté sa carrière comme architecte logiciel, mais nous explique avec enthousiasme qu’il a découvert sa passion pour les interfaces utilisateur en travaillant sur des toolkits graphiques. Adepte de course automobile, il occupe aujourd’hui le poste de ses rêves : Tesla motors l’a chargé de concevoir le panneau de contrôle intérieur du futur Modèle S.

Comme on pouvait s’y attendre, sa présentation est très professionnelle, avec des diapositives minimalistes mais efficaces, qui rappellent Presentation Zen. Il s’attache surtout à définir des principes directeurs, à la façon de Don’t make me think, qu’il citera d’ailleurs comme référence.

Avant l’interface utilisateur, il faut s’intéresser à l’expérience utilisateur : peaufiner l’interface est la dernière étape. Il faut avant tout définir ce que fait le produit, comment il rend service à une personne. Le processus de design suit les étapes suivantes :

  • L’expression du concept, c’est à dire du besoin métier ;
  • L’architecture de l’information et la conception des interactions, qui se caractérisent par des itérations sur des prototypes de bas niveau (diagrammes de flux ou modèles en « fil de fer ») ;
  • La conception visuelle, qui itère cette fois-ci sur des mockups très fidèles au rendu final ;
  • Enfin, le plan de mise en production.

Le design est subjectif : il n’y a pas de réponse objectivement correcte à un problème donné. Cependant, l’interaction homme-machine repose sur quelques principes de base, qu’il faut respecter. Pour Joe, le design par comité ne marche pas : les discussions sont bénéfiques dans les phases d’itération, mais une seule personne doit prendre la décision finale. De même, il estime que le design par heuristique (mesurer les temps de réflexion, le nombre de clics…) fonctionne mais ne donne pas de bons résultats visuels (« looks assy » selon ses propres termes).

La seconde partie de la présentation est plus pratique, Joe nous livre ses « règles d’or » du design :

  1. La structure des données sous-jacentes ne doivent pas influencer l’interface utilisateur. Inversement, l’interface ne doit pas non plus influencer l’implémentation. Souvent, une bonne interface évite ces problèmes grâce à une couche de transformation de données.
  2. Le besoin doit primer sur la technologie. Il faut résister à la tentation de se « faire plaisir » sur la technique. Idéalement, les choix techniques doivent être repoussés le plus tard possible, une fois que le besoin est bien cerné.
  3. Démarrer le processus avec de vrais cas d’utilisation. Voir comment les utilisateurs répondaient au besoin précédemment, ce qui marchait et ne marchait pas.
  4. Identifier les catégories d’utilisateurs qui vont utiliser le produit. Les incarner sous forme de personnages avec un nom, une photo, qui aidera à les identifier. Envisager de leur proposer des interfaces différentes.
  5. Penser en terme de flux, pas de fonctionnalités. Une interface est vivante, en mouvement. Par exemple, ne pas penser en terme d’écran de connexion, mais de processus de connexion. Ceci facilitera les retours des utilisateurs dès les premières itérations.
  6. Prototyper souvent, jeter les prototypes souvent. Ne pas trop investir, construire rapidement et jeter sans regret.
  7. Rendre la prochaine étape évidente. Joe nous donne l’exemple de la page principale de Google, où les boutons « Recherche » et « J’ai de la chance » sont côte à côte et ont exactement le même style. Si vous découvriez cette page pour la première fois, la différence entre ces deux boutons serait-elle évidente ?
  8. Réduire le nombre d’éléments perçus. Face à un écran, le cerveau perçoit une charge cognitive, sur laquelle il se base pour estimer le travail nécessaire pour « gagner » l’écran. Il évalue dans l’ordre :
    • les formes négatives et l’esthétique, qui produisent une réponse émotionnelle ;
    • le nombre d’éléments, qui détermine la charge de travail perçue ;
    • et enfin l’emplacement du premier élément, qui déclenche l’exécution.
       Joe montre un exemple avec les mêmes champs organisés de deux manières différentes, le résultat est frappant : le premier écran, avec tous ses champs en colonne, est complètement rébarbatif ; le second, utilisant quelques regroupements et des titres de section, paraît beaucoup plus simple à remplir.
  9. Utiliser la mémoire musculaire, être consistant.
  10. Penser à ce qui peut être fait sans rechargement de page. Par exemple, une liste chargée progressivement en AJAX peut être plus efficace qu’une liste paginée : l’utilisateur se souviendra mieux de la position approximative d’un élément que d’un numéro exact de page.
  11. Utiliser des transitions pour changer d’état. Montrer à l’utilisateur où il va, et comment revenir. Joe nous montre la page descriptive de la Tesla Modèle S, où la transition vers les sections se fait avec un défilement automatique vers le bas.
  12. Itérer et raffiner, itérer et raffiner. Joe valorise les designers qui cherchent continuellement à améliorer leur produit.
  13. Et avant tout, fournir une expérience de qualité à l’utilisateur. Ne pas juste « livrer cette fichue interface ».

Une présentation remarquable par la qualité de son orateur, et fourmillant de conseils utiles.

Publié par

Commentaire

3 réponses pour " Devoxx – Rules for Good UI Design "

  1. Publié par , Il y a 8 années

    Globalement, d’accord sauf sur 2 points.

    — « Le besoin doit primer sur la technologie. »
    J’ai actuellement le cas où le besoin de l’utilisateur était d’afficher et de rechercher rapidement parmis une liste de plus de 1.000 éléments. Ni une ni deux, on lui vend des filtres et des tris sur les tables de données.
    Passage à l’implémentation, la technologie (plus ou moins imposée par le client) ne permet pas de coupler du MVC (databinding) avec du filtrage… Ça va faire plus de 15j qu’on perd à tenter de trouver une solution viable pour réaliser cette exigence qu’on s’est nous-même attachée au pied en vendant du filtrage dans la spécification !

    — « Penser à ce qui peut être fait sans rechargement de page. »
    Même cas de figure, un client a une saisie un peu complexe à réaliser, et il ne souhaite pas avoir à faire « Retour » pour corriger ses données. On met donc tout sur seulement 2 écrans, avec de la mise-à-jour dynamique de l’IHM.
    Passage à l’implémentation, les règles de gestion sont totalement anarchiques à mettre en place, chaque saisie utilisateur relançant des vérifications qui déclenchent des pilées de popup (champs manquants, valeurs incorrectes…), la moindre modification entraînant des régressions monstrueuses dans le flux de saisie, etc.
    Les GUI stateless (même comportement quelque soit le chemin de saisie choisi) sont beaucoup plus simples à spécifier / concevoir / réaliser / tester / modifier que les GUI statefull (comportement différent en fonction du chemin pris), et surtout avec une dette technique beaucoup moins importante.
    Car bien souvent qui dit « statefull » (surtout dans les applis non web) dit « adieu architecture n-tiers, tests U ou MVC » !

  2. Publié par , Il y a 7 années

    Nicolas, tu te contredis : comme tu le dis, c’est la technologie (plus ou moins imposée par ton client) qui a fait que tu as galéré pour implémenter tes filtres.
    Ensuite, quand Joe Nuxoll parle de « Penser à ce qui peut être fait sans rechargement de page. », imagine que tu ais juste un javascript qui s’active à chaque nouveau caractère taper dans un champ pour t’indiquer si la valeur de celui-ci est valide. C’est tout à fait stateless. En effet, soit ta règle est directement implémenté en JS, soit elle appelle un web service, stateless sur ton serveur. Ton utilisateur est content : il a directement ses infos de valider. Toi tu es content, tu as juste la prise en compte de ton formulaire à gérer à la soumission de ton formulaire.

  3. Publié par , Il y a 7 années

    Je ne suis pas sûr de m’être contredit.

    Le choix technologique de mon client aurait du influer sur son besoin, et interdire toute envie de filtrage.
    On doit donc tenir compte des contraintes techniques lors de la rédaction du cahier des charges ou de l’expression des besoins, ce que Joe Nuxoll semble contredire dans sa présentation.

    Concernant le JS, mon problème n’est pas la saisie d’un seul champ, mais d’un ensemble de champs.
    Dans le 1er cas, je suis totalement d’accord avec toi, on est bien stateless.
    Dans le 2nd cas, on l’est déjà beaucoup moins, l’ordre de saisie / modification des champs pouvant influencer sur la suite (voire le passif !) de la saisie (par exemple des drop-down en série). La saisie globale des informations est une énorme machine à états (dont le graphe associé est complet !).

    En plus, je te ferais remarquer que même si le JS te signale que le formulaire est valide, on ne doit absolument pas tenir compte de ce qu’il nous remonte, mais on doit tout revalider au niveau serveur. Ne serait-ce que parce que le JS s’exécute côté client et ne doit donc pas être considéré comme une source fiable et sécurisée, au même titre que les valeurs GET ou POST.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.