ConceptionIHM Lect1

Conception des IHM
Fabien Duchateau
fabien.duchateau [at] univ-lyon1.fr

Université Claude Bernard Lyon 1
2013 - 2014
Transparents disponibles sur

http://liris.cnrs.fr/stephanie.jean-daubias/
Version originale par Stéphanie Jean-Daubias
1/107
Introduction
Etapes du cycle de développement d’un logiciel :
I Analyse (spécifications, analyse de l’existant et conception)
I Réalisation (programmation, bases de données, tests)
I Livraison (intégration, validation, documentation)
I Maintenance (mises à jour, correction de bugs)
2/107
LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Introduction (2)
IHM = ensemble des dispositifs matériel et logiciel permettant à

un-e utilisateurice d’interagir avec un système interactif
I Artefact concret qui sera utilisé par les utilisateurices
I Un tiers des questions lors de réunions avec les utilisateurices
porte sur les IHM
I Phase de maintenance : 33% de debugging et 67% de
changements demandés par les utilisateurices
3/107
J. Nielsen, Usability engineering, Academic Press, 1993

Introduction (2)
IHM = ensemble des dispositifs matériel et logiciel permettant à

un-e utilisateurice d’interagir avec un système interactif
I Artefact concret qui sera utilisé par les utilisateurices
I Un tiers des questions lors de réunions avec les utilisateurices
porte sur les IHM
I Phase de maintenance : 33% de debugging et 67% de
changements demandés par les utilisateurices
Les IHM doivent être pensées dès la phase d’analyse du logiciel !
3/107
J. Nielsen, Usability engineering, Academic Press, 1993

Introduction (3)
Les IHM ont un impact significatif sur :

I Attractivité du logiciel
I Gain de productivité
I Coûts de développement, de maintenance et de formation
4/107

Examples de bonnes/mauvaises pratiques
I Refonte des écrans de saisie chez Ameritech : gain de 600ms /
appel ⇒ 3 millions $ / an
I Catastrophe de l’Airbus (1992) : confusion d’affichage des
unités sur un cadran d’altimétrie
I Accident nucléaire de Three Mile Island (1979) : absence de
prise en compte de la dimension humaine dans le processus de
supervision
5/107
en.wikipedia.org/wiki/Three_Mile_Island_accident
Plan du cours
Conception en génie logiciel
Méthodes de conception IHM
Techniques de recueil d’informations
Un cas concret
6/107

Conception en génie logiciel Méthodes de conception IHM Techniques de recueil d’informations Un cas concret
Nombreuses méthodes de conception en génie logiciel :

I Merise
I Modèle en cascade
I Modèle en V
I Modèle par incréments
I Modèle en spirale
I Modèle Agile
7/107

Merise
Méthode française pour l’analyse, la conception et la gestion de
projet
8/107
fr.wikipedia.org/wiki/Fichier:MERISE.jpg
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.
8/107
fr.wikipedia.org/wiki/Fichier:MERISE.jpg
Modèle en cascade
Modèle classique du génie logiciel hérité du BTP (1966) :

I Défini pour de grands projets
I Importance des documents signés par les utilisateurices
I Passage à l’étape suivante uniquement si l’étape précédente
est satisfaite
I Retour possible uniquement à l’étape précédente
9/107
Laurent Audibert, UML 2 : De l’apprentissage à la pratique, Ellipses, 2009

Modèle en cascade (2)
10/107

Modèle en cascade (2)
Inconvénients
Implication limitée des utilisateurices. Evaluation lors des deux
dernières phases (effet “tunnel”). 10/107

Modèle en V
Modèle très populaire (1980) :

I Développement et tests sont effectués en parallèle
I Importance des documents
I Retours possibles à chaque étape mais sans connaître leur
portée
11/107

Modèle en V (2)
Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, 12/107
Addison-Wesley, 1995
Modèle en V (2)
Inconvénients
Evaluation tardive du logiciel. Nouvelles fonctionnalités pendant le
développement
Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, 12/107
Addison-Wesley, 1995
Modèle par incréments
I Construction du noyau
I Ajout progressif de fonctionnalités
4
3
2
1
noyau
13/107

