Conception des IHM. Fabien Duchateau

Transcription

1 Conception des IHM Fabien Duchateau fabien.duchateau [at] univ-lyon1.fr Université Claude Bernard Lyon Version originale par Stéphanie Jean-Daubias : 1/109

2 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

3 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, /109

4 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, /109

5 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 4/109

6 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 5/109

7 Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 6/109

8 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

9 "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! 8/109

10 Merise Méthode française pour l analyse, la conception et la gestion de projet 9/109

11 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. 9/109

12 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, /109

13 Modèle en cascade (2) 11/109

14 Modèle en cascade (2) Inconvénients Implication limitée des utilisatrices. Évaluation lors des deux dernières phases (effet tunnel ). 11/109

15 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

16 Modèle en V (2) Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, Addison-Wesley, /109

17 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, /109

18 Modèle par incréments Construction du noyau Ajout progressif de fonctionnalités Noyau /109

19 Modèle par incréments Construction du noyau Ajout progressif de fonctionnalités Noyau Inconvénients Problèmes possibles pour ajouter une fonctionnalité, voire remise en cause du noyau 14/109

20 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

21 Modèle en spirale (2) http;//en.wikipedia.org/wiki/spiral_model 16/109

22 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

23 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

24 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

25 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. 19/109

26 Modèle Agile (4) Dynamic Systems Development Method (DSDM) est basée sur RAD (Rapid Application Development, 1991) /109

27 Modèle Agile (5) RUP (Rational Unified Process), FDD (Feature Driven Development), Crystal Clear, etc. 21/109

28 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

29 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

30 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 23/109

31 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 23/109

32 Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 24/109

33 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 25/109

34 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, /109

35 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

36 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

37 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

38 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

39 Types de prototype (2) Example de prototype papier pour une application téléphone 31/109

40 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 32/109

41 Types de prototype (4) D un prototype papier aux prototypes logiciel 33/109

42 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

43 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

44 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

45 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

46 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

47 Conception centrée utilisateur (6) Figure: Modèle de tâche pour l activité envoyer un sms 39/109

48 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

49 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

50 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

51 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

52 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

53 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

54 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

55 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

56 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

57 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

58 Méthode des personas et scenarios (4) Exemples de personas 48/109

59 Méthode des personas et scenarios (4) Exemples de personas 48/109

60 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) /109

61 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

62 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

63 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

64 En résumé (2) Comme l utilisatrice est au centre de ces méthodes, besoin de techniques pour recueillir les informations 53/109

65 Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 54/109

66 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

67 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

68 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 survey.html 57/109

69 Scénarios de conception (3) Figure: Modèle pour écrire un scénarimage 58/109

70 Scénarios de conception (4) Example de scenarimage 59/109

71 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

72 Inspections cognitives (2) Example d inspection cognitive pour l utilisabilité d itunes 61/109

73 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

74 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 63/109

75 Magicien d Oz (3) Les "métiers invisibles" 64/109

76 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 historique_files/dvhm%20luzzati.pdf 65/109

77 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

78 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

79 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

80 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

81 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

82 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

83 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

84 Observations : analyse de protocole Traces papier : Coût de traitement acceptable Un seul point de vue, car pré-analysé 72/109

85 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

86 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

87 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] [E02P1] 01 [E02P2] 01 [E03] (a+3)(b+a) [FIN] 74/109

88 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

89 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

90 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

91 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

92 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

93 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

94 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

95 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

96 Questionnaires (2) 82/109

97 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

98 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

99 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

100 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 86/109

101 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

102 Conception en parallèle (3) 88/109

103 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

104 Audit ergonomique (2) Avantages Rapidité de l audit Pistes pour prioritiser les étapes suivantes de conception 90/109

105 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

106 Audit ergonomique (3) 91/109

107 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? 92/109

108 Plan du cours Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d informations Un cas concret 93/109

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

110 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

111 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

112 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

113 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

114 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

115 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

116 Proposition 1 : une application mobile (6) Conception, seconde itération Modèle de la tâche pour la proposition 1 100/109

117 Proposition 1 : une application mobile (7) Vidéo de démonstration de la proposition 1 (IHM-ecolo) 101/109

118 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

119 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

120 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

121 Proposition 2 : une borne près des poubelles (4) Conception, première itération Enchaînement des écrans pour la proposition 2 105/109

122 Proposition 2 : une borne près des poubelles (5) Vidéo de démonstration de la proposition 2 (Tri-force) 106/109