Nous proposons un atelier de prototypage rapide d'une app mobile suivi d'un atelier de testing. L'app a réaliser répond au ppm suivant : comment organiser une soirée à la dernière minute en évitant d'avoir 10 bouteilles de whisky et rien à manger :-)
Sur la base d'un brief, les participants sont invités :
- à décrire le profil utilisateur + JTBD (customer profile canvas)
- à réaliser le prototype de l'application (le flow et les features essentielles)
- à tester leur prototype avec le public
Puis debrief avec analyse des metrics puis modification du prototype avant nouvelle itération.
4. Le brief
27/09/2017
4
• Albert organise un dîner où chacun doit apporter quelque chose.
• Mais c’est difficile de coordonner les invités sur ce qu’ils vont
apporter
• Et si on faisait une application pour mobile ?
5. Qui sont les utilisateurs ? Exemple de Persona
27/09/2017
5
6. Exercice : Quels sont les besoins d’Alexia ?
27/09/2017
6
• Mettez-vous dans la peau de vos utilisateurs pour connaître leurs
motivations réelles
Pain
Exemple : Je risque de ne pas apporter ce
qu’il convient
Gain
Exemple : Je vais gagner du temps
Job to be done
Exemple : Qui apporte quoi ?
7. Scénario d’utilisation
27/09/2017
7
• Quel scénario va t-on
prototyper ?
• Celui qui a le plus d’impact
• Pour cet atelier : La version la
plus simple
• Décomposer en étapes,
du point de vue de l’utilisateur
• Les étapes clefs vont devenir
les écrans principaux des
écrans mobiles
8. Exercice : Scénario d’utilisation
27/09/2017
8
Depuis l’invitation d’Alexia jusqu’à la confirmation de ce qu’elle apportera
Exemple :
Sélection
d’un plat
11. Tester le prototype
27/09/2017
11
Pour vérifier que nous sommes en train de construire ‘The right
thing’
• Vérifier aussi tôt que possible que notre solution répond au besoin de
l’utilisateur
Pour améliorer le produit
• Itérations
12. Exercice - Rôle du testeur (10 minutes)
27/09/2017
12
Réalisez une tâche avec le prototype :
• « Un de vos amis vous a invité à une soirée. Vous devez apporter quelque chose à boire
ou à manger.
Montrez-moi comment vous feriez pour préparer votre soirée en utilisant l’interface que
nous vous proposons. »
« Pensez tout haut »
13. Exercice - Rôle de l’observateur : Observer, écouter, noter
27/09/2017
13
• Ne pas influencer le participant
• Questions ouvertes pour comprendre pourquoi le participant fait
ce qu’il fait
• Noter le parcours du testeur
17. Qu’est-ce qu’on peut tester ?
27/09/2017
19
• Qu’est-ce qu’on peut tester ?
• N’importe quel parcours d’utilisation peut être testé, du moment que toutes les
étapes du parcours sont présentes.
• Peu importe le support : papier, maquette Axure ou Sketch, site en ligne …
• Aussi possible de tester les services d’un concurrent
Exemple de wireframe fait avec Axure Exemple d’espace de travail Sketch + InVision
18. Tester bien
27/09/2017
20
• Mettre le testeur en position d’utilisateur actif, pas de contemplateur
• Le testeur doit être un véritable utilisateur potentiel (ex : pas un collègue complaisant)
• Distinguer ce que les utilisateurs font Vs ce que les utilisateurs disent.
• En cas de contradiction, les faits sont plus importants que les opinions.
• Vérifier en début d’entretien que la personne est un vrai utilisateur potentiel, c’est
à dire qu’elle a un besoin réel (= problème à résoudre)
• Pour trouver des ‘vrais’ utilisateurs : Recruteur, groupes FB, … comme on trouverait ses
clients
• Ne pas influencer le testeur
• Le minimum d’affect (ex à éviter : ‘c’est moi qui l’ai fait’, soupirer, s’énerver)
• Pas d’indice dans la tâche ou lors des discussions préliminaires
• Questions ouvertes
• Faire observer par d’autres personnes de temps en temps
• Pour avoir un autre regard
19. Tester vite
27/09/2017
21
• Pas besoin d’équipement spécifique
• Mais enregistrer si possible
• 3 à 5 participants par persona
• Tester soi-même
• On a tout de suite l’information
• Pas cher
Nielsen et Landauer - 1993
20. Itérer
27/09/2017
22
• Mettre à jour le prototype
• Après avoir eu la certitude que le parcours doit être modifié
• Tester une hypothèse à la fois
Notes de l'éditeur
A prévoir, pour 20 participants (5 groupes de 4) :
Ecran + videoprojecteur (+ connecteurs ! + Micro caméra ipevo). Audio pas nécessaire
Tables OU flip charts : une table ou Flipchart par groupe de 4 personnes (5 personnes max par table)
1 flipchart pour les animateurs, pour prendre des notes pendant les debriefing
Paquet de 50 bristols A6 pour faire le prototype (10 par table), et feutres 4 couleurs par table, don’t un noir.
Post-its : 60 par table (idéalement : 20 verts, 20 oranges, 20 jaunes)
Intro + Brief : 15 minutes
Présentations
Qui est dans la salle ?
Si le temps le permet : Tour de table 30 secondes chacun : Prénom, fonction, qu’espérez-vous de cet atelier ?
Sinon : mains levées. Qui a un produit à concevoir ? Qui est développeur ?
Dans les présentations : parler de l’association Lean Startup Experience
Démarche :
Identifier les utilisateurs
Comprendre leurs attentes
Décrire un parcours d’utilisation
Réaliser un prototype testable
Tester le prototype avec des utilisateurs
Profil : possesseurs de smartphone, travaillent – occupés, motivés à l’idée d’apporter leur contribution.
Consigne : Dessinez le rond et les trois parties sur le flipchart
Heure de Début + 15 Minutes. Durée : 10 minutes
‘Customer profile’
Expliquer et DONNER DES EXEMPLES de Pain, gain, job to be done.
http://www.simplydirect.com/step-into-your-buyers-shoes-creating-actionable-customer-profiles/
Customer Pains: Ce que l’on veut éviter.
In the box ‘Customer Pains’ you gather all the negative emotions and undesired costs, situations and risk which the customer could experience before, during and after getting the job is done. Obstacles, risks, undesired outcomes.
Exemple :
Transports : Je n’ai pas le temps de voyager pour voir cet ami.
Customer Gains: Outcome and concrete benefit for the customer. In the box ‘Customer Gains’ you gather all the customer’s benefits and desires, and may span personal, functional, or economical etc. For example, this box could include positive emotions, functional requirements, or specific cost savings.
Transports :
Job to be Done : What the job the customer is trying to get done. In the box ‘Customer Jobs’ you gather all the customer needs, the problems that they are trying to solve and the tasks they are trying to perform or complete.Comme s’il demandait à un fournisseur de faire quelque chose. Du point de vue et dans les termes du consommateur. Exemple : Exemples :
Empêcher que mes récoltes soient dévastées par les parasites.
Aller le plus vite possible d’un point A à un point B
Heure de début + 30 minutes
Quel scenario a le plus d’impact ?
Pour la persona ‘Organisateur :
Connaître l’app
Choisir l’app et l’installer
Créer mon premier dîner : inviter des amis, proposer une date et un lieu, etc
Vérifier la progression de l’organisation
-Etc
Pour la persona ‘Invité’ :
Recevoir l’invitation, et installer l’app
Une fois l’app installée, prendre connaissance de l’évènement et contribuer (C’EST LE SCEANRIO QUE NOUS ALLONS RETENIR)
Suivre l’avancée de l’évènement
Etc
Heure de début + 30 minutes
Durée : 20 minutes
Scénario : Depuis l’invitation d’Alexia jusqu’à la confirmation de ce qu’elle apportera
Durée :
Attention : différence avec le vocabulaire utilisé en développement Agile :Epic, user story, feature…. Voir http://www.berejeb.com/2016/02/construisez-votre-user-story-map-en-5-etapes-faciles-une-autre-facon-de-representer-le-backlog-de-produit/
Livres :
- User story mapping, de Jeff Patton
Mapping Experiences (l’Ours Brun) de Jim Kalbach
Experience Maps de Robert Curedale
Exemple de 4 pages sur prototype papier réalisé par Frédéric sur des feuilles bristol A5, pour Yescape, service de location de camping cars entre particuliers (site mobile responsive).
Montrable sur écran avec une caméra iPevo
Livre :
Sketching User Experiences, de Saul Greenberg and….
Heure de début + 50 minutes
Durée : 30 minutes
Livre : le story mapping
Heure de début + 1h20 minutes
Durée : 2x10 minutes
Pour dérisquer
Mieux connaître ses clients : Que font-ils et pourquoi ?
Nous ne sommes pas les clients de notre solution (point de vue différent)
Entretiens et observations individuelles
Heure de début + 1h20 minutes
Durée : 2x10 minutes
La tâche ne doit pas comporter d’indice qui aide le participant à utiliser l’interface (ex : nom des rubriques dans le libellé de la tâche)
Noter le parcours : Obstacles (= déviations) le long du parcours principal
Noter quelques verbatims
Relance éventuelle : « Qu’est-ce que vous pensez ? Montrez-moi comment vous faîtes.»
Exemples d’autres mesures :
Temps mis pour réaliser une tâche (efficience)
Nombre de clics sur tel objet (efficicence)
Mesure qui permette de valider une hypothèse. Ex :
Taille du panier,
Nombre de participant qui ont utilisé la géolocalisation d’un supermarché
Nombre de participants qui ont utilisé l’option de livraison au domicile de votre ami
Livrables :
Qui sont les utilisateurs > Personas
Quels sont leurs but > Customer profile (pain, gain, job to be done)
Quel est leur parcours ? (journey map)
Quel est le résultat ? (KPI d’usage et business)
Résumé pour réaliser un test utilisateur :
Définir une tâche importante pour le client et pour le service à tester
C’est un ‘problème’ pour lequel le service propose une solution
Prototyper :
Dessiner tous les écrans qui permettent de réaliser le parcours à tester
Si on laisse le testeur imaginer certaines étapes, on ne sait plus ce qu’on évalue.
Peu importe le support. Le niveau de qualité graphique (papier, wireframe, maquette cliquable, …).
Trouver 3 à 5 vrais utilisateurs potentiel, représentatifs de votre cible principale (persona).
Consignes : ‘Montrez-moi’, ‘Pensez tout haut’
Observer, écouter, noter
Mesurer : Efficacité, efficience, satisfaction
Analyser (Learn) : Identifier les besoins, les patterns pour des groupes d’utilisateurs, les obstacles sur le parcours.
Itérer
Partie à imprimer.
On peut la montrer si on a le temps, et /ou pour répondre à des questions
Objectifs d’un bon prototype qui permet de tester des hypothèses :
Basique
Rapide (à faire)
Adapté
L’objectif premier du prototype n’est PAS de communiquer auprès de clients potentiels comme pourraient l’être un prototype de voiture (qui permet aussi de valider la faisabilité technique)