Modèle par incréments
I Construction du noyau
I Ajout progressif de fonctionnalités
4
3
2
1
noyau
Inconvénients
Problèmes possibles pour ajouter une fonctionnalité, voire remise
en cause du noyau
13/107

Modèle en spirale
Meta-modèle défini en 1986 par Barry Boehm :

I Plus général que le modèle en V
I Itérations longues (6 mois à 2 ans)
I Chaque cycle est découpé en 4 phases
I Déterminer les objectifs, les alternatives pour les atteindre et
les contraintes
I Evaluation des alternatives, analyse des risques
I Développement, validation et vérification de la solution retenue
(en utilisant un autre modèle)
I Planification du cycle suivant
14/107

Modèle en spirale (2)
15/107
en.wikipedia.org/wiki/Spiral_model
Modèle en spirale (2)
Inconvénients
Etape cruciale d’analyse des risques, que l’utilisateurice doit
accepter
15/107
en.wikipedia.org/wiki/Spiral_model
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
16/107

Modèle Agile (2)
I Scrum (1995). L’équipe est soudée pour concevoir une partie

précise des fonctionnalités. L’utilisateurice aide à définir les
priorités sur les prochaines fonctionnalités à développer.
Figure: Itérations (sprints) de la méthode Scrum
17/107
fr.wikipedia.org/wiki/Fichier:PlanificationScrum.png
Modèle Agile (3)
I Extreme Programming (1996) qui inclut de fréquents

délivrables (cycles courts), une programmation en binôme,
une intégration facilitée des changements utilisateurices.
18/107
extremeprogramming.org
Modèle Agile (4)
I Dynamic Systems Development Method (DSDM) est

basé sur RAD (Rapid Application Development, 1991)
en.wikipedia.org/wiki/DSDM 19/107
commons.wikimedia.org/wiki/File:Rad15.gif
Modèle Agile (5)

I RUP (Rational Unified Process), FDD (Feature Driven
Development), Crystal Clear, etc .
20/107
en.wikipedia.org/wiki/Software_engineering_process
En résumé
Le cycle de vie en génie logiciel concerne les IHM

Avantages
Certaines méthodes Agile poussent à impliquer fortement les
utilisateurices pendant la phase de conception du logiciel
21/107

En résumé
Le cycle de vie en génie logiciel concerne les IHM

Avantages
Certaines méthodes Agile poussent à impliquer fortement les
utilisateurices pendant la phase de conception du logiciel
Inconvénients
I Méthodes centrées système
I Utilisateurice impliqué-e principalement en aval et en amont
du projet (analyse et évaluation)
21/107

En résumé (2)
Inconvénients
I Principe d’indépendance entre le noyau fonctionnel et
l’interface utilisateur :
I Interface et interaction ne sont définies qu’après
I Dans les logiciels interactifs, cette séparation n’est pas si nette
I Nécessité de prévoir l’usage en même temps que les
fonctionnalités
I Fonctionnalités mises en avant au détriment des utilisateurices
22/107

En résumé (2)
Inconvénients
I Principe d’indépendance entre le noyau fonctionnel et
l’interface utilisateur :
I Interface et interaction ne sont définies qu’après
I Dans les logiciels interactifs, cette séparation n’est pas si nette
I Nécessité de prévoir l’usage en même temps que les
fonctionnalités
I Fonctionnalités mises en avant au détriment des utilisateurices
⇒ Méthodes de conception spécifiques aux IHM
22/107

Plan du cours
Un cas concret
23/107

Différentes méthodes existantes :

I Conception itérative
I Conception par prototypage
I Conception centrée utilisateur
I Conception participative
I Conception informative
I Conception par personas et scénarios
24/107
http://blog.excilys.com/2010/09/13/
Pourquoi des méthodes de conception IHM ?
Pourquoi utiliser des méthodes de conception spécifiques aux

IHM ?
I Réduction des coûts de développement et de maintenance du
logiciel
I Réduction des risques
I Gain de productivité côté utilisateurices
I Réutilisation et améliorations des composants de base du
logiciel
I Réduction du budget et du temps pour la formation au logiciel
25/107
J.F. Nogier, Ergonomie du logiciel et design Web, Dunod, 2008

