Conception des IHM Fabien Duchateau fabien.duchateau [at] univ-lyon1.fr Université Claude Bernard Lyon 1 2014-2015 http://liris.cnrs.fr/fabien.duchateau/ens/lif14/ Version originale par Stéphanie Jean-Daubias : http://liris.cnrs.fr/stephanie.jean-daubias/ 1/109
Introduction Étapes du cycle de développement d un logiciel : Analyse (spécifications, analyse de l existant et conception) Réalisation (programmation, bases de données, tests) Livraison (intégration, validation, documentation) Maintenance (mises à jour, correction de bugs) 2/109
Introduction (2) IHM = ensemble des dispositifs matériel et logiciel permettant à une utilisatrice d interagir avec un système interactif Écran/interface d une application : Artefact concret qui sera utilisé par les utilisatrices Un tiers des questions lors de réunions avec les utilisatrices porte sur les IHM Phase de maintenance : 33% de debugging et 67% de changements demandés par les utilisatrices J. Nielsen, Usability engineering, Academic Press, 1993 3/109
Introduction (2) IHM = ensemble des dispositifs matériel et logiciel permettant à une utilisatrice d interagir avec un système interactif Écran/interface d une application : Artefact concret qui sera utilisé par les utilisatrices Un tiers des questions lors de réunions avec les utilisatrices porte sur les IHM Phase de maintenance : 33% de debugging et 67% de changements demandés par les utilisatrices Les IHM doivent être pensées dès la phase d analyse du logiciel! J. Nielsen, Usability engineering, Academic Press, 1993 3/109
Introduction (3) Les IHM ont un impact significatif sur : Attractivité du logiciel Gain de productivité Coûts de développement, de maintenance et de formation http://dilbert.com/ 4/109
Examples de bonnes/mauvaises pratiques Refonte des écrans de saisie chez Ameritech : gain de 600ms / appel 3 millions $ / an Catastrophe de l Airbus (1992) : confusion d affichage des unités sur un cadran d altimétrie Accident nucléaire de Three Mile Island (1979) : absence de prise en compte de la dimension humaine dans le processus de supervision http://en.wikipedia.org/wiki/three_mile_island_accident 5/109
Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 6/109
Conception en génie logiciel Nombreuses méthodes de conception en génie logiciel : Quick and dirty Merise Modèle en cascade Modèle en V Modèle par incréments Modèle en spirale Modèle Agile 7/109
"Quick and dirty Initialement le nom du système d exploitation MSDOS était QDOS, pour Quick and Dirty OS Pas de description précise de la méthode : Phase d analyse et de conception souvent limitée (voire inexistante) Programmation rapide mais sale, code peu réutilisable Encore utilisée pour des prototypes, maquettes ou projets d étudiant-e-s... Méthode à éviter! http://fr.wikipedia.org/wiki/qdos 8/109
Merise Méthode française pour l analyse, la conception et la gestion de projet http://fr.wikipedia.org/wiki/fichier:merise.jpg 9/109
Merise Méthode française pour l analyse, la conception et la gestion de projet Inconvénients Pour des projets de grande ampleur mais souvent internes. Inadaptée aux environnements distribués. http://fr.wikipedia.org/wiki/fichier:merise.jpg 9/109
Modèle en cascade Modèle classique du génie logiciel hérité du BTP (1966) : Défini pour de grands projets Importance des documents signés par les utilisatrices Passage à l étape suivante uniquement si l étape précédente est satisfaite Retour possible uniquement à l étape précédente Laurent Audibert, UML 2 : De l apprentissage à la pratique, Ellipses, 2009 10/109
Modèle en cascade (2) 11/109
Modèle en cascade (2) Inconvénients Implication limitée des utilisatrices. Évaluation lors des deux dernières phases (effet tunnel ). 11/109
Modèle en V Modèle très populaire (1980) : Développement et tests sont effectués en parallèle Importance des documents Retours possibles à chaque étape mais sans connaître leur portée 12/109
Modèle en V (2) Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, Addison-Wesley, 1995 13/109
Modèle en V (2) Inconvénients Évaluation tardive du logiciel. Difficulté à intégrer de nouvelles fonctionnalités pendant le développement Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, Addison-Wesley, 1995 13/109
Modèle par incréments Construction du noyau Ajout progressif de fonctionnalités Noyau 1 2 3 14/109
Modèle par incréments Construction du noyau Ajout progressif de fonctionnalités Noyau 1 2 3 Inconvénients Problèmes possibles pour ajouter une fonctionnalité, voire remise en cause du noyau 14/109
Modèle en spirale Meta-modèle défini en 1986 par Barry Boehm : Plus général que le modèle en V Itérations longues (6 mois à 2 ans) Chaque cycle est découpé en 4 phases Déterminer les objectifs, les alternatives pour les atteindre et les contraintes Évaluation des alternatives, analyse des risques Développement, validation et vérification de la solution retenue (en utilisant un autre modèle) Planification du cycle suivant 15/109
Modèle en spirale (2) http;//en.wikipedia.org/wiki/spiral_model 16/109
Modèle en spirale (2) Inconvénients Étape cruciale d analyse des risques, que l utilisatrice doit accepter http;//en.wikipedia.org/wiki/spiral_model 16/109
Modèle Agile Agile regroupe plusieurs méthodes existantes partageant des valeurs communes : 1. Développement itératif et incrémental 2. Adaptation aux changements 3. Forte collaboration (interne et externe) 4. Logiciels opérationnels 17/109
Modèle Agile (2) Scrum (1995). L équipe est soudée pour concevoir une partie précise des fonctionnalités. L utilisatrice aide à définir les priorités sur les prochaines fonctionnalités à développer. Figure: Itérations (sprints) de la méthode Scrum fr.wikipedia.org/wiki/fichier:planificationscrum.png 18/109
Modèle Agile (3) Extreme Programming (1996) qui inclut de fréquents délivrables (cycles courts), une programmation en binôme, une intégration facilitée des changements utilisatrices. http://extremeprogramming.org 19/109
Modèle Agile (4) Dynamic Systems Development Method (DSDM) est basée sur RAD (Rapid Application Development, 1991) http://en.wikipedia.org/wiki/dsdm http://commons.wikimedia.org/wiki/file:rad15.gif 20/109
Modèle Agile (5) RUP (Rational Unified Process), FDD (Feature Driven Development), Crystal Clear, etc. http://en.wikipedia.org/wiki/software_engineering_process 21/109
En résumé Le cycle de vie en génie logiciel concerne les IHM Avantages des méthodes de conception génie logiciel Certaines méthodes Agile poussent à impliquer fortement les utilisatrices/clientes pendant la phase de conception du logiciel 22/109
En résumé Le cycle de vie en génie logiciel concerne les IHM Avantages des méthodes de conception génie logiciel Certaines méthodes Agile poussent à impliquer fortement les utilisatrices/clientes pendant la phase de conception du logiciel Inconvénients des méthodes de conception génie logiciel Méthodes centrées système (garantie fonctionnelle, centrées sur le client) Utilisatrice impliquée principalement en aval et en amont du projet (analyse et évaluation) 22/109
En résumé (2) Inconvénients des méthodes de conception génie logiciel Principe d indépendance entre le noyau fonctionnel et l interface utilisateur : Interface et interaction ne sont définies qu après Dans les logiciels interactifs, cette séparation n est pas si nette Nécessité de prévoir l usage en même temps que les fonctionnalités (quelques tentatives cependant, e.g., adaptation de SCRUM pour l IHM) Fonctionnalités mises en avant au détriment des utilisatrices http://prog13.free.fr/wp-content/frederic_monjo_scrum_ihm.pdf 23/109
En résumé (2) Inconvénients des méthodes de conception génie logiciel Principe d indépendance entre le noyau fonctionnel et l interface utilisateur : Interface et interaction ne sont définies qu après Dans les logiciels interactifs, cette séparation n est pas si nette Nécessité de prévoir l usage en même temps que les fonctionnalités (quelques tentatives cependant, e.g., adaptation de SCRUM pour l IHM) Fonctionnalités mises en avant au détriment des utilisatrices Méthodes de conception spécifiques aux IHM http://prog13.free.fr/wp-content/frederic_monjo_scrum_ihm.pdf 23/109
Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 24/109
Méthodes de conception IHM Différentes méthodes existantes : Conception itérative Conception par prototypage Conception centrée utilisateur Conception participative Conception informative Conception par personas et scénarios http://blog.excilys.com/2010/09/13/ 25/109
Pourquoi des méthodes de conception IHM? Pourquoi utiliser des méthodes de conception spécifiques aux IHM? Réduction des coûts de développement et de maintenance du logiciel Réduction des risques Gain de productivité côté utilisatrices Réutilisation et améliorations des composants de base du logiciel Réduction du budget et du temps pour la formation au logiciel J.F. Nogier, Ergonomie du logiciel et design Web, Dunod, 2008 26/109
Conception itérative Succession de phases Affinements progressifs des spécifications du produit Évaluations des solutions retenues Réalisations, modifications jusqu à obtention d un produit satisfaisant 27/109
Conception itérative (2) Le processus de construction est itératif : Pour des problèmes difficiles à spécifier Processus de conception ni ascendant, ni descendant Développement de solutions partielles, intermédiaires Apparition en cours de développement de nouveaux objectifs Prise en compte de l avis des utilisatrices qui peuvent changer Communication au sein de l équipe de conception, avec les utilisatrices Difficulté à gérer la conception itérative prototypage 28/109
Conception par prototypage Le prototypage permet : Aux concepteurices de travailler sur plusieurs ensembles de détails à la fois Aux utilisatrices de voir ce que sera le système final De se concentrer sur les parties problématiques de l interface D étudier des alternatives de conception De s assurer de l utilisabilité du système 29/109
Types de prototype Prototypes informels, sur papier Dessiner des écrans sur papier, sur logiciel Utiliser des post-its / transparents / présentations pour des montages dynamiques Exécuter un scénario et essayer des variantes pour des choix de haut niveau : décider des fonctionnalités qui seront disponibles de niveau intermédiaire : dessiner une séquence d écrans de bas niveau : dessiner des idées d icônes 30/109
Types de prototype (2) Example de prototype papier pour une application téléphone http://www.youtube.com/watch?v=yqshwootp5e 31/109
Types de prototype (3) Prototypes vidéo Créer une vidéo de l utilisation d un prototype Simuler les fonctionnalités non implantées, les interactions Prototypes informatiques à l aide d outils : Accès direct à l interface : Visual Basic, Delphi Assistance au prototypage : Visual C, Tcl-Tk, Pencil http://pencil.evolus.vn/ 32/109
Types de prototype (4) D un prototype papier aux prototypes logiciel https://wiki.ubuntu.com/softwarestore 33/109
Conception centrée utilisateur Trois phases : Analyse (identification des fonctionnalités ou services, i.e., l utilité recherchée par les utilisatrices de l application) Développement (construction de la structure des menus et découpage en fenêtres / pages Web) Évaluation (raffinement progressif du prototype) 34/109
Conception centrée utilisateur (2) Prise en compte des utilisatrices : Dès la phase d analyse Étude de l utilisatrice et de sa tâche Nécessité de spécifier les caractéristiques : De l utilisatrice De la tâche à réaliser De l interaction Relations concepteurice - utilisatrice : Utilisatrice observé-e dans la résolution de sa tâche Interrogé-e sur ses attentes Questionné-e sur le logiciel conçu 35/109
Conception centrée utilisateur (3) Avantages : Prise en compte de l utilisatrice avant la phase d évaluation Difficultés : Choisir des utilisatrices représentatifs et disponibles Ne pas oublier le contexte réel d utilisation Expliciter les comportements, les connaissances mises en jeu... Techniques de recueil d informations associées Observation directe, entretiens, questionnaires 36/109
Conception centrée utilisateur (4) Modèle de l utilisateur : identifier les caractéristiques pertinentes de l utilisatrice Données générales taille, âge, sexe, déficiences niveau de formation, habitudes culturelles Données liées à l application : compétences sur le domaine/en informatique débutant, occasionnel, expérimenté, expert 37/109
Conception centrée utilisateur (5) Modèle de la tâche : identifier l enchaînement des processus d une tâche Construire la hiérarchie de tâches du système Spécifier chaque tâche, penser aux exceptions Évaluer la décomposition avec l utilisatrice Définitions : Tâche but = ce qui doit être fait procédure = un ensemble de sous-tâches reliées par des relations de composition ou des relations temporelles Tâche élémentaire tâche décomposable uniquement en actions physiques opérations d E/S 38/109
Conception centrée utilisateur (6) Figure: Modèle de tâche pour l activité envoyer un sms 39/109
Conception centrée utilisateur (7) Modèle de l interaction : il consiste établir une correspondance directe entre : Les objets conceptuels informatiques (e.g., un fichier) Les objets d interaction et de présentation les représentations du fichier à l écran (fermé, ouvert) les opérations sur le fichier (modification, suppression, etc.) Cette correspondance doit : Apparaître comme "naturelle" S inscrire dans une cohérence d ensemble : la métaphore 40/109
Conception centrée utilisateur (8) Métaphore dans le modèle de l interaction : utilisation de concepts connus de l utilisatrice Facilite l apprentissage L utilisatrice anticipe le comportement du système Examples de métaphore du monde réel : Spatiales (bureau, maison, etc.) Sociales ou techniques (imprimante, courrier, etc.) 41/109
Conception participative Prise en compte des utilisatrices : Pas seulement comme testeurs Mais aussi comme partenaires de conception : Tâches essentiellement connues des utilisatrices Source possible d innovations Relations concepteurice-utilisatrice : utilisatrice partenaire de conception à part entière Et participe aux choix de conception finaux Techniques de recueil d informations associées Scénarios, magicien d Oz, inspections cognitives, brainstorming, prototypes 42/109
Conception participative (2) Avantages Seules les utilisatrices connaissent la réalité des tâches Indispensable pour les activités mal identifiées ou peu structurées Facilite l acceptation du logiciel 43/109
Conception participative (2) Avantages Seules les utilisatrices connaissent la réalité des tâches Indispensable pour les activités mal identifiées ou peu structurées Facilite l acceptation du logiciel Inconvénients Augmentation des coûts de développement Contradictions possibles entre les utilisatrices participant-e-s et les autres Obligation d accepter des compromis pour satisfaire des participant-e-s, même s ils/elles ont tort 43/109
Conception informative Prise en compte des utilisatrices : Pas seulement comme testeurs Mais sans les considérer comme partenaires de conception Méthode imaginée pour la conception avec des enfants Relations concepteurice-utilisatrice : utilisatrice dans l équipe de conception Mais ne participe pas aux choix finaux 44/109
Méthode des personas et scenarios Méthode des personas : Utilisée dans différents domaines (plans marketing, sondages, etc.) Introduite aux débuts des années 1990 pour la conception d IHM Objectifs de la méthode : Meilleure compréhension des utilisatrices et de leurs buts Vision partagée des utilisatrices Création de scénarios à partir des personas 45/109
Méthode des personas et scenarios (2) Définition du persona (ou archétype) : Pas un-e utilisatrice réel-le, mais une abstraction de plusieurs Regroupe les traits caractéristiques les plus fréquents des utilisatrices La description d un persona peut inclure : Des objectifs, contraintes, environnement de travail Ce qui va déclencher leurs actions Ce qui peut les influencer Ce qui peut les freiner ou les faire fuir 46/109
Méthode des personas et scenarios (3) Description d un persona (suite) : Un prénom Un titre Une photo Une devise (par rapport à l application) Une description, éducation, background social 47/109
Méthode des personas et scenarios (3) Description d un persona (suite) : Un prénom Un titre Une photo Une devise (par rapport à l application) Une description, éducation, background social Éviter les super-personas et les stéréotypes! 47/109
Méthode des personas et scenarios (4) Exemples de personas 48/109
Méthode des personas et scenarios (4) Exemples de personas 48/109
Méthode des personas et scenarios (5) Un scénario est une sorte d histoire avec : Un persona Un environnement Un but (que le persona doit accomplir) Des obstacles Exécution d un scénario orientation pour les choix de fonctionnalités, interactions, interfaces (et plus tard évaluation de l interface réalisée) http://www.karizmatic.fr/humaniser-lutilisateur/ http://www.qualitystreet.fr/tag/persona/ 49/109
Méthode des personas et scenarios (6) Example de scénario : Se connecter au site Grooveshark, chercher des musiques par titre, auteur ou album, les ajouter à la playlist et étendre cette playlist par l ajout de musiques dans le même genre musical. 50/109
Méthode des personas et scenarios (7) Avantages Empathie cognitive (comprendre les états ou croyances d une autre personne) Applicable au Web / large échelle Inconvénients Mauvaise définition des personas échec Distance par rapport aux utilisatrices réel-les Besoin de modifier les personas en cas de nouveaux résultats ou d environnement différent 51/109
En résumé Garder les points forts des différentes méthodes : Prise en compte précoce de l utilisatrice dès la conception Prise en compte précoce de l évaluation dès la conception utilisateurice utilisateurice conception conception évaluation évaluation 52/109
En résumé (2) Comme l utilisatrice est au centre de ces méthodes, besoin de techniques pour recueillir les informations 53/109
Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 54/109
Techniques de recueil d informations La plupart des méthodes de conception pour IHM nécessitent de collecter des informations sur les utilisatrices et leurs activités avec des techniques : Scénario de conception Inspection cognitive Magicien d Oz Enquête / entretien Observations Focus group Tri par cartes Questionnaire Remue-méninges Conception en parallèle Audit ergonomique 55/109
Scénarios de conception But : Créer une description réaliste de l utilisation du nouveau système Moyen : Utiliser les scénarimages (storyboards) du monde du cinéma Points clés, commentaires, enchaînements Pour une vue d ensemble de l interaction 56/109
Scénarios de conception (2) Procédure : Identifier des activités existantes typiques inhabituelles Créer des scénarios de travail en généralisant les histoires mélanger les événements de différentes provenances incorporer des situations inhabituelles dans des activités typiques inclure des situations qui aboutissent et d autres pas http://grouplab.cpsc.ucalgary.ca/saul/681/1998/prototyping/ survey.html 57/109
Scénarios de conception (3) Figure: Modèle pour écrire un scénarimage http://fr.wikipedia.org/wiki/storyboard 58/109
Scénarios de conception (4) Example de scenarimage 59/109
Inspections cognitives (cognitive walkthroughs) But : Évaluer le système en se mettant à la place de l utilisatrice Moyen : Spécification d une série de tâches et des séquences d actions pour les réaliser Procédure : Évaluation en imaginant ce que ferait l utilisatrice comprend-il les messages, le comportement du système? Interprétation et prise en compte des résultats 60/109
Inspections cognitives (2) Example d inspection cognitive pour l utilisabilité d itunes http://www.youtube.com/watch?v=ro77wqq0swo 61/109
Magicien d Oz But : Simuler les fonctionnalités absentes du système Système réel inexistant ou partiellement développé Technique difficile à mettre en place : adapté à des systèmes lourds, difficile à développer Moyen : Un compère effectue les actions à la place du système 62/109
Magicien d Oz (2) Procédure : Le magicien interprète les entrées de l utilisatrice Il supplée aux manques du prototype et contrôle le comportement du système Sensation d utiliser un vrai système De moins en moins utilisé à cause des logiciels de protypage d interface http://fr.wikipedia.org/wiki/le_magicien_d%27oz 63/109
Magicien d Oz (3) Les "métiers invisibles" http://www.youtube.com/watch?v=skgectyvtou 64/109
Magicien d Oz (4) Example : projet DIALORS, un système de dialogue pour réserver un billet de train en langage naturel Expérimentations réelles en 1984 : une opératrice simule les réponses du système Un des points mis en avant : face à la machine, les utilisatrices ont adopté - contrairement aux attentes des concepteurices - un langage haché simplification du modèle pour le langage naturel http://www-lium.univ-lemans.fr/~luzzati/recherches/ historique_files/dvhm%20luzzati.pdf 65/109
Enquête / entretien But : Identifier des pistes de conception pour les prochaines itérations ou des exemples spécifiques de problèmes rencontrés par les utilisatrices Caractéristiques : Interviewer l utilisatrice dans son environnement de travail (face à face) Durée recommandée de 45 minutes / une heure Privilégier le magnétophone à la prise de notes (traces et concentration sur l échange) 66/109
Enquête / entretien (2) Procédure : Rassembler un panel représentatif d utilisatrices Pendant l interview en face à face : questions semi-directives pour l analyse (degré de liberté) questions plutôt directives pour l évaluation (cibler un élément) neutralité de l enquêteurice reformulation des réponses Analyse des résultats fr.wikibooks.org/wiki/outils_méthodologiques_(sociologie) 67/109
Enquête / entretien (3) Possibilité d utiliser les entretiens pour des incidents critiques : Détécter les points forts et points faibles d un système Demander de se souvenir d un problème particulier vécu dans un passé récent Demander de décrire chaque incident en détail Demander ce qui est habituel et ce qui ne l est pas dans l incident 68/109
Enquête / entretien (4) Avantages Analyse qualitative Identification des tendances et des priorités, ou dans le cas d entretiens critiques, des points forts (à renforcer) et des points faibles (à corriger) 69/109
Enquête / entretien (4) Avantages Analyse qualitative Identification des tendances et des priorités, ou dans le cas d entretiens critiques, des points forts (à renforcer) et des points faibles (à corriger) Inconvénients Vision subjective (ne pas en tirer des conclusions chiffrées) 69/109
Observations But : Identifier les gros problèmes du logiciel (prototype / système final) Procédure : En laboratoire ou sur le terrain Choisir au moins 2 utilisatrices qui agiront indépendamment 70/109
Observations (2) Procédure (suite) Définir une mission spécifique (résoudre un problème, suivre un scénario) Décider de ce que l on veut mesurer Demander aux utilisatrices d effectuer la tâche (méthode intrusive) observation directe simple avec explication à haute voix à deux pour observer leurs interactions (interrogations, explications) Enregistrer les interactions, puis les analyser papier, audio, vidéo, trace informatique 71/109
Observations : analyse de protocole Traces papier : Coût de traitement acceptable Un seul point de vue, car pré-analysé 72/109
Observations : analyse de protocole (2) Enregistrements vidéo (ou audio) : Voir le visage, la posture de l utilisatrice Voir l écran Oculométrie (eye tracking) 73/109
Observations : analyse de protocole (2) Enregistrements vidéo (ou audio) : Voir le visage, la posture de l utilisatrice Voir l écran Oculométrie (eye tracking) Permet de corriger certains biais des protocoles verbaux Très long et coûteux à dépouiller 73/109
Observations : analyse de protocole (3) Traces informatiques : Mémorisation de (toutes) les actions de l utilisatrice Permet de rejouer la session Objectif : dépouillement automatiquement l analyse doit être prévue avant TRACE 13:13:42 Début 13:14:14 Exercice 3 13:14:29 Partie 2 13:14:32 Cahier de brouillon 13:14:49 Représentation graphique 13:14:55 Tracé libre 13:14:59 Effacement 13:15:01 Exercice 4 (Suiv) 13:15:30 Intersection 13:15:54 Exercice terminé 13:15:58 Désactiver les bulles d'aide 13:16:00 Masquer la palette 13:16:02 Aide 13:16:03 Aide page 2 13:16:06 Fin de l'aide 13:16:37 Copier : x-2y=-6 13:16:41 Coller : x-2y=-6 13:17:52 Enregistrement 13:17:54 Fin PRODUCTIO N 13:17:54 [Identificatio n] JEAN- DAUBIAS Stéphanie Date : 23/02/2009 [E01] 1110 0011 [E02P1] 01 [E02P2] 01 [E03] 0010000000 (a+3)(b+a) [FIN] 74/109
Focus group But : Comprendre les motivations des utilisatrices En groupe, et donc bénéfice de la dynamique de groupe Séance filmée, paperboards, et/ou assistant-e-s 75/109
Focus group (2) Procédure : Définir différents thèmes à aborder (5 ou 6 recommandés) Limiter le groupe à 7-10 participant-e-s (timidité, temps de parole) Animation du groupe : activité brise-glace, les utilisatrices font connaissance rappeler les règles à respecter exercices de difficulté croissante, et portant sur des points de plus en plus précis du système synthèse des résultats et discussions 76/109
Focus group (3) Avantages Vision globale sur le système en terme de motivations, préférences, priorités, attentes voire conflits. Séances enrichies par les interactions et par la réutilisation des résultats des séances précédentes. Émergence d idées nouvelles 77/109
Focus group (3) Avantages Vision globale sur le système en terme de motivations, préférences, priorités, attentes voire conflits. Séances enrichies par les interactions et par la réutilisation des résultats des séances précédentes. Émergence d idées nouvelles Inconvénients Éviter pour l évaluation (utilisatrices pas en situation réelle) 77/109
Tri par cartes But : Construire l architecture de l information d une application Utilisé en début de conception Effectuer plusieurs tris (de 3 à 10 selon convergence des résultats et le mode) Préparation : Panel représentatif d utilisatrices Séance en mode individuel ou groupe Chaque carte = une information ou une fonctionnalité (décrite par un ou 2 mots-clés) 78/109
Tri par cartes (2) Procédure en 3 étapes : Validation des mots-clés sur les cartes (réécriture au besoin) Regroupement des cartes qui se ressemblent Choix d un nom pour chaque groupe construit Analyse des résultats : Repérer les groupes les plus fréquemment formés statistiques Analyse qualitative basée sur les observations lors des séances Possibilité de tri fermé (groupes déjà définis et les participant-e-s y rangent les cartes) 79/109
Tri par cartes (3) Avantages Garantie de trouver ce que l on cherche (organisation du contenu) Peu de problèmes de navigation entre les fenêtres / pages Combiner le tri fermé puis tri ouvert en cas de nombre de cartes important (> 100) 80/109
Questionnaires But : Résumer économiquement l avis de nombreuses utilisatrices Procédure : Déterminer le public (représentatif) destinataire du questionnaire Comment diffuser/récupérer Comment analyser les résultats (automatiquement/manuellement) Types de questions : Informations générales Questions ouvertes, dirigées, QCM Échelle, classements 81/109
Questionnaires (2) 82/109
Remue-méninges (brainstorming) But : Générer un grand nombre d idées créatives Procédure : Réunir un petit groupe avec différents rôles et expertises Limiter le temps (1h) Décrire un problème de conception spécifique 83/109
Remue-méninges (2) Phase 1 : générer une grande quantités de solutions faire participer tout le monde, enregistrer toutes les idées sans les évaluer 84/109
Remue-méninges (3) Phase 2 : classer les idées en fonction de leur qualité chacun annonce les idées qu il préfère les idées sont classées par nombre de votes commencer la conception à partir des idées les mieux classées ne pas oublier les idées insolites 85/109
Conception en parallèle But : Créer plusieurs interfaces et sélectionner leurs points forts Procédure : Panel représentatif d utilisatrices Chaque utilisatrice (ou groupe) réalise indépendamment une interface (papier, logiciel, etc.) Discussion autour des interfaces réalisées http://www.useit.com/papers/parallel_design/ 86/109
Conception en parallèle (2) Avantages Les meilleures idées émergeant de la session sont gardées Pistes pour prioritiser les étapes suivantes de conception 87/109
Conception en parallèle (3) 88/109
Audit ergonomique But : Évaluation rapide d une interface par des experts en ergonomie Procédure : Dans l idéal, évaluation par plusieurs experts indépendants et confrontation de leurs résultats En pratique, évaluation par un expert en ergonomie et relecture par un expert du domaine (cf cours d évaluation) 89/109
Audit ergonomique (2) Avantages Rapidité de l audit Pistes pour prioritiser les étapes suivantes de conception 90/109
Audit ergonomique (2) Avantages Rapidité de l audit Pistes pour prioritiser les étapes suivantes de conception Inconvénients Coût de l audit Aucun retour des utilisatrices finaux de l application 90/109
Audit ergonomique (3) 91/109
En résumé Analyse Développement Évaluation Scénarios de conception Inspections cognitives Magicien d Oz Enquêtes / entretiens Observations Questionnaire Remue-méninges Focus group Tri par cartes Conception en parallèle Audit ergonomique Quand utiliser quelle technique? http://www.usability.gov 92/109
Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 93/109
Définition du sujet de TD Sujet : conception d une application de reconnaissance de déchets pour le tri sélectif Description de l application Public cible Description du dispositif Liste des fonctionnalités Méthode(s) de conception Enchaînement et réalisation des maquettes 94/109
Définition du sujet de TD Sujet : conception d une application de reconnaissance de déchets pour le tri sélectif Description de l application Public cible Description du dispositif Liste des fonctionnalités Méthode(s) de conception Enchaînement et réalisation des maquettes Voyons 3 propositions réalisées par des groupes d étudiant-e-s 94/109
Proposition 1 : une application mobile Description de l application : L application permet d identifier un déchet soit en le photographiant avec la fonction appareil photo d une tablette, soit en le recherchant dans des catégories, soit en saisissant des mot-clés. Une fois le déchet identifié, l application indique le type de poubelles où le jeter. Des fonctionnalités cartographiques sont également disponibles (localisation des poubelles, édition collaborative). Public cible : Tout public, équipé d une tablette avec appareil photo Description du dispositif : Application mobile (tablettes) avec appareil photo 95/109
Proposition 1 : une application mobile (2) Liste des fonctionnalités : Recherche d un déchet par mot-clé ou catégorie Reconnaissance d un déchet par photographie Géolocalisation des poubelles Travail collaboratif d ajout de poubelles 96/109
Proposition 1 : une application mobile (3) Conception, première itération Pas d utilisatrice méthode des personas et scénarios Analyse : questionnaire (site Web) et résultats de sondages pour définir des personas et des scénarios remue-méninges pour les idées et fonctionnalités prioritaires Développement des interfaces par prototypage En parallèle, diffusion et promotion (site Web, etc.) Phase d évaluation : inspection cognitive (en utilisant les personas) 97/109
Proposition 1 : une application mobile (4) Conception, première itération Exemple de scénario : Steve, 22 ans, se lève à 7h et prend son petit déjeuner. À la fin de son repas, sa bouteille de lait de riz est vide et il ne sait pas où il peut la jeter. Heureusement, il se souvient avoir téléchargé une application pour le tri sélectif. Il décide alors de l utiliser. Empoignant la bouteille d une main, il la prend en photo et l application réussit à reconnaître le déchet. Il consulte la fiche produit correspondante et découvre le type de poubelles adéquat pour y jeter la bouteille, ainsi que des informations de recyclage sur l objet. Satisfait, Steve quitte l application en appuyant sur le bouton«home». 98/109
Proposition 1 : une application mobile (5) Conception, seconde itération utilisatrices attiré-e-s par l application grâce à la promotion méthode de conception centrée utilisateur Analyse : focus group pour comprendre les motivations des utilisatrices entretiens avec les utilisatrices pour définir le modèle de la tâche Développement des interfaces : conception en parallèle pour améliorer les faiblesses détectées sur les interfaces Phase d évaluation : observations de l utilisatrice 99/109
Proposition 1 : une application mobile (6) Conception, seconde itération Modèle de la tâche pour la proposition 1 100/109
Proposition 1 : une application mobile (7) Vidéo de démonstration de la proposition 1 (IHM-ecolo) 101/109
Proposition 2 : une borne près des poubelles Description de l application : Un-e utilisatrice apporte son déchet aux poubelles de recyclage mais ne sait pas dans quelle poubelle le jeter. Une borne tactile permet d identifier le déchet par recherche (mot-clé et catégorie) ou par scan du code barre, puis indique la couleur de la poubelle où jeter le déchet. Des conseils et astuces sont également affichés sur la borne pour valoriser le déchet (compostage, dons, etc.) Public cible : Les personnes qui recyclent déjà Description du dispositif : Application lourde sur des bornes situées à côté des poubelles 102/109
Proposition 2 : une borne près des poubelles (2) Liste des fonctionnalités : Recherche d un déchet par mot-clé ou catégorie Reconnaissance d un déchet par code barre Conseils et astuces de recyclage Menu de configuration 103/109
Proposition 2 : une borne près des poubelles (3) Conception, première itération utilisatrices réels à proximité des lieux de recyclage méthode de conception informative Analyse : questionnaires pour étayer les fonctionnalités scénarios de conception pour modéliser les interactions Développement des interfaces : tri par cartes pour réaliser l enchaînement des interfaces Phase d évaluation : magicien d Oz par l installation de bornes fictives 104/109
Proposition 2 : une borne près des poubelles (4) Conception, première itération Enchaînement des écrans pour la proposition 2 105/109
Proposition 2 : une borne près des poubelles (5) Vidéo de démonstration de la proposition 2 (Tri-force) 106/109
Proposition 3 : du jeu éducatif à "Big Brother" Évolution de la proposition (et des interfaces) : A l origine un jeu éducatif pour apprendre à bien trier les déchets 107/109
Proposition 3 : du jeu éducatif à "Big Brother" Évolution de la proposition (et des interfaces) : A l origine un jeu éducatif pour apprendre à bien trier les déchets Enregistrement des actions de tri (quel déchet et dans quelle poubelle) grâce au téléphone portable 107/109
Proposition 3 : du jeu éducatif à "Big Brother" Évolution de la proposition (et des interfaces) : A l origine un jeu éducatif pour apprendre à bien trier les déchets Enregistrement des actions de tri (quel déchet et dans quelle poubelle) grâce au téléphone portable Ajout d un système de récompense et punition pour chaque personne 107/109
Proposition 3 : du jeu éducatif à "Big Brother" Évolution de la proposition (et des interfaces) : A l origine un jeu éducatif pour apprendre à bien trier les déchets Enregistrement des actions de tri (quel déchet et dans quelle poubelle) grâce au téléphone portable Ajout d un système de récompense et punition pour chaque personne Finalement, n importe qui est capable "d attraper une personne" et de savoir si elle recycle bien 107/109
Bilan Ce qu il faut retenir : Les méthodes de conception en génie logiciel sont insuffisantes pour la conception des IHM Conception de l IHM précoce, méthodique, itérative, expérimentale Pas de méthode scientifique analytique pour la conception des IHM, mais plutôt des méthodes empiriques Combiner différentes méthodes de conception IHM Leur associer une ou plusieurs techniques de recueil d informations 108/109
Des questions, commentaires? www.projectcartoon.com 109/109