Field research and interaction design: course #6

Course #6: evaluation

nicolas nova | liftlabHead, Geneva | April, 29th 2010

• 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)

Evaluate what?

• 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

Quand évaluer?

evaluation

expert evaluation (analytical approach)

testing (empirical approach)

informal (ethnographic)

formal (usability testing)

Methodologies

• 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

Expert evaluation

• 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.

“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

“Inspection cognitive”

evaluation





Methodologies

• 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)

Usability testing

• 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

Qualitatif-quantitatif

recruitment(+consentment form)

definition of tasks

test phase(w/o think aloud)

analysis

reporting (problems and solution)

problem definition

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?


• 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...)

(Jakob Nielsen, http://www.useit.com/alertbox/20000319.html)


5-12

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


• 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

• ...


• 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)

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...

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

during the test

• Faire en sorte que le participant soit à l’aise

• Minimiser les distractions

• Se retenir de guider l’utilisateur qui rencontre des problèmes

• Faire attention aux signaux témoignant des problèmes et erreurs

• Se rappeler et noter les actions et les problèmes

• 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)

analysis

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).

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)

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

• Ne pas savoir pourquoi vous testez (les tests vont plus informez ce qui ne marche pas que ce qui marche)

• Ne pas impliquer les parties prenantes (programmeurs, marketing, designers)

• Recruter des participants en dehors de la cible

• Concevoir des tâches non appropriées

• Mal faciliter la passation du test

• Oublier de définir comment vous allez “vendre” les résultats

• En rester là avec un seul test (itérez avec solutions)

7 erreurs

approches

evaluation





• 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

Approche “terrain”

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

Project discussion

Project overview

➡ 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.

thanks

[email protected]

mailto:[email protected]

mailto:[email protected]