Conception itérative
Succession de phases
I Affinements progressifs des spécifications du produit
I Evaluations des solutions retenues
I Réalisations, modifications jusqu’à obtention d’un produit
satisfaisant
26/107

Conception itérative (2)
Le processus de construction est itératif :

I Pour des problèmes difficiles à spécifier
I Processus de conception ni ascendant, ni descendant
I Développement de solutions partielles, intermédiaires
I Apparition en cours de développement de nouveaux objectifs
I Prise en compte de l’avis des utilisateurices qui peuvent
changer
I Communication au sein de l’équipe de conception, avec les
utilisateurices
Difficulté à gérer la conception itérative ⇒ prototypage
27/107

Conception par prototypage
Le prototypage permet :
I Aux concepteurices de travailler sur plusieurs ensembles de
détails à la fois
I Aux utilisateurices de voir ce que sera le système final
I De se concentrer sur les parties problématiques de l’interface
I D’étudier des alternatives de conception
I De s’assurer de l’utilisabilité du système
28/107

Types de prototype
Prototypes informels, sur papier

I Dessiner des écrans sur papier, sur logiciel
I Utiliser des post-its / transparents / présentations pour des
montages dynamiques
I Exécuter un scénario et essayer des variantes pour des choix
I de haut niveau : décider des fonctionnalités qui seront
disponibles
I de niveau intermédiaire : dessiner une séquence d’écrans
I de bas niveau : dessiner des idées d’icônes
29/107

Types de prototype (2)
Example de prototype papier pour une application téléphone
30/107
http://www.youtube.com/watch?v=YQsHwooTP5E

Prototypes vidéo
I Créer une vidéo de l’utilisation d’un prototype
I Simuler les fonctionnalités non implantées, les interactions
Prototypes informatiques à l’aide d’outils :
I Accès direct à l’interface : Visual Basic, Delphi
I Assistance au prototypage : Visual C, Tcl-Tk, Pencil
31/107
http://pencil.evolus.vn/
D’un prototype papier aux prototypes logiciel

32/107
https://wiki.ubuntu.com/SoftwareStore
Conception centrée utilisateur

Trois phases :
I Analyse (identification des fonctionnalités ou services, i.e.,
l’utilité recherchée par les utilisateurices de l’application)
I Développement (construction de la structure des menus et
découpage en fenêtres / pages Web)
I Evaluation (raffinement progressif du prototype)
33/107

Conception centrée utilisateur (2)
Prise en compte des utilisateurices :

I Dès la phase d’analyse
I Etude de l’utilisateurice et de sa tâche
Nécessité de spécifier les caractéristiques :
I De l’utilisateurice
I De la tâche à réaliser
I De l’interaction
Relations concepteurice - utilisateurice :
I Utilisateurice observé-e dans la résolution de sa tâche
I Interrogé-e sur ses attentes
I Questionné-e sur le logiciel conçu
34/107

Avantages :
I Prise en compte de l’utilisateurice avant la phase d’évaluation
Difficultés :
I Choisir des utilisateurices représentatifs et disponibles
I Ne pas oublier le contexte réel d’utilisation
I Expliciter les comportements, les connaissances mises en jeu...
Techniques de recueil d’informations associées

Observation directe, entretiens, questionnaires
35/107

Modèle de l’utilisateur : identifier les caractéristiques pertinentes

de l’utilisateurice
I Données générales
I taille, âge, sexe, déficiences
I niveau de formation, habitudes culturelles
I Données liées à l’application : compétences sur le domaine/en
informatique
I débutant, occasionnel, expérimenté, expert
36/107

Modèle de la tâche : identifier l’enchaînement des processus

d’une tâche
I Construire la hiérarchie de tâches du système
I Spécifier chaque tâche, penser aux exceptions
I Evaluer la décomposition avec l’utilisateurice
Définitions :
I Tâche
I but = ce qui doit être fait
I procédure = un ensemble de sous-tâches reliées par des
relations de composition ou des relations temporelles
I Tâche élémentaire
I tâche décomposable uniquement en actions physiques
opérations d’E/S
37/107

Figure: Modèle de tâche pour l’activité “envoyer un sms”

38/107

Modèle de l’interaction : établir une correspondance directe

