https://www.etiennegarbugli.com
Slides for a course I created for the Computer Research Institute of Montréal (CRIM) in Canada. UX design and testing in an agile context.
2. +
Étienne Garbugli
n Consultant en expérience utilisateur
n Université Concordia
n Ordre des Conseillers en Ressources Humaines Agréé
n Ericsson, Evolio, Notarius, Radio Canada
n Lead User Experience Design,ThoughtWorks
n Responsable pour la Chine
n Lead Usability Analyst, Aeroplan
n 2x fondateur d'entreprises en technologie
n Auteur du livre ‘Lean B2B’
2
3. +
Exercice
n Inscrivez une question à laquelle vous
aimeriez obtenir réponse d’ici la fin de
la formation.
n Affichez votre question au tableau à
l’aide d’une note Post it.
n Nous allons y revenir.
Question sur l’arrimage de
l’ergonomie et de l’agile
3
4. +
Plan du cours
4
n Avant-midi
n Introduction et mise à
niveau
n Rôles et responsabilités
n Défis de l'arrimage
n Planification de projet agile
n Après-midi
n Planification et itération zéro
n Les « customer journey »
n Le design collaboratif
n La priorisation des
fonctionnalités
n Avant-midi
n Les tests utilisateur
n Le prototypage rapide
n Après-midi
n Et dans votre entreprise?
n Les nouvelles tendances
Jour 1 Jour 2
5. +
Objectifs
n Décrire
n les problématiques d’arrimage de l’ergonomie et de
l’agile
n Connaître
n les techniques de conception centrée sur l’utilisateur
pouvant être utilisées par les équipes de projet agiles
n Utiliser
n les bonnes techniques selon les besoins du projet et le
profil de l’équipe
5
10. +
Historique
n 1986: Modèle en spirale – Barry Boehm
n 1991: « Rapid Application Development » - James
Martin
n 1996: XP « eXtreme Programming » - Kent Beck
n 2001: Création du Manifeste Agile
n 2001: « Agile Software Development With Scrum » -
Ken Schwaber
10
11. +
Le manifeste Agile
n Nous valorisons:
n Les individus et leurs interactions plus que les
processus et les outils
n Des logiciels opérationnels plus qu’une documentation
exhaustive
n La collaboration avec les clients plus que la négociation
contractuelle
n L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais
privilégions les premiers.
11
http://agilemanifesto.org/iso/fr/
12. +
Aujourd’hui…
n Des dizaines de méthodologies dites agiles
n Rapid Application Development (RAD, 1991)
n Scrum (1996)
n RUP (1998)
n Extreme programming (XP, 1999)
n Adaptive software development (ASD, 2000)
n Crystal clear (2004)
n Etc.
n Chaque entreprise utilise sa propre version des
méthodologies agiles.
12
13. +
Pratiques communes
n Participation de l’utilisateur final aux groupes de travail.
n Autonomie et organisation centralisée de l’équipe.
n Spécification et validation permanente des exigences.
n Pilotage par les enjeux et les risques.
n Planification stratégique globale basée sur des itérations
rapides.
n Réalisation en jalons par prototypage actif itératif et
incrémental.
n Recherche continue d’amélioration des pratiques.
n Architecture à base de composants.
13
14. +
Exercice
n Individuellement, définir les
responsabilités de chacun des rôles de
la page suivante.
n Pour chaque rôle, identifier qui dans
votre équipe de projets a ces
responsabilités.
Rôles et responsabilités
14
15. +
Rôles et responsabilités
15
Rôle Responsabilités Responsable dans
mon entreprise
Analyste d’affaires
Développeur
Designer
Ergonome
Chef de produit
Testeur
21. +
Efficacité vs efficience
21
“Let’s say you’re very good at climbing up a tall
ladder, and can reach the top of it very quickly and
with little effort.Will that skill help you – if the ladder
is leaning against the wrong wall?
Even if you’re slower at climbing it, if the ladder is
against the right wall, you’ll eventually get to where
you want to be. It is more important that you are doing
the right things, than doing whatever you are doing
more efficiently.”
http://www.entrepreneurs-journey.com/5939/time-management-secrets-every-entrepreneur-should-know/
22. +
Quelques oublis
n Qui identifie le profil des
utilisateurs?
n Qui analyse les tâches des
utilisateurs?
n Qui s’assure de l’efficacité
de la navigation?
n Qui établit la stratégie de
contenu?
n Qui évalue l’efficacité de
ce qui a été mis en place?
22
23. +Le rôle du design, du designer
d'expérience utilisateur et de
l'ergonome
23
24. +
Le designer
Le designer conçoit un produit en harmonisant les
critères esthétiques et fonctionnels. Il est ainsi
l'interface entre les services commerciaux qui
détermine les besoins des clients et les services de
fabrication. Il réunit les impératifs des uns et des
autres pour les formaliser en un produit.
24
25. +
Le designer UX
25
L’UX designer est responsable de la relation, de
l’usage et de l’interaction entre l’humain et la
solution; il n’est pas dans la promesse, une
manipulation ou un rêve. Il cherche, coconçoit et
vérifie la solution, pour donner une réponse
appropriée, conforme aux attentes, en prenant en
compte le contexte d’utilisation.
http://www.inndesign.fr/ux-design-lexperience-de-monika-kierecka/
27. +
L’ergonome
Il contribue à la conception et à l’évaluation des
tâches, du travail, des produits, des environnements
et des systèmes en vue de les rendre compatibles
avec les besoins, les compétences et les limites des
personnes.
27
http://www.ergonomie-self.org/ergo/defergo.html
28. +
Les défis de l'arrimage avec agile
n Les techniques de l’ergonomie sont souvent perçues
comme plus appropriées en développement « cascade »
n L’ergonomie force les équipes à repenser les besoins des
utilisateurs finaux et à planifier l’expérience utilisateur
d’un point de vue plus holistique
n L’ergonomie est perçue comme un ajout de documentation,
allant ainsi à l’encontre des principes agile
n Chevauchements des responsabilités de l’ergonome avec
l’équipe technique, l’analyste d’affaires et le chef de
produit
n Différentes attentes quant à la qualité et la finition du
produit
28
30. +
Les bénéfices de l'arrimage avec
agile
n Planification holistique du produit permettant
d’augmenter la cohérence de la solution
n Possibilité d’explorer davantage d’alternatives
rapidement
n Assurer une plus grande pertinence et un plus
grand niveau d’ergonomie du produit final
n Réduction des risques
n Unification de la vision produit
30
36. +
Exercice
n Ma femme et moi venons de nous faire
construire une maison en banlieue.
Nous aimerions terminer le
terrassement de la propriété d’ici la
Saint-Jean-Baptiste.
n Je suis le propriétaire (chef de produit)
et vous êtes l’équipe de paysagement.
n Assignez un gestionnaire de projet
dans l’équipe et donnez-lui les
responsabilités de prendre des notes.
n Estimez le travail à effectuer et
complétez le paysagement de ma
propriété en mode agile.
Le paysagement de ma propriété
36
37. +
Vos contraintes
n Vous avez 7 semaines pour compléter le
paysagement de ma propriété
n Une semaine dure 10 minutes
n 4 carrés de gazon équivalent à 1 point d’effort
n Votre vélocité comme équipe est de 22
37
38. +
Votre « Backlog »
n Gazonner le terrain
n Asphalter l’entrée
n Installer une piscine
n Installer une galerie pour
le BBQ
n Construire un cabanon
n Planter des haies dans la
cour
n Planter des fleurs à l’avant
38
41. +
Techniques évaluées aujourd’hui
n Le parcours client
n Le « customer journey »
n La carte de l’empathie
n Le design collaboratif
n Le design parallèle
n Le « brain writing »
n Le « 6 up sketching »
n La priorisation des fonctionnalités
n L’analyse Kano
n La priorisation forcée
n L’impact vs faisabilité
41
42. +
L’inception de projet
42
Période préliminaire qui sert à l’organisation d’un
nouveau projet.
“No time is considered for design of the overall
framework. Scrum teams jump into feature releases.
They’re building inside out instead of outside in or
holistically.”
http://boxesandarrows.com/the-ux-professionals-guide-to-working-with-agile-scrum-teams/
43. +
Inception!= Itération Zéro
43
L’itération zéro ne résulte pas à une livraison de
fonctionnalités pour le client. Elle permet à l'équipe
de projets de se concentrer sur les processus qui
seront nécessaires pour l'adoption et l'utilisation de
la plupart des pratiques agiles.
46. +
Pourquoi une inception?
46
n Partager la vision
n Déterminer l’étendu du projet
n Comprendre les usagers
n Analyser les processus
n Partager les responsabilités
n Créer l’équipe et un momentum de projet
n Évaluer à haut niveau la solution technique
47. +
*Important
47
L’objectif de l’inception n’est pas de concevoir le
système en entier (« up-front design »).
Nous concevons juste assez pour nous permettre de
gérer le risque du projet.
49. +
Comment organiser une
inception?
49
qRéserver une grande salle où il sera facile de
circuler. S’assurer qu’il y ait des grands murs et
une grande table
qS’assurer l’accès à un projecteur, une imprimante
et une connexion Internet
qAssembler une équipe de projets
multidisciplinaire
qCentraliser les requis, la recherche, les stats, etc.
qÉtablir un plan pour l’inception
53. +
Planification de l’inception
53
n Une inception peut durer de 2 jours à 4 semaines
selon la durée du projet
n Toutes les inceptions sont différentes et doivent
être prévues en conséquence
n Un modérateur senior (souvent l’analyste) permet
de s’assurer du respect des « timeboxes »
n Les participants peuvent ajuster la cédule de
l’inception au jour le jour
54. +
Les règlements
54
n Fermer son téléphone
n Travailler en équipe
n Être ouvert d’esprit
n S’assurer de garder un niveau d’énergie élevé
n Ne rien prendre personnel
n Une conversation à la fois
n Sélectionner et bâtir. Et non accord / désaccord.
55. +
Le « Parking Lot »
55
n Pourquoi?
n Pour s’assurer que les sujets de discussion
demeurent pertinents
n Pour garder le momentum lors de l’inception
n Pour garder un oeil sur certains éléments qui
seront importants dans le futur
n Comment?
n Noter les discussions temporairement non
pertinentes afin d’y revenir à un moment plus
approprié
56. +
Le repartage
56
n Pourquoi?
n S’assurer que tous les participants soient à niveau
n Permettre aux participants de bâtir sur les idées du
groupe
n S’assurer qu’aucune bonne idée ne se perd
n Comment?
n Faire un tour de table afin de présenter les designs
ou idées de chacun après chaque exercice
58. +
Les personas
58
Selon « Ergonomic Garden », un "PERSONA" est un
archétype, une représentation fictive des utilisateurs
cibles, qu'on peut utiliser pour guider nos décisions
concernant les fonctionnalités, la navigation, les
interactions et même le design visuel.
60. +
Les personas
60
n Développer différents archétypes correspondants
aux publics identifiés
n Basé sur de vraies données (entrevues, recherche)
n Caractéristique des personas:
n Résultat d’observations et d’entrevues
n « Patterns » comportementaux
n Objectifs
n Habiletés
n Attitudes
n Contexte et environnements
61. +
Les personas
61
n Caractéristiques socio-économiques,
démographiques et attitudes
n Sexe (femme, homme, enfant), âge, nationalité, lieu de vie,
profession, nombre d’enfants, rôle social, revenu familial, style
de vie, niveau de scolarité, cadre d’utilisation, utilisateur
connu versus utilisateur inconnu.
n Niveau de tolérance et attitude envers l’informatisation,
attitude face à la tâche, motivation, langues maîtrisées et toute
autre information pertinente.
62. +
Les personas
62
n Niveau d’expérience avec le produit
n Identifier le niveau d’expérience ou technique dont
l’utilisateur aura besoin pour utiliser le produit interactif.
n Expert : plus de rapidité, prise de décision rapide,
concentration, supporte une plus grande charge de travail, a
une image mentale plus complète du système.
n Débutant : plus lent, apprentissage par étapes, sujet aux
distractions, aux surcharges, attention limitée.
n Compter sur le niveau d’expérience qui sera acquise avec le
temps.
63. +
Les personas
63
n Habilités physiques et accessibilité
n Déficience visuelle liée à l’âge
n Fatigue et stress.
n Problèmes d’audition et handicaps physiques plus lourds
n Vision : environ 1/3 de la population porte des lunettes et n’a
pas une vision parfaite
64. +
Les personas
64
n Diverses considérations:
n Diversités culturelles
n Langue parlée et écrite (police de caractères)
n Sens d’écriture et de lecture à l’écran
n Formats des dates, codes postaux, etc.
n Décalage horaire
n Conversion monétaire
n Représentations iconographiques (signes, conventions
sociales, protocoles)
n Couleurs et symboles
67. +
Personas vs Customer journey
67
n Le persona
n Détermine les besoins des utilisateurs et leurs aspirations
n Le « cutomer journey »
n Permet de comprendre l’expérience utilisateur en entier, le
contexte d’utilisation et les faiblesses des processus
68. +
Le « Customer journey »
68
n Le « customer journey » est toujours lié à un persona
et réutilise l’information collectée dans les entrevues
n Le début et la fin du parcours client sont identifiés
sur une séquence de temps
n Sur cette séquence, il faut déterminer les:
n Actions
n Sentiments
n Désirs et besoins
n Réflexions
69. +
Pourquoi un Customer journey?
69
n Pour mieux comprendre l’état d’esprit des
utilisateurs à chaque point d’interaction
n Pour améliorer la collaboration entre les canaux de
communication et départements
n Pour présenter une expérience utilisateur cohérente
à travers les canaux et départements
n Pour identifier le contexte, les faiblesses et les
incohérences
73. 73
Le Customer journey
Qui suis-je? Déclencheur
Étapes
Actions
/
Sentime
nts
Découverte Recherche Comparaison Achat
74. 74
Le Customer journey
Qui suis-je? Déclencheur
Étapes
Actions
/
Sentime
nts
Découverte Recherche Comparaison Achat
75. 75
Le Customer journey
Qui suis-je? Déclencheur
Étapes
Actions
/
Sentime
nts
Découverte Recherche Comparaison Achat
Réflexio
ns Processus de décision
76. 76
Le Customer journey
Qui suis-je? Déclencheur
Étapes
Actions
/
Sentiments
Découverte Recherche Comparaison Achat
Réflexions
Processus de décision
Opportunités
77. +
Exercice
n En équipe, utiliser l’information du
projet, du persona et les consignes afin
de créer un customer journey.
n Débuter par les déclencheurs, établir
les étapes et actions puis compléter
avec les réflexions et sentiments.
n Quelles sont les opportunités? Quels
sont les apprentissages?
Créer un « customer journey »
77
83. +
Le design collaboratif
83
Consiste à recruter un plus large éventail de
contributions au processus de conception. La
recherche de conception collaborative implique
souvent la création et l'observation de nouveaux
procédés de conception, destiné à aller au-delà des
rôles techniques classiques.
84. +
Pourquoi le design collaboratif?
84
n Permet au client et aux membres de l’équipe
technique de jouer le rôle de designers
n Permet d’avoir des échanges sains sur la conception
de l’expérience utilisateur et d’identifier les risques
n Facilite la communication des besoins et la
négociation de l’étendue des livrables
n Permet d’augmenter la participation de l’équipe et
d’aligner la vision
85. +
Et si je ne sais pas dessiner?
85
n Débuter par un exercice de réchauffement
n S’entendre sur des conventions de dessin simples
n Garder les exercices courts afin de forcer les
équipes à créer des designs minimalistes
n Faire le minimum de design afin de communiquer les
points principaux
86. +
Différentes approches
86
Approche Technique
Le design « 6 up » En groupe, l’équipe conçoit 6+ versions avant
d’en sélectionner une pour la raffiner.
Le design parallèle Chaque membre du groupe conçoit sa
propre version qui est ensuite partagée avec
l’équipe.
Le « brain writing » Chaque membre du groupe conçoit une
version qui est ensuite raffinée par la
personne suivante et ainsi de suite.
88. +
*Important
88
- Jim Glymph, Gehry Partners
If you freeze an idea too quickly, you fall in
love with it. If you refine it too quickly, you
become attached to it and it becomes very
hard to keep exploring, to keep looking for
better.”
89. +
Exercice
n En groupe, choisir une des techniques
de design collaboratif observées.
n Créer 6 différents designs rapidement
avant d’en sélectionner un à raffiner.
n Travailler soit sur le tableau blanc ou
avec des feuilles de dessin.
Collaborer pour créer un design
89
93. +
La priorisation forcée
93
n Créer une liste exhaustive des fonctionnalités
ou histoires utilisateurs à livrer
n Prioriser en groupe ou individuellement les
fonctionnalités
n Toutes les fonctionnalités doivent avoir une
priorité distincte (aucune égalité n’est
permise)
n Faire la moyenne des résultats
94. +
Impact vs Faisabilité
94
n Utiliser 2 dimensions sur une échelle de 1 à 5
n Impact / Importance
Quel est l’impact attendu de la mise en place de la
fonctionnalité?
n Faisabilité
Quel est le niveau de facilité de mettre en place de la
fonctionnalité?
n Limiter le pointage à 3 points par fonctionnalité
n Ex. 6 fonctionnalités voudraient dire 18 points par
dimension
96. +
Analyse Kano
96
n Modèle conçu par le professeur japonais Noriaki
Kano en 1984 en réponse aux idées
traditionnelles que la satisfaction du client est
simplement proportionnelle au niveau
fonctionnel du produit, service ou processus
n Permet d’obtenir des données sur la perception
de la qualité chez les utilisateurs
n Catégorise les fonctionnalités selon 5 attributs
http://fr.wikipedia.org/wiki/Modèle_de_Kano
97. +
Analyse Kano
97
n Obligatoires, indispensables - (Must be)
n Attractifs - (Attirants)
n Performance ou linéaires - (One-Dimensional)
n Indifférents - (Zone d'indifférence)
n Double tranchant - (Reverse)
http://fr.wikipedia.org/wiki/Modèle_de_Kano
98. +
Pourquoi l’analyse Kano?
98
n Découvrir toutes les fonctions indispensables du
produit
n Être compétitif en ce qui a trait aux requis de
performance
n Se distinguer de la compétition à l’aide des
fonctionnalités attractives
n Prioriser en fonction de la règle O > P > A > I
(obligatoires > performance > attractifs > indifférent)
n Analyse complexe, mais résultats fiables
99. +
Comment faire une analyse Kano?
99
n Préférablement effectué lors d’entrevues face à face,
mais peut être effectué en ligne ou en version papier
n À l’aide de la liste de fonctionnalités ou d’histoires
utilisateur, on crée un questionnaire standardisé
n 20-30 entrevues permettent de déterminer 90-95%
des fonctionnalités
100. +
Comment faire une analyse Kano?
100
n Pour chaque fonctionnalité, on demande:
n Comment vous sentez-vous si cette fonctionnalité est présente
dans le produit, service ou processus? (forme positive)
n Comment vous sentez-vous si cette fonctionnalité n'est pas
présente dans le produit, service ou processus? (forme
négative)
n Choix de réponses standardisés permettant de faire
le calcul rapidement.
n Version automatisée disponible en ligne:
n http://www.knockoutsurveys.com/kano
102. +
Exercice
n Établir la liste des fonctionnalités
émanant du design sélectionné.
n Créer le questionnaire pour les
fonctionnalités.
n Travailler avec des utilisateurs d’une
autre équipe afin de collecter des
résultats de sondages.
n Comptabiliser les résultats pour
chaque participant.
Prioriser les fonctionnalités en
utilisant l’analyse Kano
102
103. +
Calcul des résultats
103
Forme négative de la question
Forme
positive
de la
question
1. Like 2. Must be 3. Neutral 4. Live with 5. Dislike
1. Like
-- A A A P
2. Must be
D I I I O
3. Neutral
D I I I O
4. Live with D I I I O
5. Dislike
D D D D --
n Pour chaque participant:
A = Attractif
D = Double tranchant
I = Indifférent
P = Performance
O = Obligatoire
104. +
Retour sur la journée
104
Qu’allez-vous retenir de la journée?
105. +
En résumé
n Nous connaissons le contexte d’utilisation de notre
produit à l’aide du « customer journey »
n Nous avons un design préliminaire créé en groupe
lors de l’exercice de design collaboratif
n Nous avons priorisé nos fonctionnalités et savons
maintenant lesquelles ont de la valeur aux yeux de
nos utilisateurs grâce à l’analyse Kano
105
107. +
Quelles fonctionnalités
développer?
107
q Les fonctionnalités les plus simples?
q Les fonctionnalités les plus complexes?
q Les fonctionnalités les plus risquées?
q Les fonctionnalités ayant le plus de valeur pour
l’entreprise?
q Les fonctionnalités ayant le plus de valeur pour
les utilisateurs?
108. +
Une question de choix (iPhone)
n 3G
n Flash
n Bluetooth
n Caméra de qualité
n Caméra secondaire
n MMS
n Radio
n Vidéo
n GPS
n Java/Javascript
n Sonneries musicales
n Infrarouge
n Choix de fournisseur
n Support pour MS Office
108
http://www.zdnet.com/blog/apple/iphones-missing-features/390
111. +
Rôle de l’ergonome
n L’ergonome doit travailler sur plusieurs itérations à
la fois:
n N-1: Travailler avec les clients afin de s’assurer que le
produit mis en place répond bien aux attentes
n N: Être disponible au besoin afin de collaborer au
développement des fonctionnalités en voie de livraison
n N+1: Valider les prototypes avant le développement (A/B,
analytiques, tests utilisateurs, etc.)
n N+2: Effectuer le travail de recherche utilisateur, la
conception détaillée et les critères d’acceptation
111
112. +
Au jour le jour… Un exemple
(Itération 1 semaine)
112
Jour Tâches
Lundi Rétrospective et définition des fonctionnalités
Mardi Spécification des fonctionnalités
Mercredi Concevoir et raffiner
Jeudi Concevoir et raffiner
Vendredi Tester (feedback utilisateurs)
114. +
Le test d’utilisabilité
Le test d'utilisabilité, ou test utilisateur, est la
méthode la plus efficace pour évaluer un logiciel. Le
test consiste à observer directement l'utilisateur en
train de se servir de l'application. Il permet
d'identifier concrètement les problèmes.
L'utilisabilité peut être mesurée en calculant la
performance de l'utilisateur.
114
http://www.usabilis.com/methode/test-utilisateur.htm
116. +
Pourquoi des tests d’utilisabilité?
n Assurer la correspondance: modèle mental et tâche
n Identifier les difficultés rencontrées
n Tester les interactions complexes
n Clarifier la terminologie
n Vérifier certaines hypothèses
n Observer les comportements
n Mesurer les performances concrètes
116
117. +
Quelques alternatives
n Tests guérilla
n Tests en laboratoire
n Tests à distance (remote)
avec modérateur
n À distance sans modérateur
117
118. +
Différence avec les analytiques
n Les analytiques permettent de comprendre le
« où »
n Les tests d’utilisabilité permettent de comprendre
le « pourquoi »
118
119. +
Objectif des tests
n Exemples d'objectifs d'utilisabilité :
n « L’utilisateur devra trouver et sélectionner l’information X
à l’intérieur de 10 secondes ouY nombre de clics »
n « Le site devrait être maîtrisé par tel type d’utilisateur en
15 minutes de consultation ou de formation »
n « L'utilisateur devra acheter un produit en moins de 4
écrans de consultation »
119
120. +
Scénarios
n Séquence, suite d’actions requises
n Prévoir et observer les « chemins » empruntés
n Normalisation des résultats
n Scénario relié aux objectifs de test
n Réalisme: temps, expérience des utilisateurs, etc.
120
121. +
Organisation
n Matériel requis
n Questionnaires
n Ordinateur avec système d’exploitation X
n Navigateurs et versions (habitudes, profils des utilisateurs)
n Définition et résolution des écrans
n Type de connexion Internet au besoin : parfois, simulation
de modem 56K (régions éloignées)
n Matériel d’enregistrement et de prise de note
121
122. +
Nombre de participants
n Nombre de participants
n 3 – 15 participants
n Nielsen: 80 % de l’interface, 5 utilisateurs
n En agile, la fréquence est plus importante que le
nombre d’utilisateurs avec qui on teste
n 3 utilisateurs toutes les semaines est préférable à
8 utilisateurs tous les 2 mois
122
124. +
Organisation
n Recrutement
n Intranet/Logiciel propriétaire: recrutement interne
n Hasard: 5 participants, 5 départements
n Extranet: recrutement interne
n Internet/Logiciel grand public: recrutement interne ou
externe
n Entreprise spécialisée
n Liste de « candidats »
n Nécessité de définir le profil
124
125. +
Organisation
n Paiement
n À la discrétion des instigateurs
n Varie par profil, par région
n Variation des modes de paiement
n Certificat cadeau, jouet…
n Matériel promotionnel
125
126. +
Défis
n Fausses conceptions en agile:
n Les tests d’utilisabilité prennent trop de temps ou sont trop
lents
n Les tests d’utilisabilité sont trop difficiles à bien faire
n Les tests d’utilisabilité donnent le même type
d’informations que d’autres techniques
n Recruter des utilisateurs pour chaque itération
(plus grand défi)
n Réintégrer les apprentissages dans le projet
126
127. +
Meilleures pratiques agile
n Tester tous les participants en 1 seule journée
n S’assurer que tous les membres de l’équipe y
assistent fréquemment (enregistrer / diffuser)
n Limiter les séries de tests à 3 participants à la fois
n Tester peu importe ce qui est disponible à
fréquence régulière
n Créer et maintenir une liste de participants aux
tests afin de simplifier le recrutement
127
128. +
Élaboration des scénarios
n Un bon scénario…
n … a une ligne narrative réaliste
n … est clair et sans interprétation
n … n’utilise pas les termes de l’application
n … est réalisable (réalisation claire)
n … ne donne pas d’indices sur comment effectuer la tâche
n … permet de tester des sous-tâches
n Exemple scénario de tests réussi:
n “Jeanne Bouchard utilise Hotmail. Elle habite à Québec.
Envoyez-lui un courriel.”
128
129. +
Exercice
n Dresser la liste des fonctionnalités qui
feront partie de notre première
itération.
n Délimiter les interfaces qui devront être
créées pour l’itération.
n Rédiger deux scénarios (un scénario
facile et un plus difficile) en fonction
des tâches principales à effectuer.
n Valider que les scénarios soient bel et
bien réalisables.
Créer les scénarios de tests
129
131. +
Quelques questions
n Quel niveau de détails du prototype est pertinent
(haute ou basse fidélité)?
n Est-il plus important que le prototype soit rapide à
mettre en place ou que le code soit réutilisable?
n Est-ce que le prototype fait partie des livrables ou
est un projet à part?
n Est-ce que le code du prototype va être réutilisé?
131
132. +
Plusieurs alternatives
n Prototype papier
n Wireframes (Axure, Balsamiq, etc.)
n Prototypes interactifs (Axure, Proto.io, etc.)
n Html
n Bootstrap
n Etc.
132
135. +
Le prototypage s’applique partout
“Rent a warehouse and build a
prototype of a store… go build
20 of them, then discover it
didn't work…” – Steve Jobs,
CEO d’Apple
“In 2009, when retail sales
declined around 2%,Apple’s
retail sales rose roughly 7%.”
135
http://money.cnn.com/magazines/fortune/fortune_archive/2007/03/19/8402321/
136. +
Le prototypage s’applique partout
Historically,you can look at the
Pixar film-making process as one
of building a prototype version of
each film (known as story reels )
and then moving on to building
the fully realized one.
We d much rather fail with a
bunch of sketches that we did
(relatively) quickly and cheaply,
than once we ve modeled,
rigged,shaded,animated,and lit
the film. Fail fast, that s the
mantra.
136
http://www.cooper.com/journal/agile2008/
137. +
Exercice
n Créer les interfaces nécessaires afin
d’effectuer les tests d’utilisabilité à
l’aide des fonctionnalités de la
première itération, du design
préliminaire et des scénarios.
n Utiliser les papiers, crayons et notes
post it afin de démontrer l’interactivité.
n Au besoin, s’inspirer des exemples sur
la page suivante.
Créer un prototype papier
137
139. +
Exercice
n À l’aide des scénarios rédigés et du
prototype papier, effectuer une série
de tests d’utilisabilité.
n Un des membres de l’équipe sera
modérateur tandis qu’une autre
personne prendra des notes.
n Travailler avec des utilisateurs d’une
autre équipe afin de faire les tests
d’utilisabilité.
n Selon le temps disponible, faire d’une à
deux séances de tests.Effectuer les tests d’utilisabilité
139
140. +
Comment bien modérer un test
n Un utilisateur à la fois
n Un ou plusieurs observateurs – discrets
n Souligner que les utilisateurs ne sont pas testés
n Mettre à l’aise, rassurer
n Poser des questions ouvertes
n Ne pas aider les utilisateurs
n Surveiller son approche et langage corporel
140
142. +
Exercice
n En équipe, dresser la liste des
apprentissages suite à la première
série de tests d’utilisabilité.
n Évaluer l’impact des changements
communiqués par le chef de produit
sur les fonctionnalités livrées lors de la
première itération.
n Établir un plan pour la deuxième
itération.
Évaluer l’impact des changements
142
144. +
Exercice
n Reprendre le prototype papier créé
lors de la première itération et le
mettre à jour en fonction des résultats
des tests d’utilisabilité et des
changements du chef de produit.
n Comment approchez-vous la mise à
jour?
Mettre à jour notre prototype papier
144
145. +
En résumé - Inception
145
Inception Itération zéro
§ Équipe multidisciplinaire
§ Permet de:
§ Déterminer l’étendue du projet
§ Comprendre les usagers
§ Analyser les processus
§ Partager les responsabilités
§ Créer l’équipe et un momentum
de projet
§ Évaluer à haut niveau la solution
technique
Cyc
146. +
§ En « paires » ou sous-groupes
§ Pour:
§ Créer l’architecture de base
§ Créer les processus de tests
automatisés
§ Prioriser les fonctionnalités
§ Créer des processus de gestion de
projet
§ Analyser les tâches des utilisateurs
§ Créer des personas
En résumé – Itération zéro
146
Itération zéro Cycle 1 Cycle 2
147. +
En résumé – Itérations suivantes
147
n zéro Cycle 1 Cycle 2 Cycle 3
§ Responsabilités de l’ergonome:
§ Valider l’itération précédente avec les
clients
§ Collaborer avec l’équipe de
développement
§ Recruter des participants aux tests
§ Valider les prototypes avec de vrais
utilisateurs
§ Effectuer la recherche utilisateur et la
conception pour les itérations futures
154. +
Le Lean UX
Inspiré par les théories du Lean Startup et du
développement agile, le Lean UX permet d’en
arriver à la vraie nature d'un produit plus
rapidement, de manière collaborative et
multidisciplinaire en mettant moins d’emphase sur
les livrables et en visant la création d’une
compréhension commune de la réelle expérience
utilisateur étant conçue.
154
http://www.youtube.com/watch?v=sDv2PXSz-kA
155. +
Le Lean UX
155
- Joshua Seiden, Co-Auteur du livre Lean UX
Don’t design a product, design an
experiment.
156. +
Le Lean UX
n Priorise l’apprentissage et non le développement
de nouvelles fonctionnalités
n Transforme les requis en hypothèses
n Crée des expérimentations afin de valider les
hypothèses
156
157. +
Comment faire du Lean UX?
n Identifier les plus grands risques et les plus
grandes opportunités
n Commencer par valider les plus grands risques
n Transformer chaque fonctionnalité en une
hypothèse qui peut être rapidement validée.
157
158. +
Exercice
n Reprendre la liste des fonctionnalités
de notre première itération de projets
et la reprioriser en fonction du risque.
n Pour chaque fonctionnalité risquée,
créer une hypothèse de validation
selon le format fourni sur la page
suivante.
n Comment pourrions-nous valider cette
hypothèse?
Repenser notre projet en « Lean UX »
158
159. +
Les hypothèses Lean UX
n Nous croyons que [développer cette
fonctionnalité] [pour ce groupe d’utilisateurs]
accomplira [ce résultat].
n Nous saurons si cette fonctionnalité est une
réussite lorsque nous obtiendrons [cette
démonstration du résultat].
159
160. +
Créer un « MVP »
n Acronyme pour MinimumViable Product ou produit
minimum viable
n Le plus simple produit qui peut être mis en place afin de
tester une hypothèse
160
http://www.slideshare.net/jgothelf/beyond-staggered-sprints-integrating-user-experience-and-agile
162. +
La livraison continue
La livraison continue (« Continuous Delivery ») est
une discipline de développement logiciel dans
laquelle vous construisez un logiciel de telle
manière qu’il puisse être déployé dans
l’environnement de production à tout moment.
L'objectif des pratiques et des principes de livraison
continue est d'encourager "une plus grande
collaboration entre tous les acteurs impliqués dans
la livraison du logiciel, ceci afin de livrer un logiciel
à valeur ajoutée plus rapidement et de façon plus
fiable".
162
164. +
Pourquoi la livraison continue?
n Pour réduire les risques
n Pour effectuer les changements « just in time »
n Pour partager les responsabilités de la qualité du
produit
n Pour améliorer le travail d’équipe et la
collaboration
164
165. +
IMVU
n Outil de messagerie en 3D
n + de 25 millions
d’utilisateurs
n + de 3 millions de revenus
par mois
n + de 30 mises à jour par
jour
165
166. +
Wealthfront
n Gestion de portfolio et
d’investissements
n Environnement contrôlé
n + de 200 millions de dollars
en gestion
n + de 2 millions de
transactions par jour
n + de 30 mises à jour par jour
166
http://www.slideshare.net/startuplessonslearned/pascallouis-perez-wealthfront-sllconf-continuous-deployment
167. +
La boucle OODA
n Théorie militaire créée par
le pilote de chasse John
Boyd
n Connu sous le nom de « 40
second Boyd »
n Il crée la boucle OODA en
1986. Grande influence sur
la stratégie militaire
n Il démontre que la vitesse
et l’agilité mènent à la
victoire
167
http://fr.wikipedia.org/wiki/Boucle_OODA
168. +
D’autres approches
n Travailler en « paires »
designer-développeur
n Concevoir à l’aide de «
components » de type
Bootstrap
n Concevoir le produit
directement dans Chrome
n …
168
169. +
Et si vous n’avez pas
d’ergonome dans votre équipe?
169
170. +
Par où débuter?
1. Organiser des tests utilisateurs avec 3 utilisateurs
tous les 1 ou 2 itérations
2. Faire participer l’équipe de développement aux
tests utilisateurs
3. Assigner les tâches de l’ergonome à un membre
de l’équipe. Socialiser cet intervenant
4. Créer (ou faire créer) des personas afin
d’humaniser et garder en tête les utilisateurs
finaux
170
171. +
Quelques alternatives
171
Alternative Bénéfices Inconvénients
Former
l’équipe
• Partage des
responsabilités
• Niveau de base
• Expertise plus limitée
• Incohérences
possibles
Assigner les
tâches
• Vision unifiée
• Participation active
• Expertise plus limitée
• Disponibilités limitées
Embaucher • Bonne expertise
• Participation active
• Équipe plus large
• Plus grands coûts
Contracter • Grande expertise
• Contrôle des coûts
• Moins de collaboration
• Plus grands coûts
172. +
*Important
Il est préférable de tester un peu que de ne pas
tester du tout.
Il est préférable de tirer certains bénéfices de
l’ergonomie que de ne rien obtenir.
172
181. +
Retour sur la journée
181
Qu’allez-vous retenir de la formation? Qu’allez-
vous pouvoir utiliser?
182. +
Bibliographie
n Don't Make Me Think! A Common Sense
Approach to Web Usability. Steve Krug, 2005
n Agile Experience Design. Marc Mcneill et
Lindsay Ratcliffe, 2011
n UX for Lean Startups: Faster, Smarter User
Experience Research and Design. Laura
Klein, 2013
n Gamestorming: A Playbook for Innovators,
Rulebreakers, and Changemakers. Dave
Gray, 2010
182
183. +
Mots clés
n Expérience utilisateur agile
n Livraison continue
n Agile Experience Design
n Agile UX
n Lean UX
n Continuous design
n Continuous delivery
183
184. +
Webographie
n UxPA Québec
n http://www.uxpaquebec.org
n The architecture of everything (Jason Furnell)
n http://jasonfurnell.wordpress.com/author/jasonfurnell/
n Agile Product Design (Jeff Patton)
n http://www.agileproductdesign.com/blog/
n Dancing Mango (Marc Mcneill)
n http://www.dancingmango.com/blog/
n Lean UX (Jeff Gothelf)
n http://www.jeffgothelf.com/blog/
184
185. +
Questions et discussion
185
Étienne Garbugli
etienne@etiennegarbugli.com
Twitter: @egarbugli
LinkedIn:
http://ca.linkedin.com/in/egarbugli
Blogue:
http://www.etiennegarbugli.com
Merci pour votre participation!