• Save
Agilité et les Tests Utilisateurs
Upcoming SlideShare
Loading in...5
×
 

Agilité et les Tests Utilisateurs

on

  • 1,081 views

 

Statistics

Views

Total Views
1,081
Views on SlideShare
1,080
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

https://si0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 !

Agilité et les Tests Utilisateurs Agilité et les Tests Utilisateurs Presentation Transcript

  • #agilefranceAgilité et Tests UtilisateursSat PhiloraAgilist & Consultant User Experience Merci à nos sponsors :à Valtech web & mail gold
  • Un test utilisateur ? Utilisateur Application
  • Tester le plus tôt possible“Testing one user early in the project isbetter than testing 50 near the end”-  Steve Krug
  • T utilisateurs idéaux pour les projets agiles ests Deploy me!! Feedback Liberté Livrable
  • T utilisateurs « discount » ests vs €€€€€ €
  • « il faut beaucoup d’utilisateurs pour les tests » http://www.useit.com/alertbox/20000319.html
  • 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
  • A faire Préparer l es tests Utilisateurs Tâches t E nvironnemen Dérouler l es tests Analyser et agir
  • Qui vont être nos utilisateurs ?
  • Comment les recruter ? Appâter Filtrer Confirmer
  • 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
  • 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
  • Les scénarii : des astuces * Il était une Select fois… from productsEcrire... ...le minimum Le bon langage Tester le test
  • Préparer l’environnement Salle de réunion Ordinateur Microphone Techie Facilitateur 2 chaises Application
  • Enregistrer l’écran Mac Quicktime Silverback gratuit $70 Windows gratuit
  • Comment enregistrer des mobiles ? http://blog.mailchimp.com/recording-mobile-usability-tests/
  • A faire Préparer l es tests Utilisateurs Tâches t E nvironnemen Dérouler l es tests Analyser et agir
  • Le jour des tests Pour chaque utilisateur : Introduction – 10 mins Tests : 30 – 40 mins Conclusion : 5 mins
  • Session : IntroductionBonjour Rémunérer Expliquer Accord Questions ? Action !
  • La pensée à voix haute Je ne vois pas Je ne vois pascomment sauvegarder comment sauvegarder « A quoi êtes-vous en train de penser ? »
  • Session : Test Bla blaPremier Scénario Voix haute Encourager… …mais ne pasaperçu aider
  • Session : ConclusionQuestions ? Coupez ! Au revoir Réinitialiser Notes
  • A faire Préparer l es tests Utilisateurs Tâches t E nvironnemen Dérouler l es tests Analyser et agir
  • Et maintenant ? Product backlog Problème User story StoryVidéos (+ solution ?) Story
  • Messages clés Deploy me!! Idéals pour l’agilité Methodologie Action !
  • RéférencesLivres•  Usability Testing Essentials - Carol M. Barnum•  Rocket Surgery Made Easy - Steve KrugLiens•  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
  • Questions ? @SatPhilora