entre
I Les objets conceptuels informatiques (e.g., un fichier)
I Les objets d’interaction et de présentation
I les représentations du fichier à l’écran (fermé, ouvert)
I les opérations sur le fichier (modification, suppression, etc.)
Cette correspondance doit :
I Apparaître comme "naturelle"
I S’inscrire dans une cohérence d’ensemble : la métaphore
39/107

Métaphore dans le modèle de l’interaction : utilisation de concepts

connus de l’utilisateurice
I Facilite l’apprentissage
I L’utilisateurice anticipe le comportement du système
Examples de métaphore du monde réel :
I Spatiales (bureau, maison, etc.)
I Sociales ou techniques (imprimante, courrier, etc.)
40/107

Conception participative

I Pas seulement comme testeurs
I Mais aussi comme partenaires de conception :
I Tâches essentiellement connues des utilisateurices
I Source possible d’innovations
Relations concepteurice-utilisateurice :
I Utilisateurice partenaire de conception à part entière
I Et participe aux choix de conception finaux
Techniques de recueil d’informations associées

Scénarios, magicien d’Oz, inspections cognitives, brainstorming,
prototypes
41/107

Conception participative (2)
Avantages
I Seules les utilisateurices connaissent la réalité des tâches
I Indispensable pour les activités mal identifiées ou peu
structurées
I Facilite l’acceptation du logiciel
42/107

Conception participative (2)
Avantages
I Seules les utilisateurices connaissent la réalité des tâches
I Indispensable pour les activités mal identifiées ou peu
structurées
I Facilite l’acceptation du logiciel
Inconvénients
I Augmentation des coûts de développement
I Contradictions possibles entre les utilisateurices participant-e-s
et les autres
I Obligation d’accepter des compromis pour satisfaire des
participant-e-s, même s’ils/elles ont tort
42/107

Conception informative

I Pas seulement comme testeurs
I Mais sans les considérer comme partenaires de conception
I Méthode imaginée pour la conception avec des enfants
Relations concepteurice-utilisateurice :
I Utilisateurice dans l’équipe de conception
I Mais ne participe pas aux choix finaux
43/107

Méthode des personas et scenarios

Méthode des personas :
I Utilisée dans différents domaines (plans marketing, sondages,
etc.)
I Introduite aux débuts des années 1990 pour la conception
d’IHM
Objectifs de la méthode :
I Meilleure compréhension des utilisateurices et de leurs buts
I Vision partagée des utilisateurices
I Création de scénarios à partir des personas
44/107

Méthode des personas et scenarios (2)
Définition du persona (ou archétype) :

I Pas un-e utilisateurice réel-le, mais une abstraction de
plusieurs
I Regroupe les traits caractéristiques les plus fréquents des
utilisateurices
La description d’un persona peut inclure :
I Des objectifs, contraintes, environnement de travail
I Ce qui va déclencher leurs actions
I Ce qui peut les influencer
I Ce qui peut les freiner ou les faire fuir
45/107

I Un prénom
I Un titre
I Une photo
I Une devise (par rapport à l’application)
I Une description, éducation, background social
46/107

I Un prénom
I Un titre
I Une photo
I Une devise (par rapport à l’application)
I Une description, éducation, background social
Eviter les “super-personas” et les stéréotypes !
46/107

Exemples de personas 47/107

Exemples de personas 47/107

Un scenario est une sorte d’histoire avec :

I Un persona
I Un environnement
I Un but (que le persona doit accomplir)
I 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/ 48/107
http://www.qualitystreet.fr/tag/persona/

Example de scenario : 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.
49/107

Avantages
I Empathie cognitive (comprendre les états ou croyances d’une
autre personne)
I Applicable au Web / large échelle
Inconvénients
I Mauvaise définition des personas ⇒ échec
I Distance par rapport aux utilisateurices réel-les
I Besoin de modifier les personas en cas de nouveaux résultats
ou d’environnement différent
50/107

En résumé
Garder les points forts des différentes méthodes :

I Prise en compte précoce de l’utilisateurice dès la conception
I Prise en compte précoce de l’évaluation dès la conception
utilisateurice
utilisateurice
conception
conception évaluation
évaluation
51/107

En résumé (2)
⇒ Comme l’utilisateurice est au centre de ces méthodes, besoin de

