Le test utilisateur Exemple de test utilisateur (humoristique) : http://www.youtube.com/watch?v=3Qg80qTfzgU Test utilisateur de smartphone : http://www.youtube.com/watch?v=LnAS_MKl96A Test de site web à distance : http://www.youtube.com/watch?v=k2lcfSVSR40

Quelles sont les différentes étapes du test ? D’après la vidéo du test de fruit, quelles sont les étapes du test utilisateur ? Important de demander si l’util a compris la tâche. Que faire si l’util bloque ? Ne pas laisser ramer… Faire verbaliser l’util : questions ouvertes, reformulation. Donner exemple en verbalisant soi-même. Si l’util oublie un élément de la consigne, lui rappeler. Prise de notes : plutôt un enregistreur, noter seulement les moments importants

Test de scénarios (usability testing) Construction de scénarios authentiques d’après analyse de l’activité et analyse du système Pre-test Recrutement des utilisateurs Passation du test utilisateurs Expliquer Faire passer les tâches - enregistrer Questionnaires et entretien de debriefing Analyse qualitative et quantitative Diagnostic et proposition de remédiations. On verra ça concrètement la prochaine fois avec une activité sur ordinateur en 4183

Test de scénarios : petit jeu de rôle Exercice : deux volontaires dont un ne connaît pas le site Scénario Observateurs : la moitié observent l’entretien : ce qui se passe, comment se déroule le test l’autre moitié notent les problèmes rencontrés par l’utilisateur Après le test, chacun rapporte son observation (y compris les participants au jeu de rôle) Voir l’animation humoristique sur Chamilo (Documents P4)

Passation - Recommandations Consignes par écrit – Tâches lues par l’interviewer puis données à l’util L’interviewer doit-il intervenir pour motiver l’util ? Oui pour soutenir, pour dire qu’on peut trouver l’info. Eviter de dire quoi faire. Eventuellement rediriger vers page d’accueil. Quand s’arrêter de poursuivre la tâche ? Quand l’utilisateur s’exaspère !

Problèmes observés Que s’est-il passé ? Pourquoi était-ce un problème pour l’utilisateur

2. Recruter les utilisateurs Représentatifs du public-cible (si possible) Prendre les vrais utilisateurs, « pas leurs représentants » Population homogène pour chaque échantillon de public cible Combien de sujets Dépend de la diversité du public cible : 5 par type de cibles est acceptable Représentatifs du public-cible (si possible) Prendre les vrais utilisateurs, « pas leurs représentants » Problèmes de recrutement Problèmes de confidentialité Varier les autres variables: Expérience dans le domaine concerné Expérience avec l ’informatique, avec Internet, … Age, sexe, culture, position géographique Fonction dans l ’entreprise Combien de sujets? Dépend de l ’homogénéité de la population 3-5: détection des gros problèmes 5-10: conclusions plus défendables >10: validation Contacté par insider qui explique les enjeux Qui sont usagers réguliers d’internet, mais ne connaissent pas le site en question

