6 petits trucs faciliter vos tests d’utilisabilité sur mobile

Je n’en suis pas à mes premières armes pour ce qui est des tests d’utilisabilité. Ça faut plusieurs fois que j’ai à en réaliser et superviser dans le cadre de mon travail, mais la dernière volée de tests effectués pour un projet en cours était fort différente: il fallait tester l’interface sur mobile!

Tout d’abord, on parle de tests effectués dans le cadre d’un projet pour améliorer l’interface utilisateur d’un site Internet, pas de tests dans un but scientifique ou desquels vont découler un rapport complet. Nous avions un délai très court, un budget restreint et une capacité limitée. Ainsi, nous avons réalisé ces tests dans nos locaux, avec notre propre personnel, sans enregistrer le tout sur caméra ou bien logiciel de capture d’écran… à la bonne franquette, quoi! (mais tout de même structurés, hein!)

Alors, des tests sur mobile, y’a rien là, z’allez dire! C’est juste un test sur un appareil différent… Ben, oui, effectivement, c’est pas sorcier. Malgré tout, il y a des choses à prendre en considération pour maximiser les résultats…

1. Trouvez PLUSIEURS appareils pour faire vos tests

Nous devions mettre la main sur un appareil mobile pour faire les tests et j’ai réussi à obtenir (grâce à la collaboration de mes collègues) deux appareils, un iPhone 5s et un Samsung Galaxy Mega (une phablette). Ce fut là le meilleur des deux mondes!

Nous avons pu offrir à nos participants la technologie avec laquelle ils étaient la plus à l’aise. Bien que ça puisse paraître anodin, on ne veut pas tester le système d’exploitation, mais plutôt notre site.

Le meilleur exemple est la manière dont Android gère l’affichage des boîtes déroulantes (select) versus iOS 7. Complètement différent!

À gauche, l’affichage d’une boîte de sélection (select) dans une interface Android et à droite, dans iOS 7. On note une grande disparité entre les deux interfaces.

2. Faites un test sur les appareils en question

Tout bon spécialiste UX qui se respecte qui prépare des tests d’utilisabilité sait qu’il faut faire un premier dry-run pour s’assurer de la viabilité de nos tests et des interfaces… Eh bien, en ouvrant le site sur un vrai iPhone (et non pas en ne faisait qu’un changement de taille de fenêtre de fureteur), on s’est bien rendu compte que le texte était beaucoup trop petit!

Rien de mieux que de tester sur un appareil plutôt que de faire de l’émulation! On remarque alors plein de petits trucs auxquels on avait pas pensé (l’utilisation d’une interface tactile a aussi un impact non négligeable).

3. Ne présumez de rien

On croit, à tort, que certains comportements ou des habitudes de navigation sont si fortement ancrées que c’est la base même de tout. Vous vous trompez. Dans le cadre de nos tests, AUCUN utilisateur n’a utilisé le logo du site (le classique «Québec drapeau» du bandeau programme d’identification visuelle) sur mobile. Pour revenir à la page d’accueil, ils ont tous préféré utiliser la fonction de retour du navigateur (que j’ai moi même longuement cherché sur iOS…)

4. Vous devrez vous lever pour voir l’utilisateur en action!

Dans le test sur ordinateur standard, l’utilisteur avait son propre écran pendant que les observateurs voyaient une copie sur l’écran du portable utilisé pour le test. Cet aménagement n’était pas possible pour l’appareil mobile.

À moins que vous ne connaissiez un moyen de diffuser sur un écran (sans coûts ni trucs bizarres) ce que l’utilisateur fait, vous devrez vous lever et aller derrière l’utilisateur pour le voir travailler sur son écran. De plus, puisque le doigt de l’utilisateur est son principal moyen d’interagir avec l’interface, il nous faut voir celui-ci en action. Sur l’ordinateur standard, le curseur se déplace et on voit les gestes de l’utilisateur.

Ainsi, les observateurs doivent se lever et, petit hic, ça cause un léger inconfort au participant… il a plein de gens qui regardent derrière son épaule.

5. Vos participants DOIVENT être familiers avec la navigation sur appareils mobiles

Dans le cadre de nos tests, nous avons remarqué deux types fort différents d’utilisateurs: ceux qui utilisent parfois un appareil mobile pour naviguer, et les utilisateurs réguliers et expérimentés.

L’incidence est importante. Un utilisateur qui utilise de façon régulière un appareil mobile pour accéder à Internet aura une façon tout à fait différente d’utiliser le site. Il sera à même d’utiliser des fonctions de base de l’interface (ex. pinch in / pinch out) et connaîtra les conventions inhérente au design de sites pour mobile (du moins, les quelques conventions reconnues).

L’utilisateur moins habitué sera parfois surpris de certaines réactions de l’interface ou hésitera longuement (cette fameuse peur qu’ont les utilisateurs de «briser» le site)…

