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
3. 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)
4. 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
6. 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
7. “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.
8. “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
11. 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)
12. 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
13. problem definition
recruitment definition of tasks
(+consentment form)
test phase
(w/o think aloud)
analysis
reporting (problems
and solution)
14. 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?
15. 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...)
17. 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
18. 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
• ...
19. 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)
20. 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...
21. 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
22. 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
23. 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)
24. 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).
25. 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)
26. 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
27. 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
29. 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
30. 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
32. ➡ 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.