techniques pour recueillir les informations
52/107

Plan du cours
Un cas concret
53/107

La plupart des méthodes de conception pour IHM nécessitent de

collecter des informations sur les utilisateurices et leurs activités
avec des techniques :
I Scénario de conception I Tri par cartes

I Inspection cognitive I Questionnaire
I Magicien d’Oz I Remue-méninges
I Enquête / entretien I Conception en parallèle
I Observations I Audit ergonomique
I Focus group
54/107

Scénarios de conception
But :
I Créer une description réaliste de l’utilisation du nouveau
système
Moyen :
I Utiliser les scénarimages (storyboards) du monde du cinéma
I Points clés, commentaires, enchaînements
I Pour une vue d’ensemble de l’interaction
55/107

Scénarios de conception (2)
Procédure :
I Identifier des activités existantes
I typiques
I inhabituelles
I Créer des scénarios de travail en généralisant les histoires
I mélanger les événements de différentes provenances
I incorporer des situations inhabituelles dans des activités
typiques
I inclure des situations qui aboutissent et d’autres pas
http://grouplab.cpsc.ucalgary.ca/saul/681/1998/prototyping/ 56/107
survey.html
Figure: Modèle pour écrire un scénarimage
57/107
http://fr.wikipedia.org/wiki/Storyboard
Example de scenarimage 58/107

Inspections cognitives (cognitive walkthroughs)
But :
I Évaluer le système en se mettant à la place de l’utilisateurice
Moyen :
I Spécification d’une série de tâches et des séquences d’actions
pour les réaliser
Procédure :
I Évaluation en imaginant ce que ferait l’utilisateurice
I comprend-il les messages, le comportement du système ?
I Interprétation et prise en compte des résultats
59/107

Inspections cognitives (2)
Example d’inspection cognitive pour l’utilisabilité d’iTunes
60/107
http://www.youtube.com/watch?v=Ro77wQq0sWo
Magicien d’Oz
But :
I Simuler les fonctionnalités absentes du système
I Système réel inexistant ou partiellement développé
I Technique difficile à mettre en place : adapté à des systèmes

lourds, difficile à développer
Moyen :
I Un compère effectue les actions à la place du système
61/107

Magicien d’Oz (2)
Procédure :
I Le “magicien” interprète les entrées de l’utilisateurice
I Il supplée aux manques du prototype et contrôle le
comportement du système
I Sensation d’utiliser un vrai système
De moins en moins utilisé à cause des logiciels de protypage

d’interface
62/107
http://fr.wikipedia.org/wiki/Le_Magicien_d%27Oz
Magicien d’Oz (3)
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 utilisateurices

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/ 63/107
historique_files/DVHM%20luzzati.pdf
Enquête / entretien
But :
I Identifier des pistes de conception
pour les prochaines itérations
ou des exemples spécifiques
de problèmes rencontrés par
les utilisateurices
Caractéristiques :
I Interviewer l’utilisateurice dans son environnement de travail
(face à face)
I Durée recommandée de 45 minutes / une heure
I Privilégier le magnétophone à la prise de notes (traces et
concentration sur l’échange)
64/107

Enquête / entretien (2)
Procédure :
I Rassembler un panel représentatif d’utilisateurices
I Pendant l’interview en face à face :
I questions semi-directives pour l’analyse (degré de liberté)
I questions plutôt directives pour l’évaluation (cibler un élément)
I neutralité de l’enquêteurice
I reformulation des réponses
I Analyse des résultats
65/107
fr.wikibooks.org/wiki/Outils_méthodologiques_(sociologie)
Possibilité d’utiliser les entretiens pour des incidents critiques :

I Détécter les points forts et points faibles d’un système
I Demander de se souvenir d’un problème particulier vécu dans
un passé récent
I Demander de décrire chaque incident en détail
I Demander ce qui est habituel et ce qui ne l’est pas dans
l’incident
66/107

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)
67/107

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)
67/107

Observations
But :
I Identifier les gros problèmes du logiciel (prototype / système
final)
Procédure :
I En laboratoire ou sur le terrain
I Choisir au moins 2 utilisateurices qui agiront indépendamment
68/107

