Course #6: evaluation
nicolas nova | liftlab
Head, Geneva | April, 29th 2010
Evaluate what?

•   Pour les concepteurs:

    •   Fiabilité du produit/service

    •   Utilisabilité: qualité de l’inter...
Quand évaluer?



•   Au cours de la conception: prototypes, maquettes... (suivant
    le temps disponible! Evaluation de ...
Methodologies


                          evaluation




    expert evaluation                        testing
  (analytica...
Expert evaluation


•   Evaluation a priori par un ou plusieurs experts
    (interaction design, ergonomie)

•   Utilisati...
“Inspection cognitive”


•   But: évaluer le produit/service en se mettant à la place de
    l’utilisateur

•   Moyen: spé...
“Inspection cognitive”



•   Exemple: l’utilisateur se donne un objectif à réaliser à l ’aide
    du système (ex. : vérif...
Methodologies


                          evaluation




    expert evaluation                        testing
  (analytica...
Usability testing

•   But: évaluer l’utilisabilité du produit/service par les utilisateurs
    pour l’améliorer ou le mod...
Qualitatif-quantitatif

•   Quantitatif: durée pour accomplir une tâche, temps
    d’apprentissage, nombre d’erreurs, rapp...
problem definition


  recruitment                 definition of tasks
(+consentment form)



                      test p...
problem definition




   • Des problèmes généraux:
    • Vérifier si le site web de vente par
         correspondance est...
recruitment
(+consentment form)



   •   Définir les utilisateurs typiques du produit/service
       (market segment, cib...
recruitment
(+consentment form)




                                               5-12




      (Jakob Nielsen, http://w...
task definition: script/
       scenario

      •   Choisir les tâches prototypiques concernant le
          produit/servi...
task definition: script/
       scenario




      •   Usability test orienté produit (site de e-commerce):

          •  ...
task definition: script/
       scenario


         •   Ecrire le script du test sur un document qui sera
             don...
test setting




•   Contrôlé ou en contexte?

•   Dispositif à tester (par exemple ordinateur connecté à Internet
    ave...
test phase




•   Introduction au test (même si ce se redit sur le
    document de script donné à l’utilisateur), s’assur...
during the test




   • Faire en sorte que le   • Faire attention aux
      participant soit à       signaux témoignant
 ...
analysis




• Qualitatif: mode descriptif
 • est-ce que la tâche a été réalisée?
 • lister les incidents critiques, et le...
analysis



• Quantitatif: faire des mesures
  •    durée pour accomplir une tâche,

  •    durée pour accomplir une tâche...
analysis




• Quantitatif: statistiques descriptives pour chaque
  variable décrite avant.

    • moyenne
    • minimum/m...
reporting


•   Plan d’un rapport de usability:

•   Résumé/Abstract/Exec summary: quel produit,
    quels problèmes, quel...
7 erreurs
• Ne pas savoir           • Concevoir des tâches
  pourquoi vous testez      non appropriées
  (les tests vont p...
approches

                        evaluation




  expert evaluation                        testing
(analytical approach)...
Approche “terrain”



  •   Objectif: obtenir des informations sur ce que les
      utilisateurs pensent du système, en at...
triangulation
• combinaison de méthodes pour trouver
  des signaux convergents de problèmes
• Par exemple:
 • un usability...
Project discussion
➡ To be completed for June 18th, 2010
➡ A short report with:
         • Executive summary of the project (one page / 20 li...
thanks
nicolas@liftlab.com
Field research and interaction design: course #6
Field research and interaction design: course #6
Prochain SlideShare
Chargement dans…5
×

Field research and interaction design: course #6

1 807 vues

Publié le

Sixth and final deck of slides from the Field Research and Interaction Design, a Master course at the Geneva University of Art and Design, in the Media Design program taught in 2009-2010

Publié dans : Design
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 807
Sur SlideShare
0
Issues des intégrations
0
Intégrations
340
Actions
Partages
0
Téléchargements
19
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Field research and interaction design: course #6

  1. 1. Course #6: evaluation nicolas nova | liftlab Head, Geneva | April, 29th 2010
  2. 2. Evaluate what? • Pour les concepteurs: • Fiabilité du produit/service • Utilisabilité: qualité de l’interface, permettre à l’utilisateur d’utiliser efficacement le produit/service • Utilité: est-ce que le produit/service résouds les problèmes visés? correspond-t-il aux spécifications? • Usages: est-ce que le produit/service est utilisé comme prévu? • Pour l’utilisateur: • Utilisation du produit/service (qui est perçu comme un tout, pas réductible aux dimensions ci-dessus)
  3. 3. Quand évaluer? • Au cours de la conception: prototypes, maquettes... (suivant le temps disponible! Evaluation de l’utilisabilité et de l’utilité, approche itérative. • Après la réalisation: contrôle qualité • Après la diffusion: étude d’usages, enquêtes et études de satisfaction • Avant la conception de la nouvelle version: étude d’usages, incidents critiques
  4. 4. Methodologies evaluation expert evaluation testing (analytical approach) (empirical approach) informal formal (ethnographic) (usability testing)
  5. 5. Expert evaluation • Evaluation a priori par un ou plusieurs experts (interaction design, ergonomie) • Utilisation de grilles de critères ergonomiques (recommendations, heuristiques), inspection cognitives. • Avantage: rapide, facile à utiliser (pour autant qu’on en ait l’expérience) • Inconvénients: absence du contexte et de ses effets, un seul individu (ou plusieurs experts), l’expert connait l’ergonomie mais moins la tâche
  6. 6. “Inspection cognitive” • But: évaluer le produit/service en se mettant à la place de l’utilisateur • Moyen: spécifier des micro-tâches et des séquences d’actions que l’utilisateur pourrait avoir à faire (construire un scénario) • Procédure: passer au travers du scénario en imaginant ce que l’utilisateur pourrait faire et comprendre. Puis interprétation et listing des problèmes rencontrés.
  7. 7. “Inspection cognitive” • Exemple: l’utilisateur se donne un objectif à réaliser à l ’aide du système (ex. : vérifier l’orthographe d’un document) • L’utilisateur recherche dans l’interface les actions qu’il peut réaliser autour de cet objectif (items de menu, boutons, commandes clavier, etc.) • L’utilisateur choisit l’action la plus appropriée pour atteindre le but recherché • L’utilisateur réalise l’action et évalue le feed-back du système en fonction de l’objectif àatteindre
  8. 8. Methodologies evaluation expert evaluation testing (analytical approach) (empirical approach) informal formal (ethnographic) (usability testing)
  9. 9. Usability testing • But: évaluer l’utilisabilité du produit/service par les utilisateurs pour l’améliorer ou le modifier: • comprendre l’appréhension, les instructions • comprendre le feedback • découvrir les erreurs, les problèmes • vérifier la satisfaction • mais aussi vérifier que les problèmes ont été éradiqués • Basée sur un scénario correspondant à une liste de tâche à réaliser • !!! Les résultats ne sont pas censé être généralisables (ce n’est pas une expérience contrôllée mais une forme d’expérimentation appliquée)
  10. 10. Qualitatif-quantitatif • Quantitatif: durée pour accomplir une tâche, temps d’apprentissage, nombre d’erreurs, rappel d’items après une période sans utiliser, évaluation subjective (échelle likert). • mesures, quantification (en temps réel ou en ayant filmé) • Qualitatif: est-ce que la tâche a été réalisée? lister les incidents critiques, les erreurs (catégorisation), les obstacles à la réalisation de la tâche, citations par les participants • appréciations, catégorisations d’erreurs et de problèmes
  11. 11. problem definition recruitment definition of tasks (+consentment form) test phase (w/o think aloud) analysis reporting (problems and solution)
  12. 12. problem definition • Des problèmes généraux: • Vérifier si le site web de vente par correspondance est “ergonomique” • Est-ce que le système de visioconférence sur le Nokia N95 est facile à utiliser? • Des améliorations qui fonctionnent? (comparaisons) • Quelle est le meilleur contrôle pour un jeu d’aventure 3D pour enfant sur la Wii?
  13. 13. recruitment (+consentment form) • Définir les utilisateurs typiques du produit/service (market segment, cible...) • Y a-t-il des pré-requis techniques? (savoir utiliser Windows, un OS Nokia, savoir jouer a un jeu vidéo...) • Y a-t-il des pré-requis culturels? (pour un site web pour des individus diabétiques, tester avec des diabétiques) • Formulaire de consentement (décrire le but de l’expérience, les éléments de méthode surtout si l’on filme, rappeler à l’utilisateur que ce n’est pas lui qui est testé mais le produit...)
  14. 14. recruitment (+consentment form) 5-12 (Jakob Nielsen, http://www.useit.com/alertbox/20000319.html)
  15. 15. task definition: script/ scenario • Choisir les tâches prototypiques concernant le produit/service. • Discerner les tâche globales (trouver un site web avec Google) et les micro-tâches (utiliser la fonctionnalité X sur un site web) • Vous même mais aussi avec d’autres personnes (designers, programmeurs, marketing...) • Le nombre de tâche dépend du produit, du niveau de profondeur dans lequel vous voulez aller (test en détail ou superficiel) ainsi que des contraintes (temps, ressources) • Pas possible de tout tester, donc il faut hiérarchiser ou grouper • Définir un temps maximum si vous y êtes contraint
  16. 16. task definition: script/ scenario • Usability test orienté produit (site de e-commerce): • Trouver le site web de vente de nourriture par correspondance “leshop.com” • Créer votre profile • Commander 300g de tomates, 3l de lait, des courgettes et 500g de beurre • Modifier l’addresse de livraison dans votre profile • ...
  17. 17. task definition: script/ scenario • Ecrire le script du test sur un document qui sera donné à l’utilisateur • bienvenue + pourquoi on fait ce test + “votre aide...” • information sur l’utilisateur (nom, âge, sexe, expérience antérieur) • liste de tâches • “Think aloud”: Lui dire aussi ici si il/elle doit parler à haute voix pour décrire ce qu’il/elle fait. • Trouver des exemples sur le web (google “usability test”+script)
  18. 18. test setting • Contrôlé ou en contexte? • Dispositif à tester (par exemple ordinateur connecté à Internet avec souris...) • Dispositif de collecte de données dépendant de la méthodologie: • observateur présent et prenant des notes • caméra filmant + enregistement du son ou vitre sans tain (pratique pour avoir plusieurs observateurs) • Autre: rafraichissements, toilettes...
  19. 19. test phase • Introduction au test (même si ce se redit sur le document de script donné à l’utilisateur), s’assure que les consignes sont comprises • Redit si le test nécessite le “think aloud” • Présence ou non de l’ergonome dans la pièce
  20. 20. during the test • Faire en sorte que le • Faire attention aux participant soit à signaux témoignant l’aise des problèmes et erreurs • Minimiser les distractions • Se rappeler et noter les actions et les • Se retenir de guider problèmes l’utilisateur qui rencontre des problèmes
  21. 21. analysis • Qualitatif: mode descriptif • est-ce que la tâche a été réalisée? • lister les incidents critiques, et les erreurs, les obstacles à la réalisation de la tâche, • catégoriser, trouver des exemples de citations par les participants (si think aloud)
  22. 22. analysis • Quantitatif: faire des mesures • durée pour accomplir une tâche, • durée pour accomplir une tâche après un certain temps sans utiliser le produit (test en 2 ou 3 parties) • nombre et type d’erreurs par tâches (utiliser la catégorisation d’erreurs décrites dans l’analyse qualitative) • nombre d’erreurs par unité de temps • nombre d’utilisateurs faisant une erreur particulière • nombre de d’utilisateurs complétant une tâche avec succès • rappel d’items après une période sans utiliser, • évaluation subjective (likert).
  23. 23. analysis • Quantitatif: statistiques descriptives pour chaque variable décrite avant. • moyenne • minimum/maximum (eventuellement outliers) • ecart-type • par tâche ou par individus (définition de profiles d’erreurs)
  24. 24. reporting • Plan d’un rapport de usability: • Résumé/Abstract/Exec summary: quel produit, quels problèmes, quelle solutions • Introduction (produit/service, contexte, background) • Description de la méthodologie (~ matériel et méthodes): script de test, nombre de participants, pré-requis... • Résultats significatifs (quali+quanti), visuel (graphes), liste de problèmes/erreurs • Proposition de solutions, d’alternatives
  25. 25. 7 erreurs • Ne pas savoir • Concevoir des tâches pourquoi vous testez non appropriées (les tests vont plus informez ce qui ne marche pas que ce qui • Mal faciliter la passation du test marche) • Oublier de définir • Ne pas impliquer les comment vous allez parties prenantes “vendre” les résultats (programmeurs, marketing, designers) • En rester là avec un seul test (itérez avec • Recruter des solutions) participants en dehors de la cible
  26. 26. approches evaluation expert evaluation testing (analytical approach) (empirical approach) informal formal (ethnographic) (usability testing)
  27. 27. Approche “terrain” • Objectif: obtenir des informations sur ce que les utilisateurs pensent du système, en attendent, ou ce qu’ils en font réellement. • Porte sur l’usage et l’utilisation sur le terrain (e.g. prêter un GPS de voiture pendant 1 mois) • Proche de la démarche d’étude de conception • En général sur le “terrain” mais parfois en situation de laboratoire, se combine alors au usability test
  28. 28. triangulation • combinaison de méthodes pour trouver des signaux convergents de problèmes • Par exemple: • un usability testing qui montre des problèmes de nom de menus • un entretien post-tâche durant lequel les utilisateurs se plaignent des noms de menus qui sont imprécis
  29. 29. Project discussion
  30. 30. ➡ To be completed for June 18th, 2010 ➡ A short report with: • Executive summary of the project (one page / 20 lines) • Summary of your design question (10 lines) + motivation to deal with this problem (10 lines) • Table (one page) that describes the research question in detail: What do I need to know? Why do I need to know this? What kind of data will answer the question? Where can I find the data? Whom do I contact to access these data? • Methodology description (one page): describe what you did (interview, pictures, number of people observed, etc.) • Result analysis (6-10 pages): describe the main results of your field study (the most important situation you observed, patterns and problems you noticed, exceptions you remarked) with excerpts of interviews, pictures (photo you took) and element from your personal observation. • Design implications (3-4 pages): specification for a designed product, 3 personas, a use case of your product (narrative or storyboard). • Conclusion (one page): what you learned doing this, how you would continue such as a project, ideas for design, etc.
  31. 31. thanks nicolas@liftlab.com

×