3. Tester 3.1. Expliquer Je vous vous présenter différentes tâches que vous devrez réaliser sur un site web. Ce test va durer … minutes. Le but n’est pas de vous évaluer mais de savoir si le site est satisfaisant. Il n’y a pas de bonne ou mauvaise réponse. Je vais vous demander de penser à voix haute pendant que vous réalisez ces tâches. Dites-moi lorsque vous pensez avoir terminé la tâche. Puis-je vous enregistrer... -> enregistrer de préférence avec un enregistreur d’écran : ScreenFlick pour Mac (http://www.araelium.com/screenflick) Camstudio pour Windows (http://camstudio.org)

3. Tester 3.2. Faire passer Voici le site. A quoi vous fait-il penser de premier abord ? Voici la première tâche. Lisez-là à voix haute (ou on la lit). Est-ce que vous avez compris ce qui vous est demandé ? PENSEZ TOUT HAUT PENSEZ TOUT HAUT… hmm… qu ’est-ce que vous êtes en train de faire ? Voici la deuxième tâche. ...

3. Tester 3.3. Ecouter Règles classiques de l ’entretien : Ecouter > Parler Poser des questions sur son activité Poser des questions neutres Fournir un feedback neutre Respecter les silences, laisser un petit moment après chaque tâche Rebondir sur les points intéressants, ne pas suivre rigidement un canevas Ne pas se laisser placer dans un rôle d’expert par l’utilisateur Arrêter le test en cas d’échec répétitif Prévoir un entretien post-test : Échelles de satisfaction (voir demain) Entretien ouvert : « qu’avez-vous pensé du site lorsque vous effectuiez les tâches demandées ? » Règles de l ’entretien : Ecouter > Parler Poser des questions précises Poser des questions neutres Fournir un feedback neutre Respecter les silences, laisser une chance de répondre aux questions non posées, laisser un petit moment après chaque tâche Rebondir sur les points intéressants, ne pas suivre rigidement un canevas Considérer l ’utilisateur comme un expert dans son métier, pas comme un cobaye, l ’utilisateur doit le sentir. Ne pas se laisser placer dans un rôle d’expert par l’utilisateur, càd ne pas suggérer de solutions. Facile à dire mais pas facile à faire dans la situation. S ’en référer au point précédent… Prévoir un entretien post-test : on obtient souvent des opinions, et des rationalisations de comportements, mais cela vous renseigne sur l ’attitude des utilisateurs, et également cela permet aux sujets de verbaliser leur éventuelle insatisfaction. Arrêter le test en cas d’échec répétitif. Normalement, le scénario doit prévoir d ’abord des tâches faciles et peu coûteuses en temps, qui font aussi un bon test pour savoir si l ’on doit poursuivre. En cas d ’échec, avant de virer le logiciel, s ’assurer qu ’un utilisateur de même profil aura les mêmes difficultés.

1. création de scénario - Exercice Le Scénario pour le test utilisateur est une série de tâches à réaliser sur le site web choisi, inspirées de l’analyse de l’activité, qui a pour objectif de mettre les participants dans une situation authentique d'utilisation du site web. Vous devez faire un test utilisateurs pour évaluer un site de cuisine comme Le Marmiton. Le public cible est large et ne concerne pas forcément des personnes férues de cuisine. Imaginez un scénario pour le test utilisateur qui comprenne au moins deux tâches. Le scénario doit réaliser une « mise en situation » authentique qui donne du sens aux différentes tâches. Postez votre scénario (formulé tel qu’il le serait pour l’utilisateur) dans openclass avec le #scenario

Qu’est-ce qu’un bon scénario ? S’appuyer sur les critères formulés par les utilisateurs (analyse de l’activité) pour contraindre la tâche. Prévoir une mise en situation détaillée et authentique, mais pas trop « romancée » Formulation ouverte des tâches, laissant à l’utilisateur le sentiment d’être en contrôle de la situation. Eviter les instructions directes.

3. Tester 3.2. Phase post-test Faire passer un des trois questionnaires conseillés Voir Wikispaces – Questionnaire Wammi

Pratique du test utilisateur Par deux, un-e utilisateur-trice, un-e expert-e, vous changerez de rôle pour la deuxième tâche Scénario : voir feuille distribuée L’expert prend note des problèmes rencontrés par l’utilisateur pendant la passation puis rapporte dans le forum « Activité P4 > Problèmes constatés ».

Description des problèmes utilisateurs Voir les problèmes que vous avez relevé dans Forum « Activité du 21 février » > Problèmes constatés » A faire (voir Modèle de rapport dans Dokeos) : Description concise mais complète : que s'est-il passé ? quel était le problème du point de vue de l'utilisateur ? du point de vue du système ? Mettre une copie d'écran. Nature du problème : contenu, de navigation, d'organisation, d'interaction ? Statistiques : combien d'utilisateurs l'ont rencontré ? Gravité du problème : critique - sérieux – gênant - faible Diagnostic : s’appuie sur des grilles heuristiques

Les étapes du test utilisateur Description et diagnostic des problèmes Grilles heuristiques

4. Résultats Voir Modèle dans documents Dokeos > P4 Projet > Modèle de rapport Critères d’évaluation Utilisation : efficacité, efficience, apprentissage, satisfaction Utilité Usages Synthèse : description générale et points positifs Diagnostic des problèmes Description, Citations, copie d’écran – screen cast, statistiques Gravité : degré d’entrave à l’atteinte de la tâche Catégorisation selon grille de critères Propositions de solutions Argumentées Implémentées ou non dans le prototype 2

Pourquoi utiliser une grille ? Objectif rhétorique : pour synthétiser les problèmes rencontrés Objectif diagnostique : pour faciliter le diagnostic des problèmes rencontrés et leur résolution La validité de ces critères est basée sur - la méthode de construction - des validation expérimentale de leur utilisabilité : utilisateurs novices vs. expérimentés, utilisation de cette grille vs. d ’autres ou rien du tout... Deux cas de figure : pour systématiser une inspection experte pour synthétiser les résultats d’un test utilisateurs

Trois exemples de grilles ou « check-lists » Les 10 recommandations de Nielsen La norme ISO 9241 Les critères de Bastien & Scapin

Les 10 recommandations de Nielsen Document Dokeos : Principes Nielsen Inspection experte Heuristiques basées sur l ’optimisation des fameux 4 critères : apprentissage efficience gestion des erreurs satisfaction

Les normes ISO Document Dokeos : Checklist ISO Normes définissant la qualité d’un produit informatisé Principes de dialogue Utilisabilité des systèmes Présentation visuelle Guidage de l’utilisateur Styles de dialogue : menus, manipulation directe, langage de commande ou formulaires Quality control

Les critères de Bastien & Scapin Stratégie de construction des critères : recueil d’un grand nombre de données expérimentales (800) et de recommandations individuelles (guidelines) traduction de ces données en règles distinction de classes de règles Test expérimental de l’efficacité de la grille pour experts et non experts La validité de ces critères est basée sur la méthode de construction Et validé par l’experimentation de - des validation expérimentale de leur utilisabilité : utilisateurs novices vs. expérimentés, utilisation de cette grille vs. d ’autres ou rien du tout... Références Bastien, J. M. C., & Scapin, D. L. (1995). Evaluating a user interface with ergonomic criteria. International Journal of Human-Computer Interaction, 7, 105-121. Site de l’auteur : http://www.ergoweb.ca/criteres.html Documents Dokeos : Liste des critères de Bastien et Scapin plus présentation illustrée avec les sous-critères.

1. Guidage La personne qui utilise sait-elle toujours ce qu’elle doit et peut faire ? L’information est-elle clairement organisée et présentée ?

2. Charge de travail L’interface n’est-elle pas trop chargée au niveau des éléments à lire ou des actions à faire ? Source: http://www.internetactu.net/2008/04/24/pour-une-ecologie-informationnelle/

3. Contrôle explicite Les actions entreprises par le système correspondent-elles à ce qu’attend l’utilisateur-trice ? A-t-on le contrôle sur les actions en cours ? Concerne aussi bien : le traitement par le système d’actions explicites de l’utilisateur, le contrôle qu’a l’utilisateur sur le traitement de ses actions par le système C’est à dire le fait de savoir que le système « entend » les actions voulues par l’utilisateur, et aussi que l’utilisateur peut contrôler ce que fait le système.

4. Adaptabilité Peut-on personnaliser l’interface, définir des préférences ? Y a -til une prise en compte de l’expérience (sur le site) de l’utilisateur ?

5. Gestion des erreurs Les erreurs sont : des entrées de données incorrectes, des entrées dans des formats inadéquats, des entrées de commandes avec une syntaxe incorrecte, etc. Peut-on facilement éviter les erreurs et les corriger lorsqu’elles surviennent ?

6. Homogénéité / Cohérence Les éléments de l’interface sont-ils conservés pour des contextes identiques et différenciés pour des contextes différents ? codes, dénominations, formats, procédures, etc. Justification : Les procédures, labels, commandes, etc., sont d’autant mieux reconnus, localisés et utilisés, que leur format, localisation, ou syntaxe sont stables d’un écran à l’autre, d’une session à l’autre. Dans ces conditions le système est davantage prévisible et les apprentissages plus généralisables ; les erreurs sont réduites. Par exemple, les rubriques dans un site Web doivent toujours être au m^me endroit. Les items de menu doivent être affichées dans le même ordre.

7. Signifiance des codes et dénominations Attention à l’usage des icônes : Ex l’étoile était l’icône pour ouvrir le menu les animation dans Powerpoint. Les codes et dénominations utilisées sont-ils signifiants, intuitifs pour les utilisateurs-trice ?

8. Compatibilité Le contenu est-il adapté aux caractéristiques du public cible et à son activité ? Par exemple, accord entre étapes d ’une procédure d ’une tâche sont identiques a ce qu ’exige la situation ou aux habitudes existantes. Ex : sauvegarde d’un fichier vide.

Exercice A partir des problèmes que vous avez relevés dans le forum, préparer une description comme dans le modèle de la page précédente pour les trois critères qui vous ont été distribués. Si aucun des problèmes mentionnés ne correspond au critère, cherchez si un tel problème apparaît sur le site.

4. Résultats – Modèle de structure (sous forme de tableau ici mais ce n’est pas nécessaire) + copie d’écran, citations Utilisez un outil de capture d’écran tel que Jing.

Questionnaire et entretien post-hoc Voir présentation Questionnaires… dans Documents Dokeos P4

Un ensemble de méthodes