Observations (2)
I Définir une mission spécifique (résoudre un problème, suivre

un scénario)
I Décider de ce que l’on veut mesurer
I Demander aux utilisateurices d’effectuer la tâche (méthode
intrusive)
I observation directe simple
I avec explication à haute voix
I à deux pour observer leurs interactions (interrogations,
explications)
I Enregistrer les interactions, puis les analyser
I papier, audio, vidéo, trace informatique
69/107

Observations : analyse de protocole
Traces papier :
I Coût de traitement
acceptable
I Un seul point de vue,
car “pré-analysé”
70/107

Observations : analyse de protocole (2)

Enregistrements vidéo (ou audio) :
I Voir le visage, la posture de l’utilisateurice
I Voir l’écran
Oculométrie (eye tracking)
71/107


Enregistrements vidéo (ou audio) :
I Voir le visage, la posture de l’utilisateurice
I Voir l’écran
Oculométrie (eye tracking)
Permet de corriger certains biais des protocoles verbaux
Très long et coûteux à dépouiller 71/107


Traces informatiques :
I Mémorisation de (toutes) les actions de l’utilisateurice
I Permet de rejouer la session
I Objectif : dépouillement automatiquement
I l’analyse doit être prévue avant
TRACE PRODUCTIO
13:13:42 Début N
13:14:14 Exercice 3 13:17:54
13:14:29 Partie 2 [Identificatio
13:14:32 Cahier de brouillon n]
13:14:49 Représentation JEAN-
graphique DAUBIAS
13:14:55 Tracé libre Stéphanie
13:14:59 Effacement Date :
13:15:01 Exercice 4 (Suiv) 23/02/2009
13:15:30 Intersection
13:15:54 Exercice terminé [E01]
13:15:58 Désactiver les 1110
bulles d'aide 0011
13:16:00 Masquer la palette [E02P1]
13:16:02 Aide 01
13:16:03 Aide page 2 [E02P2]
13:16:06 Fin de l'aide 01
13:16:37 Copier : x-2y=-6 [E03]
13:16:41 Coller : x-2y=-6 0010000000
13:17:52 Enregistrement (a+3)(b+a)
72/107
13:17:54 Fin [FIN]

Focus group
But :
I Comprendre les motivations des utilisateurices
I En groupe, et donc bénéfice de la dynamique de groupe
I Séance filmée, paperboards, et/ou assistant-e-s
73/107

Focus group (2)
Procédure :
I Définir différents thèmes à aborder (5 ou 6 recommandés)
I Limiter le groupe à 7-10 participant-e-s (timidité, temps de
parole)
I Animation du groupe :
I activité “brise-glace”, les utilisateurices font connaissance
I rappeler les règles à respecter
I exercices de difficulté croissante, et portant sur des points de
plus en plus précis du système
I synthèse des résultats et discussions
74/107

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.
Emergence d’idées nouvelles
75/107

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.
Emergence d’idées nouvelles
Inconvénients
Eviter pour l’évaluation (utilisateurices pas en situation réelle)
75/107

Tri par cartes
But :
I Construire l’architecture de l’information d’une application
I Utilisé en début de conception
I Effectuer plusieurs tris (de 3 à 10 selon convergence des
résultats et le mode)
Préparation :
I Panel représentatif d’utilisateurices
I Séance en mode individuel ou groupe
I Chaque carte = une information ou une fonctionnalité (décrite
par un ou 2 mots-clés)
76/107

Tri par cartes (2)
Procédure en 3 étapes :
I Validation des mots-clés sur les cartes (réécriture au besoin)
I Regroupement des cartes “qui se ressemblent”
I Choix d’un nom pour chaque groupe construit
Analyse des résultats :
I Repérer les groupes les plus fréquemment formés ⇒
statistiques
I 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)
77/107

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)
78/107

Questionnaires
But :
I Résumer économiquement l’avis de nombreuses utilisateurices
Procédure :
I Déterminer le public (représentatif) destinataire du
questionnaire
I Comment diffuser/récupérer
I Comment analyser les résultats
(automatiquement/manuellement)
Types de questions :
I Informations générales
I Questions ouvertes, dirigées, QCM
I Echelle, classements
79/107

Questionnaires (2)
80/107

