Bertrand Evain, l'ergonome avec qui je travaille sur le projet, tient un blog. Certains de ses articles sont intéressants et je les reprendrai ici. Celui qui va suivre (dont j'ai remanié la forme), traite de l'utilisabilité d'un système informatique, qu'il s'agisse d'un site Internet, d'un logiciel, d'un téléphone…

Qu'est-ce que l'utilisabilité ?

L’utilisabilité (usability en anglais) correspond à la facilité d’utilisation d’un site. D’après la norme ISO 9241-11 :

Un système est utilisable lorsqu’il permet à l’utilisateur de réaliser sa tâche avec efficacité, efficience et satisfaction dans le contexte d’utilisation spécifié.

L’efficacité correspond à la réussite ou l’échec de l’utilisateur pour une tâche donnée, par exemple modifier sa signature personnelle dans Outlook. C’est un critère binaire : réussite ou échec.

L’efficience mesure le degré de difficulté rencontré par l’utilisateur pour accomplir sa tâche. Par exemple, s'il a réussi à modifier sa signature au premier essai, le système sera jugé efficient. Le nombre d’erreurs commises, de clics effectués, de recours à l’aide, le temps passé, le recours à une aide extérieure, etc. sont autant d’indicateurs de difficulté.

La satisfaction est un critère plus subjectif, qui renvoie à un ressenti général.

Contre-exemples illustratifs

Cas d'un manque d’efficacité : le site tinkco.fr

Certains sites requièrent l'acceptation de cookies par votre navigateur pour qu'ils puissent être utilisés.

Dans notre cas, si votre navigateur les refuse, l'ajout au panier ne fonctionne pas et vous aurez beau y ajouter des éléments, il restera vide. Les chances sont alors grandes pour que vous abandonniez le site, soit que vous n'ayez pas aperçu la mention "Problème de panier ?" dans la barre de navigation latérale, soit que tout en l'ayant vue vous n'ayez pas envie de passer du temps à résoudre le problème.

Dans les 2 cas, nous dirons que le système manque d’efficacité : l'utilisateur n’a pas réussi sa tâche et il a quitté le site sans pouvoir acheter.

Cas d'un manque d'efficience : le site de la fédération française de tennis de table

Les joueurs de tennis de table vont sur le site de la FFTT principalement pour deux raisons :

• s'informer, après chaque journée de championnat, des résultats et les classements
• s'informer, une fois par mois, de leur performance personnelle et de l’évolution de leur classement.

La première tâche requiert six clics, à quoi s'ajoutent parfois un défilement (scrolling) et une action sur un bouton de sélection. La seconde requiert neuf clics avant de devoir saisir son nom.

Ce qui est problématique ici, ce n’est pas tant le nombre de clics que le fait que ces clics concernent les tâches les plus fréquemment effectuées par l’une des cibles principales du site.

Cas d'une utilisation peu satisfaisante : le site allocine.fr

Rappelons que la satisfaction est un critère subjectif : l’utilisateur peut très bien avoir réussi sa tâche mais avoir un ressenti général négatif.

C’est le cas du site allociné. Il est facile à utiliser mais, à cause du caractère intrusif de la publicité, il laisse une impression générale négative. Les propos d'une internaute dans un forum sont du reste éloquents :

Vous ne trouvez pas qu’il est insupportable le site d’allocine ? Franchement un pub de 45 secondes à chaque visite de page, c’est relou…. Y’a quoi comme site dans le meme genre mais avec moins de pub ?

Conclusion

Le billet de Bertrand s'arrête sur ces mots mais j'ajouterai une conclusion. Je trouve intéressant que les deux premiers cas relèvent d'un défaut de compréhension des besoins et des contraintes de la cible alors que le dernier relève davantage d'un manque de respect à son endroit. Là, on compromet la conquête ; ici la fidélisation. Mais, en l'espèce, nous touchons au problème de la publicité display sur Internet, sur lequel Bertrand prévoit de revenir… et moi aussi.

L’utilisabilité en ergonomie is a post from: Le blog de Madmagz

Il n'y a guère de doute que pour une poignée de façons de bien réaliser une idée, il y en a des milliers de la gâcher. L'enjeu dans notre cas est d'autant plus grand que le service est nouveau et que c'est un logiciel en ligne : nous créons un usage et, sur Internet, les utilisateurs ne vous laissent votre chance qu'un instant, avant de vous adopter ou de vous rejeter.

Aussi est-il crucial d'adopter une méthode qui limite la perte de temps liée aux tâtonnements, aux discussions sans fin, et balise le chemin vers la bonne formule. Celle de l'ergonome avec qui j'ai travaillé, Bertrand Evain, est d'une remarquable puissance. Cette méthode repose sur deux outils et une philosophie.Le premier de ces outils est le cahier des charges fonctionnel. C'est un document Powerpoint que nous avons mis en ligne sur Google Documents de façon à pouvoir y travailler conjointement. Son objectif est double : déterminer les contenus et les fonctionnalités du site ; faire le lien avec la maquette fonctionnelle.

Ce document décrit :

1. le projet
2. le produit final (dans son environnement, par ses éléments constitutifs, par ses usages)
3. les utilisateurs du site Internet (qui permet de créer et de consommer le produit final)
4. les tâches utilisateurs (utilisateurs qui sont le producteur et le consommateur du produit final)
5. le contenu du site Internet (dans les grandes lignes seulement : front office, back office, langues, versions du service, droits…)
6. le plan de travail.

