IFT2905 Interfaces personne-machine 11. Tests usagers
S´ebastien Roy
D´epartement d’Informatique et de recherche op´erationnelle Universit´e de Montr´eal
19 mars 2007 Universit´e de Montr´eal
Horreur oiu splendeur?
Horreur oiu splendeur?
Trop de d´etails. (minimalisme)
Positionnement affreux (paragraphes? titres?) (esth´etique) Aucune organisation pour aider l’usager `a sauter ce qu’il sait et aller vers ce qui l’int´er`esse (flexibilit´e et efficacit´e)
Information inutile et hors contexte (aide et documentation) Dialogue modal (l’information disparait apr`es ok)
(m´emorisation)
Termes techniques (V.90 modem) (connecter avec le monde de l’usager)
... jot down the model number... (reconnaissance vs m´emoire)
Au programme
Les tests usagers
Placer une interface devant un vrai usager.
´Ethique
Lorsqu’on utilise des vraies personnes pour des tests, on doit prendre en consid´eration de nouveaux facteurshumains.
´Evaluation formative
Test usager qui est effectu´e pendant les it´erations du
d´eveloppement. Le but est de trouver les probl`emes d’utilisabilit´e et de les r´egler `a la prochaine it´eration.
Les diff´ erents tests usagers
1. ´Evaluation formative
Trouver les probl`eme pour la prochaine it´eration
Evaluer un prototype ou une implantation, en laboratoire, sur´ une tˆache pr´ecise
Observations qualitatives (probl`emes d’utilisabilit´e)
Ce type de test usager a ´et´e fait lors des tests des prototypes papiers (avec de faux usagers par contre).
L’environnement est contrˆol´e, comme un bureau, et c’est
l’´evaluateur qui choisi les tˆaches `a tester. Ces tˆaches sont r´ealistes et proviennent de l’analyse des besoins faite au d´epart.
Un probl`eme...
L’environnement n’est pas tr`es r´ealiste et on ne sait pas si l’interface sera ad´equate en situation r´eelle.
Les diff´ erents tests usagers
2. ´Etude sur le terrain
Trouver des probl`emesen contexte
Evaluer une implantation fonctionnelle, dans un vrai contexte,´ sur des vraies tˆaches
Observations surtout qualitatives 3. Exp´erimentation controll´ee
Tester un hypoth`ese (ex: interface A plus rapide que interface B)
Evaluer un implantation fonctionnelle, dans un environnement´ control´e (labo), sur des tˆaches choisies
Observations surtout quantitatives (temps, taux d’erreur, satisfaction, ...)
Ethique ´
Les usagers sont des humains...
Lescobayes humains ont ´et´e s´erieusement abus´es dans le pass´e.
Camps Nazi (1940-1945)
Tuskegee syphilis study (1932-1972)
MIT recherche sur les isotopes radioactif (1940-1960) Yale (≈1950) sur les chocs ´electriques
McGill (1950-1962) exp´erience sur le LSD et la privation sensorielle
La recherche impliquant des humains doit ˆetre approuv´ee par un comit´e d’´ethique.
Code de Nuremberg
UdeM: Comit´e universitaire d’´ethique de la recherche (CUER) et les interfaces usagers?
L’usager sous pression
L’usager peut ressentir diff´erentes formes de pression Angoisse de la performance
Impression de passer un test d’intelligence Comparaison avec les autres
Se sentir stupide devant des observateurs Comp´etition avec les autres
L’usager est le centre d’attention, observ´e par des ´etrangers ou une cam´era, et doit faire des tˆaches qui ne lui sont pas famili`eres devant un interface qui peut ˆetre mauvaise.
La pression est bien r´eelle.
L’usager sous pression
Un sp´ecialiste en utilisabilit´e, Jared Spool (www.uie.com) raconte un cas o`u l’usager `a fondu en larmes... (source: Carolyn Snyder, Snyder consulting)
L’utilisateur original ne n’est pas pr´esent´e. On a pris quelqu’un qui passait par l`a.
C’´etait la premi`ere journ´ee d’embauche de cette personne.
Personne ne lui a expliqu´e ce qui ´etait pr´evu
La personne ne connaissait rien `a l’interface (bon!) ni au domaine (mauvais!). Elle ne repr´esentait pas l’usager normal.
Les observateurs ne savaient pas qu’il fallait se taire.
Un des observateur ´etait son patron
Les tˆaches ´etaient mal choisi´es. La premi`ere ´etait impossible.
Respect de l’usager
L’usager doit ˆetre trait´e avec respect...
Ne pas gaspiller de temps Pr´eparer tout d’avance
Ne pas faire installer le logiciel (sauf si c’est `a tester).
Rendre l’usager confortable
Cela r´eduit beaucoup la pression ressentie Informer le mieux possible l’usager
Mais attention de ne pas biaiser les tests Ne pas cacher inutilement des choses Pr´eserver la vie priv´ee de l’usager
Ne pas publier les r´esulats en identifiant les usagers L’usager doit pouvoir arrˆeter `a tout moment
Avant un test
Temps
Faire un test pilote du mat´eriel et des tˆaches Confort
“Ce n’est pas vous qu’on test, c’est l’interface.”
“Si vous avez un probl`eme, c’est la faute du syst`eme. C’est justement ce qu’on cherche `a trouver.”
Vie priv´ee
“Les r´esultats seront confidentiels.”
Information
R´esumer le but du test
Informer sur l’enregistrement, vid´eo, les observateurs R´epondre aux questions avant de commencer Contrˆole
“On arrˆete quand vous voulez.”
Pendant le test
Temps
Eliminer les tˆ´ aches inutiles Confort
Atmosph`ere calme Prendre des pauses
Ne jamais paraˆıtre d´e¸cu (de votre interface) Donner les tˆaches une `a la fois
Commencer par les tˆaches faciles Vie priv´ee
Le patron/directeur/professeur de l’usager ne devrait pas assister
Information
R´epondre au questions (si pertinentes) Contrˆole
L’usager choisit de continuer ou non.
Apr` es le test
Confort
Mentionner `a l’usager ce qu’il a aid´e par sa participation Information
R´epondre aux questions qui pouvaient biaiser l’exp´erience (C’est quoi ce bouton?
Vie priv´ee
Prot´eger l’identit´e des usagers dans les r´esultats Ne pas envoyer les vid´eos sur YouTube
Et voil`a!
Evaluation formative ´
Trouver des usagers
...repr´esentatifs des vrais usagers (selon l’analyse des usagers)
Donner `a chaque usager des tˆaches
...repr´esentatives des vraies tˆaches (selon l’analyse des besoins)
Observer l’usager ´ex´ecuter les tˆaches
Les rˆ oles
En ´Evaluation formative, il y a trois rˆoles distincts:
L’usager Le facilitateur Observateurs
L’usager
L’usager doit penser `a voix haute
Dire ce qu’il pense de ce qu’il advient Dire ce qu’il veut faire
Dire pourquoi il a fait chaque action Probl`emes
L’usager se sent inconfortable
Penser `a vois haute peut modifier un comportement Rend la concentration plus difficile
Une autre aproche: Deux usagers
Deux usagers vont probablement se parler naturellement aussi appell´e co-d´ecouverte, ouint´eraction constructive
→ presque aussi commun que l’approche `a un seul usager
Le facilitateur
Le facilitateur est le responsable du test usager Explique le test
Propose les tˆaches
Incite l’usager `a penser `a voix haute
“ `A quoi pensez-vous?”
“Pourquoi avez-vous fait ¸ca?”
Controle la session de test et empˆeche les observateurs d’interf´erer
Il faut aussi qu’il aide les usagers `a se sortir d’une impasse, mais seulement apr`es avoir not´e le probl`eme.
L’Observateur
L’observateur observe Silence!
Ne pas aider, ne pas expliquer, ne pas montrer les erreurs Utiliser un baillon si n´ecessaire...
Prendre des notes
Etre attentif aux incidents marquant qui affectent laˆ performance ou la satisfaction
En g´en´eral n´egatif
(erreurs, essais r´ep´et´es, insultes prof´er´ees `a l’ordinateur) Parfois positif
(“Cool!”,“Ah! Maintenant je vois!”, ... )
Enregistrement des observations
Crayon et papier
un formulaire pr´epar´e d’avance peut ˆetre utile Enregistrement audio
pratique pour lePenser `a vois haute Enregistrement vid´eo
Souvent 2 cam´eras (visage de l’usager, et ´ecran) L’usager peut ne pas aimer ˆetre film´e
Parfait pour des observateurs dans une pi`ece s´epar´ee Pr´eserve trop de donn´ee
Possibilit´e de retour en arri`ere pour identifier des moment critiques
Capture d’´ecran et journal des ´evenements simple, pas cher, et ne d´erange pas l’usager
Ce que Krug en pense
Don’t make me think
Chapitre 9 : Usability testing on 10 cents a day Chapitre 10 : Usability as common courtesy Les test usager en pratique...
... too little, too late, and for all the wrong reasons
C¸ a commence souvent par “quel th`eme de couleur doit-on choisir?”
LesFocus group ne sont pas des tests usagers
LeFocus groupest une petit groupe de gens (5 `a 8) autour d’une table qui r´eagissent `a des id´ees et des designs qu’on leur lance.
Ce que Krug en pense
Quelques v´erit´es sur les tests...
Vous voulez un bon site web? Il faut le tester
Celui qui con¸coit un site est trop familier. Il en sait trop.
→ tout le monde ne pense pas comme nous.
Tester sur un usager est 100% mieux qu’aucun test.
Tester fonctionne toujours, mˆeme si ce n’est pas id´eal (usager mal choisi, tˆache mal choisie, ...)
Tester un usager au d´ebut est mieux que 50 `a la fin
Plus on test au d´ebut d’un projet, plus le test est utile et efficace.
L’importance d’avoir l’usager parfait est exag´er´ee
C’est bien d’avoir un usager repr´esentatif des vrais usagers du site, mais c’est plus important de tester au d´ebut et souvent.
Ce que Krug en pense
Quelques v´erit´es sur les tests...
On ne teste pas pour prouver, mais pour apprendre On pense souvent tester pour prouver que l’interface A est meilleure que l’interface B. Pour cela, il faudrait une exp´erimentation contrˆoll´ee.
L’´evaluation formative va plutˆot consolider notre jugement pour prendre une d´ecision sur l’interface.
Tester est un processus it´eratif
On ne teste pas une seule fois. On teste, on r´epare, on teste, on r´epare, on test, on r´epare...
Rien de mieux que la r´eaction en direct d’un auditoire
La r´eaction des usagers est tellement difficile `a pr´evoir qu’il vaut mieux l’observer.
Les excuses
Les 5 meilleurs excuses pour ne pas faire de test...
“On n’a pas le temps”
“On n’a pas l’argent”
“On n’a pas l’expertise”
“On n’a pas un laboratoire d’utilisabilit´e”
“On ne saurait pas comment interpr´eter les r´esultats”
La suite dans le chapitre...