Remue-méninges (brainstorming)
But :
I Générer un grand nombre d’idées créatives
Procédure :
I Réunir un petit groupe avec différents rôles et expertises
I Limiter le temps (1h)
I Décrire un problème de conception spécifique
81/107

Remue-méninges (2)
I Phase 1 : générer une grande quantités de solutions

I faire participer tout le monde, enregistrer toutes les idées sans
les évaluer
82/107

Remue-méninges (3)
I Phase 2 : classer les idées en fonction de leur qualité

I chacun annonce les idées qu’il préfère
I les idées sont classées par nombre de votes
I commencer la conception à partir des idées les mieux classées
I ne pas oublier les idées insolites
83/107

Conception en parallèle
But :
I Créer plusieurs interfaces et sélectionner leurs points forts
Procédure :
I Panel représentatif d’utilisateurices
I Chaque utilisateurice (ou groupe) réalise indépendamment
une interface (papier, logiciel, etc.)
I Discussion autour des interfaces réalisées
84/107
http://www.useit.com/papers/parallel_design/
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
85/107

Conception en parallèle (3)
86/107

Audit ergonomique
But :
I Evaluation rapide d’une interface par des experts en ergonomie
Procédure :
I Dans l’idéal, évaluation par plusieurs experts indépendants et
confrontation de leurs résultats
I En pratique, évaluation par un expert en ergonomie et
relecture par un expert du domaine (cf cours d’évaluation)
87/107

Audit ergonomique (2)
Avantages
Rapidité de l’audit
88/107

Avantages
Rapidité de l’audit
Inconvénients
Coût de l’audit
Aucun retour des utilisateurices finaux de l’application
88/107

89/107

En résumé
Analyse Développement Evaluation

√ √
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 ?
90/107
http://www.usability.gov
Plan du cours
Un cas concret
91/107

Définition du sujet de TD
Sujet : conception d’une application de reconnaissance de déchets

pour le tri sélectif
I Description de l’application
I Public cible
I Description du dispositif
I Liste des fonctionnalités
I Méthode(s) de conception
I Enchaînement et réalisation des maquettes
92/107

Définition du sujet de TD
Sujet : conception d’une application de reconnaissance de déchets

pour le tri sélectif
I Description de l’application
I Public cible
I Description du dispositif
I Liste des fonctionnalités
I Méthode(s) de conception
I Enchaînement et réalisation des maquettes
⇒ Voyons 3 propositions réalisées par des groupes d’étudiant-e-s
92/107

Proposition 1 : une application mobile

Description de l’application :
I 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 :
I Tout public, équipé d’une tablette avec appareil photo
Description du dispositif :
I Application mobile (tablettes) avec appareil photo 93/107

Proposition 1 : une application mobile (2)
Liste des fonctionnalités :

I Recherche d’un déchet par mot-clé ou catégorie
I Reconnaissance d’un déchet par photographie
I Géolocalisation des poubelles
I Travail collaboratif d’ajout de poubelles
94/107

Conception, première itération

I Pas d’utilisateurice ⇒ méthode des personas et scénarios
I Analyse :
I questionnaire (site Web) et résultats de sondages pour définir
des personas et des scénarios
I remue-méninges pour les idées et fonctionnalités prioritaires
I Développement des interfaces par prototypage
I En parallèle, diffusion et promotion (site Web, etc.)
I Phase d’évaluation :
I inspection cognitive (en utilisant les personas)
95/107


I 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 ».
96/107

Conception, seconde itération

I Utilisateurices attiré-e-s par l’application grâce à la promotion
⇒ méthode de conception centrée utilisateur
I Analyse :
I focus group pour comprendre les motivations des
utilisateurices
I entretiens avec les utilisateurices pour définir le modèle de la
tâche
I Développement des interfaces :
I conception en parallèle pour améliorer les faiblesses
détectées sur les interfaces
I observations de l’utilisateurice
97/107


Conception, seconde itération
Modèle de la tâche pour la proposition 1 98/107

Vidéo de démonstration de la proposition 1 99/107

Proposition 2 : une borne près des poubelles

Description de l’application :
I Un-e utilisateurice 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 :
I Les personnes qui recyclent déjà
Description du dispositif :
I Application lourde sur des bornes situées à côté des poubelles 100/107

