Ergonomie

Working hand cc PHOTO.WORKS on Flickr

Working hand cc PHOTO.WORKS

Il y a quelques temps que je pousse pour une meilleure prise en compte de l’ergonomie dans la conception des interfaces graphiques à mon travail. J’ai été entendu, et ce que nous avons mis en place nous a permis — je pense — d’avancer significativement.
J’en profite pour partager ici mon expérience sur le sujet, car il me semble que la démarche que nous avons instauré est très intéressante et mériterait d’être appliquée de manière plus systématique, pas uniquement dans le logiciel.

Ma principale source d’information sur le sujet a été internet, notamment les Guidelines d’Apple ainsi que Wikipedia (et les sources citées en référence). Vous trouverez une liste de références à la fin de ce billet. J’espère trouver plus de temps pour explorer les ouvrages de référence sur la mesure de l’ergonomie (ça viendra).

Le concepteur n’est pas un utilisateur

Le principe est simple, mais à mon sens primordial : on ne peut pas concevoir un objet, un logiciel, un appareil photo ergonomique sans le présenter à un utilisateur. On peut être très compétent, connaître ses clients et le métier sur le bout des doigts ; mais notre point de vue est forcément biaisé : on conçoit le produit.
En tant que concepteur, on sait comment utiliser ce qu’on a créé, et comment ne pas l’utiliser. On sait où chercher l’information, où cliquer, quel mécanisme actionner, quel menu dérouler ; mais ce qui nous semble évident peut paraître complètement obscur à une autre personne.

Observer les utilisateurs

Binoculars portrait cc gerlos on Flickr

Binoculars portrait cc gerlos

Partant de ce constat, pour concevoir un produit ergonomique il faut s’appuyer sur l’expérience des utilisateurs.

Il existe plusieurs manières de procéder pour recueillir cette expérience, mais le vecteur est toujours le même : un test d’utilisabilité (voir Test utilisateur ou Usability testing sur Wikipedia).

Ces tests d’ergonomie reposent tous sur le même principe : mettre le produit (dans notre cas le logiciel) entre les mains d’un utilisateur et observer voire mesurer ses actions et ses réactions face aux problèmes qui lui sont posés.

Ces tests d’utilisateurs servent concrètement à récolter des informations essentielles parmi les suivantes :

  • la performance d’une fonctionnalité, c’est-à-dire le temps que prend la réalisation d’une tâche ;
  • la précision d’une interface ou d’un concept représenté par l’interface, c’est-à-dire le nombre d’erreurs que font les utilisateurs avant de trouver la «bonne» action ;
  • la courbe d’apprentissage, soit le fait que les utilisateurs se souviennent de la manière d’effectuer une action après un certain temps
  • le ressenti des utilisateurs face à chaque fonctionalité

Suivant le protocole qui est choisi pour ces tests, les informations recueillies dans les 4 domaines seront plus ou moins précises. Ainsi, l’analyse que nous avons mené permet d’étudier plus spécifiquement le ressenti et la précision des fonctionnalités, et dans une moindre mesure leur performance.

Comment diriger des tests d’utilisabilité

Notre démarche a été largement inspirée par celle décrite par Apple dans ses Guidelines.

  • Écriture, en amont, d’un scénario à tester. Ce script utilise des termes et expressions ne faisant référence qu’au métier, pas au logiciel. On ne donne pas d’instructions précises.
  • Présentation de la session au participant, du protocole suivi, du fait que les observateurs resteront volontairement en retrait. On demande également à l’utilisateur de penser à voix haute tout le long du test.
  • Test par l’utilisateur, avec enregistrement audio et vidéo de ses actions. Nous sommes deux observateurs dans la salle qui notons également ses réactions à chaud. Cependant, nous restons en retrait tout le long du test.

Jakob Nielsen précise qu’il est superflu de conduire un test d’utilisabilité avec plus de cinq utilisateurs (sur le même ensemble de fonctionnalités testées). Car ce nombre permet de relever près de 80% des problèmes d’ergonomie.

Afin de varier les profils, on peut utiliser la méthode dite «Hallway testing» qui consiste à demander à 6 personnes prises au hasard. L’origine du nom venant du choix des personnes lorsqu’elles passaient dans le couloir.

Résultats et actions

Une fois ces tests effectués, il reste à effectuer deux étapes fondamentales. Il faut premièrement restituer de manière synthétique 5 à 6 heures de tests. Il faut noter méticuleusement les lacunes chroniques, les points positifs de l’interface, les petits détails très énervants. À ce moment, la vidéo et l’audio sont d’une grande aide.

On se rend compte que de petits détails laissés inachevés par un développeur peuvent avoir une incidence très importante sur l’expérience utilisateur.

De mon point de vue, il est très important que les concepteurs de l’application aient un retour sur la méthode et les résultats obtenus par ces tests. Lors de notre première session, nous avions présenté à l’équipe une vidéo de morceaux choisis. Voir l’utilisateur galérer alors qu’il a le bouton sous la souris est toujours plus parlant qu’un descriptif d’incident.

Une fois les problèmes d’utilisabilité identifiés, il rester à les prioriser et à les régler. Certains sont particulièrement faciles à traiter. Pour certains autres, il faut revoir le fonctionnement de l’interface. Ce qui peut être coûteux, certes, mais la nécessité du changement est alors souvent irréfutable.

Rester agile

Après cette première session de tests d’ergonomie, on peut mesurer le chemin qu’il nous reste
à parcourir. Mais le plus dur est fait : se lancer, et aboutir à des améliorations concrètes de notre produit. Ce qu’il nous reste à améliorer sur ces tests serait certainement de l’ordre de la mesure et la quantification de la qualité de l’ergonomie.

Dans un premier temps cependant, je pense qu’il est inutile de sortir l’artillerie lourde. Chronométrage, compte du nombre de clics, eye tracking, c’est très bien. Mais ces outils ne sont pas nécessaires pour obtenir des premiers résultats.

Être à l’écoute de l’utilisateur et l’observer suffisent pour comprendre ses attentes, ses intuitions, ses frustrations face au logiciel. Par la suite, en fonction des besoins d’analyse, des outils plus précis peuvent être mis en place, et le protocole affiné. Du moins, c’est mon point de vue pour une structure comme la notre.

Références

Pour finir, voici un petit récapitulatif des références intéressantes sur le sujet.

Commentaires

2 Comments sur « Ergonomie »

  1. Tim dit :

    Excellent boulot, voila bien un truc que j’ai arrêté d’imaginer pouvoir changer chez S. (1 designer, pas d’équipe usability et X*10³ ingénieurs software). J’espère que l’acceptance des utilisateurs au moment de la sortie de votre nouvelle version te donnera encore plus de munitions pour continuer!

    Ah et sinon «wah un post :D»

  2. Ghusse dit :

    Merci pour tes encouragements. 😀

Laisser un commentaire