IHM

1. IHM Cours 2 Découvrir les utilisateurs et leur activité M2-IFL/DU-TICE, UPMC Elisabeth.Delozanne@upmc.fr

2. Conception centrée utilisateurs (CCU) • Terme inventé par D. Norman en 1986 [10] • Norme ISO 13407 : 5 principes • analyse des besoins des utilisateurs, de leurs tâches et de leur contexte de travail • participation active de ces utilisateurs à la conception • répartition appropriée des fonctions entre les utilisateurs et la technologie • démarche itérative de conception • intervention d'une équipe de conception multi-disciplinaire

3. Pourquoi ? • Découvrir auprès des utilisateurs • comportements • contextes • types • motivations • états d’esprit • Identifier les points noirs • Susciter de nouvelles idées • plus simples, plus efficaces, plus amusantes, moins chères

4. Principes Fondateurs • Vous (concepteur) n’êtes pas l’utilisateur • Ne cherchez pas à conforter vos a priori • Cherchez des informations, même dérangeantes • Tous les utilisateurs sont différents • L’utilisateur moyen n’existe pas • Tous les utilisateurs se ressemblent • Appuyez vous sur des résultats de recherche • Obtenez des faits, pas seulement des opinions • Toujours un décalage entre • ce que les gens disent • ce qu’ils font • Des techniques simples et efficaces existent

5. Connais tes utilisateurs ! « Vos utilisateurs se ressemblent tous » (Landay 03) • humains en général • Ex : étude de la vision, de la perception des couleurs, des habiletés bimanuelles • Source d’informations : études scientifiques, normes, guides, recommandations • « Vos utilisateurs sont tous différents » • situations de travail réel, de la vie • Ex : publics spécifiques, problématiques métiers, contextes • Sources d’informations : techniques de recueil de données

6. Objectifs du cours 2 (et projet étape 1) • Maintenir dans la conception les points de vue utilisateur • Techniques pour ôter sa casquette de concepteur • Découvrir les utilisateurs • S’informer • Ergonomie concepts de base • Collecter et analyser des données • Techniques simples et efficaces • Produire des ressources pour la conception • Personas, Scénarios, et une description des tâches