Proposition 2 : une borne près des poubelles (2)
Liste des fonctionnalités :

I Recherche d’un déchet par mot-clé ou catégorie
I Reconnaissance d’un déchet par code barre
I Conseils et astuces de recyclage
I Menu de configuration
101/107


I Utilisateurices réels à proximté des lieux de recyclage ⇒
méthode de conception informative
I Analyse :
I questionnaires pour étayer les fonctionnalités
I scénarios de conception pour modéliser les interactions
I Développement des interfaces :
I tri par cartes pour réaliser l’enchaînement des interfaces
I magicien d’Oz par l’installation de bornes fictives
102/107


Enchaînement des écrans pour la proposition 2 103/107

Vidéo de démonstration de la proposition 2 104/107

Proposition 3 : du jeu éducatif à Big Brother ( !)
Evolution de la proposition (et des interfaces) :

I A l’origine un jeu éducatif pour apprendre
à bien trier les déchets
105/107


I Enregistrement des actions de tri (quel
déchet et dans quelle poubelle)
grâce au téléphone portable
105/107


I Ajout d’un système de récompense et
punition pour chaque personne
105/107


I Ajout d’un système de récompense et
punition pour chaque personne
I Finalement, n’importe qui est capable "d’attraper une
personne" et de savoir si elle recycle bien
105/107

Bilan
Ce qu’il faut retenir :

I Les méthodes de conception en génie logiciel sont
insuffisantes pour la conception des IHM
I Conception de l’IHM ⇒ précoce, méthodique, itérative,
expérimentale
I Pas de méthode scientifique analytique pour la conception des
IHM, mais plutôt des méthodes empiriques
I Combiner différentes méthodes de conception IHM
I Leur associer une ou plusieurs techniques de recueil
d’informations
106/107

Des questions, commentaires ?
107/107
www.projectcartoon.com

ConceptionIHM Lect1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ConceptionIHM Lect1

Transféré par

Droits d'auteur :

Formats disponibles

Conception des IHM

fabien.duchateau [at] univ-lyon1.fr

Transparents disponibles sur

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

IHM = ensemble des dispositifs matériel et logiciel permettant à

J. Nielsen, Usability engineering, Academic Press, 1993

IHM = ensemble des dispositifs matériel et logiciel permettant à

Les IHM doivent être pensées dès la phase d’analyse du logiciel !

J. Nielsen, Usability engineering, Academic Press, 1993

Les IHM ont un impact significatif sur :

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Conception en génie logiciel

Méthodes de conception IHM

Techniques de recueil d’informations

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Conception en génie logiciel

Nombreuses méthodes de conception en génie logiciel :

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Modèle classique du génie logiciel hérité du BTP (1966) :

Laurent Audibert, UML 2 : De l’apprentissage à la pratique, Ellipses, 2009

Modèle en cascade (2)

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Modèle en cascade (2)

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Modèle très populaire (1980) :

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, 12/107

Frederic Brooks, The Mythical Man-Month : Essays on Software Engineering, 12/107

Modèle par incréments

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Modèle par incréments

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Meta-modèle défini en 1986 par Barry Boehm :

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Modèle en spirale (2)

Modèle en spirale (2)

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Modèle Agile (2)

I Scrum (1995). L’équipe est soudée pour concevoir une partie

Figure: Itérations (sprints) de la méthode Scrum

Modèle Agile (3)

I Extreme Programming (1996) qui inclut de fréquents

Modèle Agile (4)

I Dynamic Systems Development Method (DSDM) est

Modèle Agile (5)

Le cycle de vie en génie logiciel concerne les IHM

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Le cycle de vie en génie logiciel concerne les IHM

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

⇒ Méthodes de conception spécifiques aux IHM

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Conception en génie logiciel

Méthodes de conception IHM

Techniques de recueil d’informations

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Méthodes de conception IHM

Différentes méthodes existantes :

Pourquoi des méthodes de conception IHM ?

Pourquoi utiliser des méthodes de conception spécifiques aux

J.F. Nogier, Ergonomie du logiciel et design Web, Dunod, 2008

LIF14 - Interactions Homme Machines // Conception des IHM UCB Lyon 1

Conception itérative (2)