6. « il faut beaucoup d’utilisateurs pour les tests »
http://www.useit.com/alertbox/20000319.html
7. Une methodologie aisée
• Demander à 3 utilisateurs d’effectuer quelques tâches avec notre
application
• Observer et enregistrer les sessions
• Analyser ce qui s’est passé pour améliorer notre application
8. A faire
Préparer l es tests
Utilisateurs
Tâches
t
E nvironnemen
Dérouler l es tests
Analyser et agir
11. Les tâches
Voir le prix d’une cha
mbre
d’hôtel
Backlog
Réserver une chambre d’h
ôtel
Annuler u
ne réserv
ation
12. Les scénarii
Scénario
Contexte
Vous avez reservé une chambre à
Tâche
l’hôtel Shakespeare à Londres,
pour la nuit du 15 juin.
Annuler une
reservation
Suite à un empêchement, vous ne
pouvez plus aller à Londres.
Objectif
Annuler la réservation.
Infos
Nom d’utilisateur : baudelaire
Mot de passe : f1eur5
13. Les scénarii : des astuces
*
Il était une
Select
fois…
from
products
Ecrire...
...le minimum
Le bon langage
Tester le test
26. Références
Livres
• Usability Testing Essentials - Carol M. Barnum
• Rocket Surgery Made Easy - Steve Krug
Liens
• Mailchimp testing mobile apps:
http://blog.mailchimp.com/recording-mobile-usability-tests/
• Silverback : http://silverbackapp.com/
• Camstudio open source : http://camstudio.org/
• http://ethn.io/ : recrutement de candidats directement sur votre site
L’idée, c’est qu’on va mettre notre application devant une personne qui est representatif de nos utilisateurs.Et on va regarder ce qu’il se passe lorsque cette personne utilise notre application.Ça nous permettra de mieux comprendre comment la personne travail avec notre produit, comment elle réfléchit, les points de blocage, ce qui n’est pas clair, ce qui est frustrant, et ainsi de suite.C’est tout simple, et c’est très puissant pour trouver des problemes d’ergonomie, et d’imaginer de nouvelles fonctionnalités.Mais malheuresement, on ne le fait pas souvent. On attend souvent très tard, par exemple, la phase des UAT ou même la mise en prod avant d’avoir de vrais retours.Ca nous pose de problemes :c’est pas la même qualité de donnée (au lieu de voir ce qu’il se passe, on reçois des “bugs”)C’est souvent trop tard, surtout parce que les problemes d’ergonomie sont rarement prioritaire face aux bugs fonctionelle / techniqueLes tests utilisateurs nous donne des données de qualité très TOT dans le projet
“il vaut mieux tester un seul utilisateur au début du projet que d’en tester 50 à la fin
Pourquoi est-ce que les tests utilisateurs sont ideaux pour les projets agiles (et vice versa?) Parce que, en tant qu’agilists, on :veut toujours du feedback, tôt et souvent. On preferait valider au plutot et en continue ce qu’on est en train de créergarde le droit de changer d’avis. Ca sert à rien de faire des cycles de test si le périmètre est gravé dans le marbrea (presque) toujours une version du produit qui marche. On developpe par tranche verticale. On ne se retrouve pas avec seleument la base de données, par exemple. On a quelquechose qui fonctionne, et donc, qu’on peut utiliser pour des test utilisateurs
On ne cherche pas des données quantitative. On cherche simplement apprendre des choses. On veut des aperçus de l’utilisation de notre application. Insights. Ideas. Warning signs.Comme ça, on peut être beaucoup moins exigeant sur notre démarche. Tant qu’on apprend des choses qu’on n’aurais pas appris autrement, ça apporte quelquechose.Un exemple de cette peur de la complexité : on est souvent convaincu qu’il faut tester avec beaucoup d’utilisateurs.
Etude qui a été menée par Jakob Nielsen.Les utilisateurs les plus “productifs” sont les premiers.Tester avec 3 utilisateurs par mois vaut mieux que de tester une fois avec 15. Ca nous permet de prendre en compte ce que nous avons appris, et puis de retester.En tant qu’agilist, c’est approche iteratif me va bien
Ok, on vadonc imaginer un process qu’onpourrait faire souvent, unefois par itération, outoutes les deuxitération, ouplusieursfois par release… donc, en grosil nous fautquelquechosed’assezlegère.
Ca dépend beaucoup de notre context.Dejà, il y a une règle de base : en géneral, on va pas réutiliser nos utilisateurs. Après, ça depend:Si on est en train de developper un application interne, on aura dejà une bonne idée de nos utilisateurs, et la possibilité de les connaître un peu mieux.Si c’est un application pour une démographic spécialisé, il faut peut-être trouver des gens qui y appartiennent. Si vous êtes en train de developper un une application pour cette démographique, vous avez surement des contacts. Il faut s’y appuyer pour identifier des candidats de test. Sinon, les user groups, des forums en ligne, etc vous permettraient de rentrer en contact avec ces gens.Si c’est une application destiné au grand public on est un peu plus libre dans le sens ou il ne faut pas de connaissances spécifiques, donc le pool est plus gross. La on utilise souvent des étudiants, parce qu’ils sont souvent plus disponible. Mais là, on peut demander aux amis, aux connaissances, au membres de vos familles, etc.L’objectif est d’avoir une liste de candidats. Poster en ligne ou créer des affiches avec une adresse mail est parfait. Fait peut être proposer une compensation (slide suivant)Sinon, d’autres idées : sur votre site actuel, si vous en avez.Enfin, si vous galerez vraiment, et vous voulez absolumment avoir des gens qui correspond aux critères précises, il existe des agences qui vous aidera à récruter des “utilisateurs” (cher, ce qui va a l’encontre de notre vision “discount”) Ethn.io peut vous être interessant---L’idéal est de trouver des personnes qui sont identiques aux vrais utilisateurs… mais sinon, c’est pas la fin du monde. Par exemple, vous êtes un train de developper une application qui permets aux gens de trouver des restos, leur des avis, reserver en ligne etc. Ca serait bien que nos utilisateurs soit des gens qui aiment bien manger en resto. Mais n’importe qui comprendra ce que c’est un restaurant, un avis, une reservation, comment ça marche, etc. Faut-il se prendra la tête pour avoir des “foodies” comme on dirait en anglais ? C’est à vous de voir. Mais il faut pas que la complexité vous paralyse, car il vaut mieux tester avec 3 quasi-utilisateurs qu’avec 0 utilisateurs parfait.
[add 3 falling stick men to filter]OK, on a identifié les personnes qui peuvent être nos utilisateurs. Comment trouver 3 personnes de ce group pour nos tests ?S’il s’agit pas des collègues de votre organisation, il faudrait peut-être leur donner quelquechose pour leur temps. Un bon d’achat, entre 20 et 50 euros par exemple. Ca dépend, si c’est un application pour des medecins, çå risque de ne pas marcher.Quand tu auras quelques possibilités, je prefere au moins les avoir au téléphone. Comme çå, tu verras si la personne sera suffisament communicative, et tu peut t’assurer que le personne correspond aux critères.Si ç’a l’air d’aller, fixer les rdv, ex: 9h, 10h, 11h afin de faire une matinée de tests
Et là aussi, je crois que nous, les agilists, on est bien placés, parce que on a l’habitude de penser en terme de nos utilisateurs.Rien que le fait d’écrire des User Stories. On ditEn tant que, je veux faire TACHE, afin deDonc, entre notre vision de produit, et notre backlog de User stories, et les autres éléments (personae et storyboards), on peut très vite sortir une liste de taches essentielle à la réussite de notre produit.Puis on va choisir des tâches qu’on veut tester. Ca peut être les plus importantes, ou celle qui correspondent aux fonctionnalités qu’on a developpé recemments,…Mais, on ne peut pas donner les tâches directement aux utilisateurs comme ça. On n’a pas tendence à se lever le matin et se dire “aujourd’hui, j’ai envie d’annuler une reservation d’une chambre d’hotel”On va donc prendre chaque tâche et le transformer en scenario.
Créer des scenarii à partir d’une ou plusieur tâchesContexte (pour encourager une utilisation réalisteObjectif clairInfos supplementaire qu’il fautPenser a tester des cas “negatifs” aussi, ex: le mot de passe est périmé, le compte est bloqué, le produit n’existe plus, etc. Il faut bien tester ces cas parce que notre “relation” avec l’utilisateur est plus tendu à ces moments, donc il faut que l’ergonomie soit nickelIl faut suffisament de scenarii pour occuper l’utilisateur pendant ~40 minutes. Vaut mieux en avoir un peux trop, que pas assez
Quelquesastuces pour faire de bonnesscenarii1. Il faudraitqueçasuffit pour effectuer la tâche2. Donner les détailsqu’ilfaut, mais pas plus. Casertàriend’imaginercombien de chats la personne a à la maisonsic’est pas pertinent pour les tests3. Utiliser lelangage de l’utilisateur, pas de l’équipe de developpement4. Il faut les tester. on va donner les scenarii à quelqu’un qui n’a pas participé à leur définition. On va démander à cetter personne atteindre l’objectif. Comme ça, on va reperer tout ce qui n’est pas clair ou les informations qui manque, par exemple noms d’utilisateurs, numéros de carte bleue, etc.
Dejà,ilfauttrouver un lieu pour les tests.Le choix le plus simple, c’est de trouver un bureau ouunesalledansvotrebatiment. Il fautjustes’assurerquevous ne serez pas dérangésS’il y a beacoupd’activitéautour, çapeutêtredérangeant pour l’utilisateur, et les tests risquent d’être moinsutile.Unesalle de réunion par exemple.Pour un application desktop ou web, il faudrait un ordinateur, et deux chaise: une pour l’utilisateur, et une pour vous.Il faut l’ordinateur.Il faut s’assurer que notre application soit accessible depuis l’ordinateur, juste au cas ou on n’est pas sur le même reseau, etc. Il nous faudra une version stable de l’application qui permettra aux utilisateurs de faire les tâches qu’on a préparées. Il faudrait que les bonnes comptes utilisateurs existe. Il faut aussi que les bonnes données soient disponible. Si on va demander à l’utilisateur d’acheter tel ou tel produit sur notre site d’ecommerce si la base ne contienne aucun produit !Dans l’idéal, un membre de l’équipe de development sera disponible le jour des tests pour dépanner en cas de besoin.On veut enregistrer la session, donc il faudrait un microphone. Même si ton ordinateur dispose d’un microphone integré, je trouve qu’il est mieux d’utiliser un microphone externe. Comme çå, vous pouvez le positionner entre vous et l’utilisateur pour que çå capte tout. Sinon vous allez peut etre devoir vous mettre très près de l’utilisateur ce qui n’est pas idéale.En plus de l’audio, on veut enregistrer ce qui se passe à l’écran. Pour ça, on il nous faut un logiciel. (Voir slide suivant)Ca nous ira très bien pour les applications auxquelles on accède avec un ordinateur. Mais, si on veut tester une application mobile ?
Il faut pouvoir voir l’écran PLUS les doigts de l’utilisateur.Une solution: On attache un webcam au téléphone avec un clip Brancher le webcam dansl’ordinateur,et on enregistre ce qu’elle voitEt on peut tester surn’importequel type de device. Tupeuxégalement attaché le webcam àunehousse de mobile. Commeça le clip est derrière, et genera encore moinsl’utilisateur.L’important, c’estque le webcam n’est pas lourd, pour quel’utilisateur ne soit pas gêné.
Dernière validation du setup (+ déactiver plugins de navigateur e.g. adblock, vider le cache, cookies etc)Progamme du jour:3 sessions d’environ 1 heure.
Ok, donc, tout est en place, on est prêt à accueillir le premier utilisateur.On vas discuter un peu avec eux, proposer un café ou un verre d’eau etc. L’idée c’est juste de mettre la personne à l’aise.Puis on va s’installer dans la salle de test.D’abord, si on propose un compensation ànos utilisateurs, c’est le moment de la donner. Comma ça, la personne sait qu’elle n’a pas a nous faire plaisir histoire d’être payer. Elle peut être aussi honnête qu’elle veut…. voire méchante ;)Puis, on explique le programme et comment ça va marcher. Combien de temps il faut, que la plupart du temps sera consacré aux scenarii, que tu repondra pas auxquestions pendant la tests mais à la fin. Là il faut aussi insister sur le fait qu’il est important que la personne pense à voix haute. On on parlera dans un moment. Il s’agit également de rassurer la personne, de dire que c’est pas elle qu’on test, c’est notre produit, qu’elle peut pas se tromper, que si quelquechose n’est pas clair, c’est parce que l’application est toujours en cours de developpement, et c’est en aucun cas de leur faute. Tant qu’elle parle à voix haute, ça nous sera utile.Vu qu’on va enregister la session, et la voix (et peut être l’image) de la personne, il faut expliquer ça et surtout ce que tu vas faire avec l’enregistrement, etc. Il faut que l’utilisateur signe leur accord d’être enregistré. C’est juste un petit formulaire qui explique que l’enregistrement va servir pour améliorer ce produit, que ça va rester en interne de l’équipe, et vas pas le balancer sur youtube etc !Puis, si la personne n’a pas de questions, tu peut commencer.Il faut juste pas oublier de lancer l’enregistrement a ce moment !
La chose la plus important qu’ilfaut dire aux utilisateurs, estqu’ilfautqu’ilpenseàvoix haute. Il vafalloir les relancer, peut-êtretrèssouvent. C’estvraiment la clée de cette technique.Si on n’aquel’enregistrement de l’écran, sans entendre les pensées, on aura le même probleme qu’avec les analytics web- on aura le quoi, mais pas le pourquoi.De voirceque la personne fait, c’estinteressant. Mais on veutsurtout savoir *pourquoi* elle a fait ça.La personne a passé 5 minutes surcette page. Est-cequ’elle a trouvé le contenutrèsinterssant, ouest-cequ’elle cherchait désesperamment ou il fallait cliquer?Donc, ilfautdémanderà la personne de penseràvoix haute en continue. Il y a des gens à qui çavienttrèsnaturellement, et il y en a à qui ilfaut le rappelertous les 10 seconds. “qu’est-cequevousêtes en train de penser?” “Qu’est ce que vous êtes en train de regarder ?” “Qu’est ce que vous êtes en train de faire ?”
Il est bien de commencer par des questions ouvert, par exemple, “A votre avis, c’est quoi cette application ?” (ou “cet écran”, “cette page”, “que pouvez vous faire ici”, etc) Ce sert à habituer la personne a penser à voix haute, à se détendre, à oublier qu’on l’enregistre. Donc, tu peux passer quelques minutes, et puis presenter la première tâche.La, on commence les scenarii* Lire le scenario. Lireexactementcequetu as écris. Sinon, turisque de donner des indices. Tu as fait attention a donner la bonne niveau de detail et d’utiliser le bon langage. Il fautdonc lire exactement, mot-par-mot ce qui estsur la feuille.Donner la feuilleàl’utilisateurRappeler àl’utilisateur de penseràvoixhauteDemander àl’utilisateur de vous dire quandilpenseavoirfiniTu vas devoir rappelerl’utilisateur de penseràvoix haute de temps en temps.S’ilte pose des questions, ilfaut les renvoyerverslui: “je ne m’attendais pas àça” -> “ah, vousvousattendiezà quoi ?” etc. Il faut encourager la personne, maisil ne faut pas dire “trèsbien, bravo”, maisplutot “c’esttrès utile pour nous”Il faut pas aider l’utilisateur: ça ne sertàrien de les inviter situ vas leur dire cequ’ilfaut faire.Les autres questions, e.g. “pourquoiest-ceque les boutonssont oranges” etcetc, tuluiditqueturépondrasà la fin.Tupeuxprendre des notesQuand l’utilisateur pense avoir fini, ou quand tu te rends compte qu’il va jamais finir, procéder à la scenarii suivanteEt tu continue comme ça jusqu’à la fin tu temps alloué, ou jusqu’à ce qu’il n y a plus de scenarii. Ou, si vous vous rendez compte que l’utilisateur va jamais terminer, proposer gentiment de passer au scenario suivant.
Si l’utilisateur a posé des questions, c’est le moment de répondre (ou proposer de le contacter avec les réponses plus tard)Vous arretez l’enregistrementLa personne partVous réinitialisez toutVous complétez vos notes, si besoinPuis vous enchainez avec l’utilisateur suivant
L’import est de rapidement concretiser le valeur recolté lors des tests.On a actuellement ~ 2hrs de vidéo. Il faut les utiliser pour enrichir notre backlog.Evidement, ça dépend de votre organisation, composition de l’équipe, et surtout votre système de gestion des exigences.An exemple:Identifier les gens qui vont participer (facilitateur, PO, ergonomes, graphistes, …)Ces gens regardent les vidéos avant (s’ils n’ont pas participé en temp réelle par partage d’écran)Individuellement, ils notent les problèmes d’ergonomie qu’ils constatentEnsemble, ils les analyse *rapidement* (elimination des doublons, etc)Puis ils créent une User Story par probleme (ou idée)Chaque user story aura un lien vers la video (hebergé dans le wiki), et le moment qui a inspiré la story, plus les notes, idées etcPuis le User Story est mise toute de suite dans le backlog (qui est priorisé)Ces User Stories vont évoluer, murir, mourir comme les autresOn a donc rapidement progressé de rien (matin), données brute, (midi), possibilité d’un meilleur produit (fin de journée).
On a vu les facteurs qui rendent les projets agiles favourable à la mise en ouvre des tests utilisateursUne methodologie simple, legère, productiveQue c’est maintenant à vous d’imaginer comment mettre en place des tests utilisateurs sur vos projets: vos utilisateurs vous remercieront !