7. Analyse de besoins • Il ne suffit pas de demander aux gens ce dont ils ont besoin, ce qu’ils souhaitent • « Pour interroger l’organisation d’une action, il ne faut pas interroger (d’abord) le discours ou la conscience : il faut interroger l’action elle-même, avec cette idée qu’il y a à l’intérieur de celle-ci une organisation, pas forcément connue du sujet, qui la rend efficace, reproductible et aussi analysable » • (Pastré P., Génése et identité, dans Rabardel P. et Pastré P. Modèles du sujet pour la conception,Octares, 2005

8. Ergonomie ? • du grec ergon (travail) • Société d'Ergonomie de Langue Française (1988) • "L'ergonomie est la mise en œuvre de connaissances scientifiques relatives à l'homme • et nécessaires pour concevoir des outils, des machines et des dispositifs • qui puissent être utilisés avec le maximum de confort, de sécurité et d'efficacité pour le plus grand nombre"

9. Ergonomie des interfaces : objectifs • Construire une interface utilisateur ergonomique • adapter la logique du fonctionnement du système informatique à la logique d'utilisation de l'utilisateur • créer chez l'utilisateur une logique d'utilisation par la pratique de l'interface • Favoriser • la « co-adaptation » (Mackay) • la « co-évolution » (Derycke ) du système et des utilisateurs • la« genèse instrumentale »     « catachrèse » (Rabardel)

10. Objectifs de ce cours/ ergonomie • L’ergonomie • est une science • concepts, théories, méthodes, techniques • est un métier • Vous n’êtes pas ergonomes (moi non plus) • Vous êtes, nous sommes des "acteurs ergonomiques" [Rabardel et al. 98] • n'est pas • intuitive, bon sens, goûts et de couleurs, cosmétique • Objectif du cours • Définitions de concepts clés • Sensibilisation à la démarche ergonomique, aux techniques de recueil de données sur les utilisateurs et leur activité • Organisation d’interviews d’utilisateurs (pour le projet)

11. L'homme au travail pour l'ergonomie • [Rabardel et al. 98] • un être singulier (pas un homme moyen) • diversité • variabilité • évolution à moyen et court terme • un acteur intentionnel dont l'action est finalisée en situation de travail

12. L’utilisateur élastique • L’usager standard n’existe pas [Poulain Valot] • L’homme moyen n’existe pas [Rabardel] L’utilisateur lambda n’existe pas non plus… • Hygiène de conception : Interdisez-vous de • parler de " l’utilisateur " • utiliser "on" • On clique, on charge, on sauvegarde… Utilisez des personas, des profils d’utilisateurs • Odette clique, Léa télécharge, Léo sauvegarde

13. Conséquences en conception d'IHM • Prendre en compte les utilisateurs • dans leur diversité • classes d'utilisateurs, personas • dans leur variabilité • contexte intérieur • dynamique d'utilisation • première utilisation/nième • contexte extérieur • stress, bruit etc. • scénarios

14. Travail prescrit/travail réel • Travail prescrit • défini par avance par l'entreprise (et ses personnels) • donné à l'opérateur pour définir, organiser, réaliser et régler son travail • accessible par les consignes, règlements intérieurs, formations etc. • Travail réel • réalisé concrètement dans le bureau, l'atelier ou le service • accessible par l'observation, les rapports d’incidents

15. Écarts travail prescrit/réel • sont ignorés, méconnus, niés, dangereux ou productifs • concernent toutes les dimensions • objectifs, résultats, modes opératoires, outils, instruments et dispositifs • ont des origines multiples • niveau de la prescription, ré-interprétation personnelle • sont variables en fonction des opérateurs, des situations

16. Exemples • Grève du zèle • Le travail des étudiants pour un module • Les opérateurs dans les salles de contrôle de processus industriels • La prise en main d'un nouveau logiciel • Les bouteilles de 2 litres de Coca-cola • ….

17. Distinguer • Ceque les gens • disentqu’ils font • disentque les gens font • font • Ne vousfiez pas uniquement aux déclarations • Observez les actions • Les utilisateurs et les clients ou les donneursd’ordre • Perspectives différentes • Locales/globales • Informationsdifférentes • Diversifiezvos sources d’informations

18. Conséquences en IHM • Ne pas (se contenter de) demander aux gens leur avis • Questionnaires et enquêtes • Leur demander de (raconter comment) faire quelque chose • Observations, prototypage, scénario, tests • Ne pas se contenter du point de vue du client • Diversifiezvos sources d’informations Notion de « stakeholders » (parties prenantes) • Clients ou décideurs • Utilisateurs finaux • Utilisateurs secondaires (vendeurs, maintenance, DSI, etc.)

19. Tâche /activité • Terminologie non stabilisée • ces mots n’ont pas la même acceptation selon les disciplines • ici : en ergonomie • Tâche • but donné à l'individu dans des conditions déterminées • abstraction • Activité • ce qui se fait dans une situation singulière • Analyse du travail • en terme de tâches et d'activité • autres dimensions : • rapports sociaux, rémunération, statut, culture etc.

20. Recueil de données sur les tâches • Tâches élaborées sans l'intervention de l'opérateur • tâche à réaliser • telle que conçue par le concepteur : modes d’emploi • tâche prescrite • telle que présentée à l'opérateur : règlements, consignes, documents de formation • tâche attendue • par le prescripteur, un responsable hiérarchique : interviews • Tâches élaborées par l'opérateur • tâche redéfinie • interprétée par l'opérateur : interviews, commentaires à voix haute (méthode de l’apprenti), l'auto-confrontation • tâche effective • redéfinie et effectivement réalisée : observation

21. Activité • Multiples dimensions : • affective, cognitive, physique • Observables • comportements (gestes, postures, déplacements) • productions (documents, logs etc.) • verbalisations • Analyse de la tâche • centrée sur les processus • de transformation des choses • Analyse de l'activité • centrée sur l'opérateur • ses actions, ses fonctionnements, ses intentions

22. S’informer ? • Les connaissances de base en ergonomie • Selon le projet s’informer sur le domaine • en particulier • Analyse concurrentielle • Études disponibles • Documentation du client • Mode d’emploi, consignes, études marketing etc. • Statistiques de fréquentation • Découvrir les utilisateurs • Recueillir des données • Produire des ressources pour la conception

23. Entretiens • utilisés • pour les enquêtes d'opinion, le recueil d'expertise • l'analyse de besoins et l'étude ergonomique préalable • peuvent être • structurés • mêmes questions et mêmes formats pour tout le monde • + facile à mener, + facile de comparer • ouverts • permettent de saisir des réactions spontanées • permettent de saisir la façon de faire de l'utilisateur • individuels ou collectifs

24. Techniques d’entretien • Objectifs • Contraster le vécu et le prescrit • Obtenir des exemples précis, concrets, spécifiques • Appréhender le contexte d’utilisation • 3 techniques utiles en IHM : • Incident critique • Journée particulière • Cycle de vie

25. Questions • Spécifiques et dirigées • Combien de personnes prennent des médicaments ? • Quelle est la dernière ordonnance que vous avez rapportée ? • Spécifiques et ouvertes • Vous souvenez-vous de la dernière fois que vous avez jeté/cherché un médicament ? Renouvelé votre ordonnance ? • Racontez la dernière fois que vous êtes revenue de la pharmacie • Décrivez comment vous utilisez votre armoire à pharmacie • Générales et ouvertes • Est-ce qu’une pharmacie électronique vous semble utile ?

26. Ordre des questions Très important….. Q spécifiques avantles Q générales Q dirigées avant les Q ouvertes Pourquoi ?

27. Incident critique • Procédure : • Interview d'un utilisateur dans son environnement de travail • Lui demander • se souvenir d'un problème particulier récent (moins d'une semaine) • le décrire en détails • ce qui dans l'incident est habituel et ce qui ne l'est pas • Analyse qualitative • Classer les problèmes • puis les typer • Ex; : erreur sur commande, interprétation erronée d'affichage • Avantage • activité réelle, collecte des problèmes importants pour l'utilisateur et leurs causes • permet de trouver des solutions générales à des problèmes et non de faire du rafistolage ponctuel • Inconvénients • temps, ne couvre pas l'ensemble des problèmes

28. Une journée particulière • Objectif • Obtenir des exemples • pour contraster la description officielle du travail (travail prescrit) • pour comprendre des éléments de contexte • Procédure • Demander à la personne • de décrire une période particulière ou une journée typique incluant des problèmes • d’autres exemples typiques • Conseil • Partir d’exemples précis avant de généraliser

29. Cycle de vie d’un objet • Objectif : • Obtenir des informations sur avant et après et sur le contexte • Procédure : • Demander à la personne de décrire une action du début à la fin • Exemple : Conception d’un agenda La vie d'un Rendez-vous précis • Quand est-il noté, où ? Pourquoi ? Qu’est-ce qui est noté ? • D’autres choses sont-elles conservées en même temps ? • Qu’arrive-t-il ensuite ? • Quand, Pourquoi, Comment cette note est-elle modifiée ? Consultée ? Supprimée ? Oubliée ? Perdue ? Communiquée ? • Conseil : • Toujours se centrer sur des exemples précis

30. Avant l’interview Prévoir • Des questions sur • la personne que vous interviewez (expérience informatique etc….) • ce qui est habituel/accidentel ; • le temps passé pour effectuer une opération • Des relances • pour obtenir des détails (qui, quoi, où, pourquoi, comment) • La répartition des rôles : • 2 interviewers (1 pose les questions, 1 prend des notes ou enregistre et observe) • Le matériel nécessaire à l’interview (magnéto, caméra, ordinateur, maquettes) • Tester le matériel

31. Pendant l’interview • Prévoir 15 à 30 minutes • Commencer par • se présenter • présenter les objectifs (exemples) • préciser la durée de l’interview • Toujours • demander l’autorisation d’enregistrer ou de filmer • faire signer un consentement • Maintenir la discussion sur des exemples précis • Mettre en confiance et ne pas juger

32. Après l’interview • Remercier la personne • A chaud toujours : • reprendre les notes et les compléter • rédiger des observations • réfléchir à ce qui a été dit

33. Questions à poser ? Dans votre projet

34. Observation directe • Procédure : • Observer et enregistrer les utilisateurs en action • Leur demander de commenter leurs actions à haute voix • Exemples • Méthode de l’apprenti : « je suis stagiaire, montrez moi comment faire » • Nombre de tentatives pour réaliser une tâche (première fois, troisième fois), motif de succès, d'échec. • Inconvénients • Méthode intrusive, prend du temps, délicat • Avantages • Important pour appréhender le contexte, détecter les gros problèmes, tests d'utilisabilité • Permet de voir ce que les gens font et non ce qu’ils disent (ou ce qu’on dit) qu’ils font • Utilisée en conception et en évaluation • Indispensable

35. Enquêtes • Plusieurs phases • Rédaction du questionnaire • Administration • Récupération • Traitement des résultats • Guides sur le web (par exemple Ratier-CNRS) ou entreprises spécialisées dans les enquêtes • Avantages • Très utiles pour avoir des informations quantitatives • Des retours d’utilisations (formulaires sur un site) • Inconvénients • Demandent beaucoup de rigueur dans les traitements statistiques • Accès à ce que les gens disent pas ce qu’ils font • Faites appel à des spécialistes

36. En résumé • Recueil de données • Multipliez les perspectives • Croisez les informations • Étude des documents de formation, consignes etc. • Interviews, Observations, Enquêtes • Croisez les interprétations • Ne faites pas seulement parler les gens, regardez les faire • Recherchez des exemples précis et concrets, pas des lieux communs • Synthétiser les données • Analyse des besoins • Formelle (spécialistes) ou informelle (dans ce cours)

37. Découvrir les utilisateurs et leurs activités • Plan • Les concepts de base • Ergonomie • Utilisateur élastique • Utilisabilité • Travail prescrit, travail réel • Tâche et activité • D’autres modèles • Recueil de données • Entretiens, Observations, Magicien d’Oz, Enquête • Outils de Conception Centrée Utilisateur (CCU ) • Personas, Scénarios, (prototypage, cours 3)

38. Analyse de besoins • Définir le concept de départ • Problème à résoudre, état de l’art, participants au projet et les bénéficiaires ou le public cible, hypothèses sur l’impact du projet, questions auxquelles le projet est confronté et les contraintes • Les études de terrain • Analyse des artefacts existants, observation sur le terrain et enregistrement d’activités dans un contexte de travail, interviews • Synthèse des résultats • Analyse de tâche et catégories d’activité • Scénarios d’utilisation et personas • Pensez le plus tard possible en terme de fonctionnalités offertes par le logiciel

39. Distinguer • Analyse de besoins • Quel est le problème à résoudre ? • Conception • Quelle est la solution du problème ?

40. Analyse des tâches • Méthodes formelles • Cf. livre de Brangier • Méthodes informelles • 11 questions (cous de berkley) • Catégories d’activités (Mackay)

41. Analyse de tâches (Brekeley 2011) Qui va utiliser le système ? Quelles tâches exécutent-ils ? Quelles tâches souhaitent-ils ? Comment apprennent-ils à exécuter les tâches ? Où sont exécutées les tâches ? Quelles sont les relations entre les informations et les utilisateurs ? Quels sont les autres outils à disposition ? Comment les utilisateurs communiquent-ils entre eux ? Quelle est la fréquence d’utilisation des tâches ? Quelles sont les contraintes de temps ? Que se passent-il quand les choses vont mal ?

42. Catégories d’activité (Mackay) • Objectifs : • Préparer la création de personas et de scénarios • Faire une synthèse des comportements observés mais en conservant les détails utiles pour la conception • Procédure : • Travail collectif itératif • Relire et organiser les exemples observés dans les entretiens • Créer des histoires courtes pour illustrer chaque catégorie d’activité observée (au moins deux histoires par catégories) • Résumer

43. Les classes d’utilisateurs (stakeholders) • Les utilisateurs du logiciel • Leurs collègues et supérieurs (directeurs) • Les développeurs • Les responsables maintenance et support • Les vendeurs du logiciel • Le service informatique de l’organisation • Les clients de l’organisation • Les syndicats • Les entreprises mères • Les associations d’employés • Les actionnaires (shareholders) • Les gouvernements • (Ramage, 1997)

44. Exemples • Chercheurs de l’Institut Pasteur [Letondal&Mackay 04] • Enquête : • Utilisateurs occasionnels de logiciels scientifiques (36 %) • Utilisateurs de micro-ordinateurs (15%) • Jeunes scientifiques (15 %) intéressés par la bioinformatique • Les apprentis (15%) qui s’initient à l’informatique • Les Gourous (6%) qui sont passionnés d’informatique et de programmation • Pépite • Élèves, professeurs (débutants, expérimentés, formateurs, collège, lycée), chercheurs (en didactique, en informatique)

45. Personas • Créer des personnages • Leurs compétences • Visuelles, tactiles, manipulatrices • Métiers • Connaissances du domaine • Leur contexte • Leur activité • Pourquoi • Évite les problèmes d’utilisateur élastique, de taille unique ou de logiciel bon à tout faire • Maintenir des usagers et leur contexte dans l’équipe de conception tout au long du projet • Faire référence à des utilisations de façon précise dans l’équipe de conception • Fait gagner du temps (on parle de la même chose), facilite la collaboration et la communication

46. Les personas • Représentation fictive d’utilisateur probable • Créé à partir de données réelles. • Guide des décisions concernant la conception • Précise les besoins et les caractéristiques des différents groupes d'utilisateurs lors de la conception ou l’évolution d’un site web.

47. Création d’un personnage • Quoi ? • Buts, attentes, motivations • Contexte • Quand ? Où ? Sur quel ordinateur ? Taille de l’écran ? Sur quel navigateur ? Quelle connexion ? • Qui ? • Age, sexe, éducation, expérience en informatique et sur internet • Valeur • Psychologie • timide/agressif, impatient/patient, impulsif/systématiques • Une journée de sa vie • Lui donner vie en faire des affiches

48. Exemple Jean-Claude Grosjean

49. Scénarios ? • Une description d’une suite d’événements possibles • Format • histoire, « story board », video, tableau, description formelle • Catégories en IHM: • scénarios d’utilisation : • décrivent l’existant (avant ou après la conception) • scénarios de conception (ou de travail) : • imaginent l’utilisation de systèmes futurs • Pourquoi ? • stimuler l’imagination et la créativité, susciter des questionnements un design pertinent pour de vrais utilisateurs dans un vrai contexte, pallier aux insuffisances et à la rigidité des analyses hiérarchiques • Qui utilise ? • Théâtre et cinéma, économistes, politiques, stratèges, management, marketing, conception orientée objet (use-case de UML), IHM

50. Scénarios et cycle de vie • Quand utiliser des scénarios en IHM ? • Tout au long du cycle de développement du produit • Analyse de besoins • Scénario problème, scénario d’utilisation • Scénario observé ou des mixages de scénarios observé • Conception et prototypage • Scénario de conception, scénario de travail • Brainstroming (« remue-méninges ») • Évaluation • Scénario d’utilisation • Revue d’utilisabilité