Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

L’ergonomie et l’expérience utilisateur en contexte agile (Agile UX Masterclass)

131 visualizaciones

Publicado el

Slides for a course I built for the Computer Research Institute of Montréal, Canada. UX design and testing in an agile context.

Publicado en: Diseño
  • Wow ! Awesome ! It is really a great tour of all what a UX Designer or Usability Expert, or Visual Designer or Product owner... should know but they don't because there is no training on the subject... Wanna start a training school (or a think thank or or book or whatever... count me in, I'll be here to help!
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Sé el primero en recomendar esto

L’ergonomie et l’expérience utilisateur en contexte agile (Agile UX Masterclass)

  1. + L’ergonomie et l’expérience utilisateur en contexte agile Étienne Garbugli
  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
  6. +Introduction et mise à niveau sur les principes du développement agile 6
  7. + Agile 7
  8. + Agile 8
  9. + Agile 9 2 à 4 semaines
  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
  16. + La situation actuelle Vision affaires Vision usagers Vision technique 16 Analyste d’affaires Client Développeur Testeur Chef de produit?
  17. + Le rôle du chef de produit 17
  18. + Agile 18 2 à 4 semaines
  19. + Agile 19 2 à 4 semaines
  20. + Utilisation des fonctionnalités déployées dans les applications 20 0% 10% 20% 30% 40% 50% Toujours Souvent Quelques fois Rarement Jamais Source:The Standish Group
  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/
  26. + Design de produits vs Design UX 26
  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
  29. + Par contre… 29 n Méthodologie de développement n ISO 13407, une méthodologie agile
  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
  31. + Agile et ergonomie 31
  32. + Agile et ergonomie 32
  33. + Agile et ergonomie 33
  34. + Agile et ergonomie 34
  35. +La planification de projets agile 35
  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
  39. + Qu’avez-vous pensé? 39 On y revient plus tard.
  40. +Les « inceptions » et l’itération zéro 40
  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.
  44. + Pourquoi une inception? 44
  45. + Pourquoi une inception? 45
  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.
  48. + CRIM Formation – ERG355 V1.2 © Étienne Garbugli 48 http://www.youtube.com/watch?v=Obf1vFaCBSM
  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
  50. CRIM Formation – ERG355 V1.2 © Étienne Garbugli “The wall is the new desk.” - Dave Gray, Auteur du livre Gamestorming
  51. + Planification de l’inception 51
  52. 52 http://jasonfurnell.wordpress.com/2010/12/02/business-model-canvas-facilitator-cards/
  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
  57. + Qu’est-ce qu’un persona? 57
  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.
  59. + Les personas CRIM Formation – ERG355 V1.2 © Étienne Garbugli 59
  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
  65. + Les personas 65 n Psychographiques n Styles de vie n Croyances n Valeurs n Personnalités n Comportements n Intérêts n Opinions
  66. + Le parcours client 66
  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
  70. 70 Le Customer journey Qui suis-je? Déclencheur
  71. 71 Le Customer journey Qui suis-je? Déclencheur Étapes
  72. 72 Le Customer journey Qui suis-je? Déclencheur Étapes Découverte Recherche Comparaison Achat
  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
  78. 78
  79. CRIM Formation – ERG355 V1.2 © Étienne Garbugli 79 Le Customer journey
  80. + La carte d’empathie (alternative) 80
  81. + Le design collaboratif 81
  82. CRIM Formation – ERG355 V1.2 © Étienne Garbugli 82 “Design is a team sport.” - Jason Furnell, Designer sénior chez ThoughtWorks
  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.
  87. CRIM Formation – ERG355 V1.2 © Étienne Garbugli 87
  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
  90. + Exercice 90
  91. +La priorisation des fonctionnalités
  92. + Quelques alternatives 92 Vision affaires Vision usagers Priorisation client Priorisation forcée Impact vs faisabilité Analyse Kano
  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
  95. + Impact vs Faisabilité 95 https://www.adaptivepath.com/ideas/e000018/
  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
  101. + Comment faire une analyse Kano? 101
  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
  106. + Première Itération 106
  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
  109. + Penser à l’objectif de l’itération 109
  110. + L’ergonome travaille en parallèle 110
  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)
  113. + Le tests d’utilisabilité 113
  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
  115. CRIM Formation – ERG355 V1.2 © Étienne Garbugli 115
  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
  123. + Nombre de participants 123
  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
  130. + Le prototypage 130
  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
  133. + Rapide vs Réutilisable 133 Hi-Fi Réutilisabilité Low-Fi <HTML> Bootstrap
  134. + *Important 134 n Les prototypes ne remplacent pas les spécifications fonctionnelles…
  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
  138. CRIM Formation – ERG355 V1.2 © Étienne Garbugli
  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
  141. + Rétrospective Qu’avez-vous appris?
  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
  143. + Deuxième Itération 143
  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
  148. + Quel impact? 148 Comment se compare l’agile UX au projet que vous avez effectué hier matin?
  149. + Et dans votre entreprise? 149 Comment se compare l’agile UX à vos processus actuels?
  150. + Étude de cas - Nordstrom n Créer une application iPad en 5 jours: n http://www.youtube.com/wa tch?v=szr0ezLyQHY 150
  151. + Les nouvelles tendances 151
  152. + L’évolution de l’agile? 152
  153. + Le Lean Startup 153
  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
  161. + Tester en continu (A/B, utilisateurs, etc.) 161 25% 25% 25% 25%
  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
  163. + La livraison continue 163
  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
  173. + Les nouveaux designers 173 Expertise en design Expertise en modération
  174. + Les nouveaux designers 174 Expertise en design Expertise en modération Le designer junior
  175. + Les nouveaux designers 175 Expertise en design Le designer diva Expertise en modération
  176. + Les nouveaux designers 176 Expertise en design Expertise en modération Efficacité limitée
  177. + Les nouveaux designers 177 Expertise en design Le modérateur générique Expertise en modération
  178. + Les nouveaux designers 178 Expertise en design Le designer x 5 Expertise en modération
  179. + Des questions? 179
  180. + Des questions? 180 A-t-on répondu à toutes vos questions?
  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!

×