Encore une fois, ce que l’on veut tester, c’est le site, pas l’appareil. Si l’utilisteur n’est pas un habitué, il va hésiter par manque de connaissance et non parce que votre interface est problématique. Malgré tout, on doit reconnaître qu’une bonne proportion de nos utilisateurs finaux seront dans cette catégorie. On doit leur faciliter la vie, mais on ne peut pas les prendre par la main non plus…

Il faut donc être judicieux dans la proposition de correctifs. Certains seraient peut-être superflus car liés à cette inexpérience…

6. Planifier des scénarios spécifiques pour le mobile

Planifiez des scénarios pour l’appareil standard et d’autres pour l’appareil mobile, surtout si vous utilisez un prototype. Ça va vous permettre d’avoir le contrôle sur ce qui devra être mis en place dans le site.

Les scénarios hybrides vont nécessiter que le contenu soit à la fois optimisé pour le site standard et pour la version mobile… ce qui peut complexifier le travail dans le prototype. Bien que le site soit adaptataif (RWD – Responsive Web design), des ajustements devront être faits. Bref, simplifiez-vous le travail, faites des scénarios spécifiques pour le mobile!

Bref…

Faire des tests d’utilisabilité sur mobile n’est pas si différent de tests sur ordinateur standard ou bien un bon vieux prototype papier très basse fidélité. Suivez ces quelques conseils, et vous serez mieux préparés…

Comme il est si bien dit, peu importe le test, s’il y en a au moins un, c’est toujours mieux que rien du tout! De plus, c’est parfois surprenant ce que l’on peut apprendre à voir un utilisateur sur son site Web!

Ainsi, j’espère que ces quelques petits trucs pourront aider ceux qui auront à planifier des tests d’utilisabilité qui engloberont un volet sur appareils mobiles.

Tests d’utilisabilité sur un nouveau site

Mercredi et jeudi, les 27 et 28 janvier, nous avons fait tester le futur site du MSP par 10 personnes sélectionnées dans la population. Nous avons été accompagnés par Daniel Lafrenière pour déterminer quelles devaient être les tâches à tester, tout le reste a été fait à l’interne (scénarios, création du prototype, réalisation des tests) à l’exception du recrutement des participants. Considérant le faible coût de l’opération et les bénéfices que nous avons eus, je serais fort curieux de calculer le ROI.

Ce n’était pas la première fois que je participais (ou organisais) des tests, mais c’était un baptême pour un site ministériel avec des gens triés sur le volet. Généralement, je testais des systèmes informatiques destinés à une clientèle bien précise (coroners, policiers…). Donc, peu de variété, très ciblé, clientèle bien définie. Cette fois, c’était différent.

Le site ministériel a un vilain défaut, il ne s’adresse pas au commun des mortels, mais vise assez large. Après tout, qui d’entre-vous avez à y aller? ce sont généralement des spécialistes (sécurité civile, pompiers, policiers) ou des gens qui vivent des situation bien précises (incarcération, sinistres…) qui vont devoir s’y rendre. Bref, il est difficile de trouver des utilisateurs qui pourront représenter la plus pure réalité. Nous avons donc choisi, selon les conseils de Daniel Lafrenière, de faire jouer des rôles aux participants. Alors, qu’a-t-on appris de ces tests? En voici un résumé…

Ce que les tests nous ont appris

Tout d’abord, il importe de signaler que nous avons testé avec 10 personnes, sur deux jours, et avons fait des améliorations entre les deux groupes. Ainsi, le second groupe testait une interface que nous avions amélioré, nous permettant ainsi de visualiser immédiatement les impacts de ces changements.

Première constatation surprenante, les utilisateurs n’avaient pas tendance à utiliser le menu supérieur, un genre de bandeau sous le PIV. Pourtant, on ne peut dire qu’il était invisible. Après analyse sommaire des résultats, c’est peut-être lié au test lui-même. Le utilisateurs avaient tendance à rechercher du contenu dans les pages et à rester dans une seule section. Nous avons amélioré la visibilité du bandeau, on a eu un meilleur succès, mais il est difficile de dire si le problème d’origine est lié au test ou à l’interface.

Par contre, un élément majeur de navigation (profils de clientèle) était presqu’invisible pour le premier groupe et un simple changement de contraste a fait toute la différence. Parfois, il suffit de peu pour un grand résultat!

Nous avons amélioré de petites choses, des survols (roll-over), ajouté de l’information subtile et, à chaque fois, ces petites choses ont eu un effet. Sauf une, une bannière qui reste invisible à tous. Le problème n’est pas réglé et nous n’avons pas encore de solution miracle… j’espère que nous trouverons une idée d’ici le lancement!

Un autre problème, d’un autre ordre, est celui de la terminologie. Le gouvernement a sa langue de bois, vous savez bien, et malgré bien des efforts, il en reste encore. Il est parfois difficile de trouver un équivalent qui plaise à tous, et cette problématique a été maintes fois observée pendant le test… Là, ça sort un peu de ma plate-bande… On verra comment on pourra améliorer le tout…

Ce que nous avons appris sur les tests