De ces différents points, le troisième et le quatrième me semblent particulièrement importants. Une page Web n'existe pas in abstracto : elle est destinée à quelqu'un pour qu'il en fasse quelque chose. Le travail sur les utilisateurs (qui sont-ils ? pourquoi utiliseraient-ils le service ? que doivent-ils faire ?…) est fondamental.

Le second outil est la maquette fonctionnelle (qu'on appelle également prototype, wireframe ou storyboard). La maquette définit les pages Web, leur succession, leur contenu (textes, visuels…) et l'agencement de ces contenus. Bertrand la réalise au moyen d'un progiciel. La maquette fonctionnelle concrétise le cahier des charges.

Le lien entre la maquette et le cahier des charges s'apparente au lien entre le scénario d'un film et sa mise en scène. Cependant, un bon film est-il possible sans un dialogue nourri entre son réalisateur (Bertrand) et son producteur (votre serviteur) ?

De fait, ces outils sont nourris par les discussions auxquels ils donnent lieu. Nos réunions avaient lieu soient par téléphone soit dans nos bureaux. Elles étaient parfois vives, car c'est aussi un débat d'idées. Si elles ont néanmoins été fécondes, c'est que nous avons su éviter deux écueils. Le premier est le compromis, espèce d'accommodement mou se substituant à la confrontation. Le second est d'en faire une affaire personnelle ("je veux avoir raison", "c'est moi l'expert", "c'est moi le client", etc.) : le point n'est pas d'avoir raison ou tort mais de trouver la meilleure solution. Car en définitive, il n'en est qu'un qui a toujours raison et c'est le juge de paix : l'utilisateur.

Chaque discussion donnait lieu à un compte-rendu qui servait de base à une nouvelle mouture du cahier des charges ou de la maquette fonctionnelle. Nous avons ainsi avancé jusqu'à la version finale de la maquette, qu'il fallait désormais tester. Avant de tourner le film, l'on montre le storyboard au public auquel il est destiné afin de recueillir son avis. Mais ceci est une autre histoire…

En conclusion, une des grandes forces de cette méthode est qu'elle fournit des supports concrets, objectifs et complémentaires aux discussions. Celles-ci s'en trouvent singulièrement fécondes, au point qu'elles m'ont fait souvenir d'un mot que je n'avais plus utilisé depuis mes cours de philo en classe terminale : la maïeutique. Selon cette définition, c'est une méthode qui permet, grâce au dialogue, à un esprit d'accoucher de vérités demeurées cachées.

Comment passer de l’idée aux pages Web ? is a post from: Le blog de Madmagz

Au terme de deux mois et demi de conception, Bertrand Evain (l'ergonome de l'équipe) et moi avons abouti à la maquette fonctionnelle du site. Une maquette fonctionnelle (ou story board ou wireframe ou prototype), c'est la représentation des différents écrans du site. (On peut pour cela utiliser Powerpoint ou un outil professionnel comme Axure)

Avant de passer la main à l'équipe technique, il nous fallait franchir cette étape cruciale : les tests utilisateurs. Pour prendre une image, c'est comme pour un architecte de montrer les plans de la maison qu'il a conçue à de probables habitants avant qu'elle ne commence à être construite (développement) et peinte (graphisme). Si les habitants la rejettent, il n'y a plus qu'à recommencer !

Bertrand a pour cela une méthodologie en cinq points. La première est de baliser le parcours en déterminant, pour chaque écran, le point à valider. Cela peut se représenter sous la forme du tableau ci-après.

Il faut ensuite choisir les personnes. Une demi-douzaine suffit, selon Bertrand, pour découvrir 80% des problèmes. L'enjeu pour nous étant surtout de valider la compréhension et, d'autre part, le service étant grand public, nous n'avons pas établi de profil cible.

Vient le moment où l'on présente le test aux personnes. Il est important de les mettre à l'aise et de préciser que le but n'est pas de les juger mais de recueillir leurs réactions. Il n'y a ni bonne ni mauvaise réponse : les torts, s'il y en a, sont nécessairement pour nous. Il est également important de ne pas servir d'aide : la personne doit se débrouiller comme si elle était seule.

Dans la prise de notes, il importe d'être factuel et d'avoir garde à deux choses : le comportement et les propos. Il est frappant de voir comme les comportements varient devant un même écran. Certains passent leur souris sur les boutons comptant voir apparaître une légende, d'autre recherche une FAQ, etc. Quant aux propos (voice of customer), ce sont des pépites qu'il faut recueillir avidement. Ils véhiculent plus que le sens : le sentiment, l'état d'esprit.

Enfin, la synthèse doit faire la part entre les réactions singulières et les leçons.

Les tests utilisateurs ont porté à la lumière des frictions lors du passage de l'étape de création à celle de publication, des termes inexplicites, des incohérences, etc. Ces points étaient toutefois mineurs : toutes les personnes ont compris rapidement le propos du service et la façon de l'utiliser. La conception était validée !

Et l'enjeu n'est pas à mésestimer. Ce qui est gagné ici, c'est un coût d'acquisition inférieur, un taux d'adoption et d'usage supérieurs, des recommandations en plus grand nombre, un service utilisateur moins sollicité, des ajustements techniques éliminés, etc. Autant dire que le travail ergonomique et les tests utilisateurs qui le sanctionnent sont indispensables.

Les tests utilisateurs is a post from: Le blog de Madmagz