Outre ce que les tests nous ont appris, nous avons appris sur les tests. Tout d’abord, sur la sélection des participants. Peut-être avions-nous été à la fois trop laxistes et fermes sur nos critères. Par exemple, nous aurions peut-être dû mettre un écart d’âge plus grand, mais spécifier qu’on ne voulait pas de gens travaillant au gouvernement et non seulement au ministère…

Le libellé des questions n’était pas parfait. On a même dû revoir une question dans sa forme car la phrase était complexe, nous l’avons réalisé après quelques utilisateurs. L’effet sur le test n’était pas majeur, mais on a vu une différence de compréhension une fois le libellé changé.

Finalement, je le savais, mais c’est tout de même important à rappeler: les gens n’agissent pas de la même façon lors de tests que devant leur ordinateur! C’est bien certain!

Il faut savoir interpréter ce qui est lié au tests et ce qui ne l’est pas. Les utilisateurs ont un comportement légèrement biaisé, par exemple, dû au fait qu’une ou deux personnes les observent ou qu’ils doivent parler à voix haute.

En conclusion

Il est évident que l’exercice que nous avons fait a eu un impact majeur sur la qualité du site, et je suis tout à fait conscient que ce dernier ne sera pas non plus parfait à sa sortie. Je m’attends à des remarques et des commentaires sur l’utilisabilité du site, mais je crois que le test nous aura évité bien des problèmes.

Il faudra demeurer vigilant après la mise en ligne. Par exemple, suivre avec les statistiques Web l’utilisation et les performances du site: chemin de visite, origine des visiteurs, mots-clés, indexation générale… Bref, les tests n’étaient qu’une phase dans la conception. Faire un site Web, c’est un work in progress, ne l’oublions pas!

Réaliser un test d’utilisabilité et un prototype papier

Dans le cadre du Web Éducation du 24 septembre, Simon Bédard et moi avons présenté quatre séquences vidéo pour démontrer le déroulement d’un test d’utilisabilité, de la création du scénario à la réalisation du test. Voici donc ces quatre petits vidéos!

Un petit avertissement: tout est fictif. Le ministère de la Gestion des permis, ça n’existe pas. Y’a pas de «permis d’établissements», Transville, ça existe pas… C’est pour le test, le contenu, c’est pas important! (en passant, je sais pas trop pourquoi le premier est en 4:3 au lieu de 16:9… je suis tout allongé!)

La création du scénario

Cette séquence présente l’étape de création du scénario. On définit quels seront les écrans à faire et la séquence testée ainsi que les informations à fournir à l’utilisateur.

Concevoir le prototype

Le matériel et comment on réalise le prototype. Il y a même une patch qu’il fallait appliquer suite à un bug du système!

Faire un pré-test

Le pré-test est un «reality-check», un test pour le test! Ça nous permet de déceler des lacunes avant de se lancer dans la nature avec le scénario.

Et finalement, le test!

Voici venu le temps du test. On accueil l’utilisateur, lui explique le déroulement du test et on suit ses faits et gestes!

Conférences sur conférences…

Eh ben… fallait un été plus relaxe pour avoir un automne de fous, hein? je fais quatre présentations cet automne, et le tout en deux semaines. Et non, ce n’est même pas sur le même sujet!

La première, c’était au WebÉducation sur les tests d’utilisabilité la semaine dernière. La seconde, au CÉGEP de Sainte-Foy, lundi dernier, où je m’adressais aux finissants du programme de graphisme (d’où je suis moi-même issu) au sujet des CMS. Finalement, je présentais à mon service le déroulement du projet de refonte du site ministériel mardi dernier. Ma dernière présentation sera sur le processus de sélection d’un logiciel libre (le cas de la sélection de TYPO3 au minsitère), le tout à la Vitrine Technologique, à Québec.

Bon… après ça, bien, je prends quelques mois de congé sans faire de présentations… je crois que j’en ai besoin!

WebÉducation sur les tests d’utilisabilité

L’automne prochain (en septembre), aura lieu un WebÉducation sur les tests d’utilisabilité. Je me suis [encore] mis la cravate dans le tordeur, en bon français, et c’est à moi que revient l’odieux de planifier la journée (eh oui!).

L’objectif principal de la journée est de démontrer qu’il est possible, pour un organisme public, de réaliser des tests d’utilisabilité à peu de frais.Ainsi donc, je lance un appel à tous pour trouver des conférenciers qui pourraient être intéressés.

J’ai pondu un horaire sommaire en quatre conférences. Alors, si vous êtes intéressé, contactez-moi! Ou si vous connaissez une personne qui pourrait être intéressée, dites-lui de me contacter!

À titre indicatif, un WebÉducation est une journée de conférence gratuite organisée par le Ministère des services gouvernementaux, à l’auditorium du complexe G (Marie- Guyart, à Québec). Il y a généralement entre 100 et 250 personnes, selon le thème de la conférence, tous des employés du gouvernement (public et parapublic) qui ont une influence dans leur M/O

respectif.

En espérant une réponse positive des personnes intéressées!