LIF14 conceptionIHM

Conception des IHM
Fabien Duchateau
fabien.duchateau [at] univ-lyon1.fr
Universit Claude Bernard Lyon 1
Automne 2012
Transparents disponibles sur

http://liris.cnrs.fr/stephanie.jean-daubias/
Version originale par Stphanie Jean-Daubias
1/92
Introduction
Etapes du cycle de dveloppement dun logiciel :
I Analyse (spcifications, analyse de lexistant et
conception)
I Ralisation (programmation, bases de donnes,
tests)
I Livraison (intgration, validation, documentation)
I Maintenance (mises jour, correction de bugs)
2/92
LIF14 - Conception des IHM UCB Lyon 1

Introduction (2)
IHM = ensemble des dispositifs matriel et logiciel
permettant un-e utilisateurice dinteragir avec un
systme interactif
I Artefact concret qui sera utilis par les
utilisateurices
I Un tiers des questions lors de runions avec les
utilisateurices porte sur les IHM
I Phase de maintenance : 33% de debugging et 67%
de changements demands par les utilisateurices
3/92
J. Nielsen, Usability engineering, Academic Press, 1993
Introduction (2)
IHM = ensemble des dispositifs matriel et logiciel
permettant un-e utilisateurice dinteragir avec un
systme interactif
I Artefact concret qui sera utilis par les
utilisateurices
I Un tiers des questions lors de runions avec les
utilisateurices porte sur les IHM
I Phase de maintenance : 33% de debugging et 67%
de changements demands par les utilisateurices
Les IHM doivent tre penses ds la phase danalyse du

logiciel !
3/92
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 Cots de dveloppement, de maintenance et de

formation
4/92

Examples de bonnes/mauvaises pratiques
I Refonte des crans de saisie chez Ameritech : gain
de 600ms / appel 3 millions $ / an
I Catastrophe de lAirbus (1992) : confusion
daffichage des units sur un cadran daltimtrie
I Accident nuclaire de Three Mile Island (1979) :
absence de prise en compte de la dimension
humaine dans le processus de supervision
5/92
en.wikipedia.org/wiki/Three_Mile_Island_accident
Plan du cours
Conception en gnie logiciel
Mthodes de conception IHM
Techniques de recueil dinformations
6/92

Conception en gnie logiciel Mthodes de conception IHM Techniques de recueil dinformations
Nombreuses mthodes de conception en gnie logiciel :

Merise
Modle en cascade
Modle en V
Modle par incrments
Modle en spirale
Modle Agile
7/92

Merise
Mthode franaise pour lanalyse, la conception et la
gestion de projet
8/92
fr.wikipedia.org/wiki/Fichier:MERISE.jpg
Merise
Mthode franaise pour lanalyse, la conception et la
gestion de projet
Inconvnients
Pour des projets de grande ampleur mais souvent
internes. Inadapte aux environnements distribus.
8/92
fr.wikipedia.org/wiki/Fichier:MERISE.jpg
Modle en cascade
Modle classique du gnie logiciel hrit du BTP (1966) :

I Dfini pour de grands projets
I Importance des documents signs par les

utilisateurices
I Passage ltape suivante uniquement si ltape
prcdente est satisfaite
I Retour possible uniquement ltape prcdente
Laurent Audibert, UML 2 : De lapprentissage la pratique, El- 9/92

lipses, 2009
Modle en cascade
10/92

Modle en cascade
Inconvnients
Implication limite des utilisateurices. Evaluation lors des
deux dernires phases (effet tunnel). 10/92

Modle en V
Modle trs populaire (1980) :

I Dveloppement et tests sont effectus en parallle
I Importance des documents
I Retours possibles chaque tape mais sans

connatre leur porte
11/92

Modle en V
Frederic Brooks, The Mythical Man-Month : Essays on Software En- 12/92

gineering, Addison-Wesley, 1995
Modle en V
Inconvnients
Evaluation tardive du logiciel. Nouvelles fonctionnalits
pendant le dveloppement
Frederic Brooks, The Mythical Man-Month : Essays on Software En- 12/92

gineering, Addison-Wesley, 1995
Modle par incrments

I Construction du noyau
I Ajout progressif de fonctionnalits
4
3
2
1
noyau
13/92

Modle par incrments

I Construction du noyau
I Ajout progressif de fonctionnalits
4
3
2
1
noyau
Inconvnients
Problmes possibles pour ajouter une fonctionnalit,
voire remise en cause du noyau 13/92

Modle en spirale
Meta-modle dfini en 1986 par Barry Boehm :

I Plus gnral que le modle en V
I Itrations longues (6 mois 2 ans)
I Chaque cycle est dcoup en 4 phases

I Dterminer les objectifs, les alternatives pour les
atteindre et les contraintes
I Evaluation des alternatives, analyse des risques
I Dveloppement, validation et vrification de la
solution retenue (en utilisant un autre modle)
I Planification du cycle suivant
14/92

Modle en spirale
15/92
en.wikipedia.org/wiki/Spiral_model
Modle en spirale
Inconvnients
Etape cruciale danalyse des risques, que lutilisateurice
doit accepter
15/92
en.wikipedia.org/wiki/Spiral_model
Modle Agile
Agile regroupe plusieurs mthodes existantes
partageant des valeurs communes :
1. Dveloppement itratif et incrmental
2. Adaptation aux changements
3. Forte collaboration (interne et externe)
4. Logiciels oprationnels
16/92

Modle Agile
I Scrum (1995). Lquipe est soude pour concevoir
une partie prcise des fonctionnalits.
Lutilisateurice aide dfinir les priorits sur les
prochaines fonctionnalits dvelopper.
Figure: Itrations (sprints) de la mthode Scrum
17/92
fr.wikipedia.org/wiki/Fichier:PlanificationScrum.png
Modle Agile
I Extreme Programming (1996) qui inclut de
frquents dlivrables (cycles courts), une
programmation en binme, une intgration facilite
des changements utilisateurs.
18/92
extremeprogramming.org
Dynamic Systems Development Method

I DSDM est bas sur RAD (Rapid Application
Development, 1991)
en.wikipedia.org/wiki/DSDM 19/92
commons.wikimedia.org/wiki/File:Rad15.gif
Modle Agile
I RUP (Rational Unified Process), FDD (Feature Driven
Development), Crystal Clear, etc .
20/92
en.wikipedia.org/wiki/Software_engineering_process
Conclusion conception en gnie logiciel
Le cycle de vie en gnie logiciel concerne les IHM

Avantages
Proximit des mthodes Agile avec les mthodes de
conception IHM (implication plus forte des utilisateurices)
21/92

Le cycle de vie en gnie logiciel concerne les IHM

Avantages
Proximit des mthodes Agile avec les mthodes de
conception IHM (implication plus forte des utilisateurices)
Inconvnients
I Mthodes centres systme
I Utilisateurice impliqu-e principalement en aval et
en amont du projet (analyse et valuation)
21/92

Inconvnients
I Principe dindpendance entre le noyau fonctionnel
et linterface utilisateur :
I Interface et interaction ne sont dfinies quaprs
I Dans les logiciels interactifs, cette sparation nest
pas si nette
I Ncessit de prvoir lusage en mme temps que les
fonctionnalits
I Fonctionnalits mises en avant au dtriment des
utilisateurices
22/92

Inconvnients
I Principe dindpendance entre le noyau fonctionnel
et linterface utilisateur :
I Interface et interaction ne sont dfinies quaprs
I Dans les logiciels interactifs, cette sparation nest
pas si nette
I Ncessit de prvoir lusage en mme temps que les
fonctionnalits
I Fonctionnalits mises en avant au dtriment des
utilisateurices
Mthodes de conception spcifiques aux IHM

22/92

Plan du cours
23/92

Diffrentes mthodes existantes :

Conception itrative
Prototypage
Conception centre utilisateur
Conception participative
Conception informative
Mthode des personas
24/92
http://blog.excilys.com/2010/09/13/
Pourquoi des mthodes de conception IHM ?
Ncessit dutiliser des mthodes de conception

spcifiques aux IHM :
I Rduction des cots de dveloppement et de
maintenance du logiciel
I Rduction des risques
I Gain de productivit ct utilisateurices
I Rutilisation et amliorations des composants de

base du logiciel
I Rduction du budget et du temps pour la formation
au logiciel
25/92
J.F. Nogier, Ergonomie du logiciel et design Web, Dunod, 2008
Conception itrative
Succession de phases
I Affinements progressifs des spcifications du produit
I Evaluations des solutions retenues
I Ralisations, modifications jusqu obtention dun

produit satisfaisant
26/92

Conception itrative
Le processus de construction est itratif :
I Pour des problmes difficiles spcifier
I Processus de conception ni ascendant, ni
descendant
I Dveloppement de solutions partielles,
intermdiaires
I Apparition en cours de dveloppement de nouveaux
objectifs
I Prise en compte de lavis des utilisateurices qui
peuvent changer
I Communication au sein de lquipe de conception,
avec les utilisateurices
Difficult grer la conception itrative prototypage 27/92

Prototypage
Le prototypage permet :
I Aux concepteurices de travailler sur plusieurs
ensembles de dtails la fois
I Aux utilisateurices de voir ce que sera le systme
final
I De se concentrer sur les parties problmatiques de
linterface
I Dtudier des alternatives de conception
I De sassurer de lutilisabilit du systme
28/92

Types de prototype
Prototypes informels, sur papier

I Dessiner des crans sur papier, sur logiciel
I Utiliser des post-its / transparents / prsentations

pour des montages dynamiques
I Excuter un scnario et essayer des variantes pour
des choix
I de haut niveau : dcider des fonctionnalits qui
seront disponibles
I de niveau intermdiaire : dessiner une squence
dcrans
I de bas niveau : dessiner des ides dicnes
29/92

Types de prototype (2)
Example de prototype papier pour une application

tlphone
30/92
http://www.youtube.com/watch?v=YQsHwooTP5E

Prototypes vido
I Crer une vido de lutilisation dun prototype
I Simuler les fonctionnalits non implantes, les
interactions
Prototypes informatiques laide doutils :
I Accs direct linterface : Visual Basic, Delphi
I Assistance au prototypage : Visual C, Tcl-Tk, Pencil
31/92
http://pencil.evolus.vn/
Dun prototype papier aux prototypes logiciel

32/92
https://wiki.ubuntu.com/SoftwareStore
Conception centre utilisateur

Trois phases :
I Analyse (identification des fonctionnalits ou
services, i.e., lutilit recherche par les
utilisateurices de lapplication)
I Conception (construction de la structure des menus
et dcoupage en fentres / pages Web)
I Evaluation (raffinement progressif du prototype)
33/92

Conception centre utilisateur (2)

Prise en compte des utilisateurices :
I Ds la phase danalyse
I Etude de lutilisateurice et de sa tche
Ncessit de spcifier les caractristiques :

I De lutilisateurice
I De la tche raliser
I De linteraction
Relations concepteurice - utilisateurice :

I Utilisateurice observ-e dans la rsolution de sa
tche
I Interrog-e sur ses attentes
I Questionn-e sur le logiciel conu 34/92

Conception centre utilisateur (3)

Avantages :
I Prise en compte de lutilisateurice avant la phase
dvaluation
Difficults :
I Choisir des utilisateurices reprsentatifs et
disponibles
I Ne pas oublier le contexte rel dutilisation
I Expliciter les comportements, les connaissances

mises en jeu...
Techniques de recueil dinformations associes

Observation directe, entretiens, questionnaires
35/92

Modle de lutilisateur
Identifier les caractristiques pertinentes de

lutilisateurice
I Donnes gnrales
I taille, ge, sexe, dficiences
I niveau de formation, habitudes culturelles
I Donnes lies lapplication : comptences sur le
domaine/en informatique
I dbutant, occasionnel, expriment, expert
36/92

Modle de la tche
Mthode :
I Construire la hirarchie de tches du systme
I Spcifier chaque tche, penser aux exceptions
I Evaluer la dcomposition avec lutilisateurice
Dfinitions :
I Tche
I but = ce qui doit tre fait
I procdure = un ensemble de sous-tches relies par
des relations de composition ou des relations
temporelles
I Tche lmentaire
I tche dcomposable uniquement en actions
physiques oprations dE/S 37/92

Modle de la tche (2)
Figure: Modle de tche pour lactivit envoyer un sms 38/92

Modle de linteraction
tablir une correspondance directe entre :

I Les objets conceptuels informatiques (e.g., un fichier)
I Les objets dinteraction et de prsentation

I les reprsentations du fichier lcran (ferm,
ouvert)
I les oprations sur le fichier (modification,
suppression, etc.)
Cette correspondance doit :
I Apparatre comme "naturelle"
I Sinscrire dans une cohrence densemble : la

mtaphore
39/92

Modle de linteraction (2)

Mtaphore : utilisation de concepts connus de
lutilisateurice
I Facilite lapprentissage
I Lutilisateurice anticipe le comportement du systme
Examples de mtaphore du monde rel :

I Spatiales (bureau, maison, etc.)
I Sociales ou techniques (imprimante, courrier, etc.)
40/92

I Pas seulement comme testeurs
I Mais aussi comme partenaires de conception :

I Tches essentiellement connues des utilisateurices
I Source possible dinnovations
Relations concepteurice-utilisateurice :
I Utilisateurice partenaire de conception part entire
I Et participe aux choix de conception finaux
Techniques de recueil dinformations associes

Scnarios, magicien dOz, inspections cognitives,
brainstorming, prototypes 41/92

Avantages
I Seules les utilisateurices connaissent la ralit des
tches
I Indispensable pour les activits mal identifies ou
peu structures
I Facilite lacceptation du logiciel
42/92

Avantages
I Seules les utilisateurices connaissent la ralit des
tches
I Indispensable pour les activits mal identifies ou
peu structures
I Facilite lacceptation du logiciel
Inconvnients
I Augmentation des cots de dveloppement
I Contradictions possibles entre les utilisateurices
participant-e-s et les autres
I Obligation daccepter des compromis pour satisfaire
des participant-e-s, mme sils/elles ont tort 42/92

Conception informative

I Pas seulement comme testeurs
I Mais sans les considrer comme partenaires de

conception
I Mthode imagine pour la conception avec des
enfants
Relations concepteurice-utilisateurice :
I Utilisateurice dans lquipe de conception
I Mais ne participe pas aux choix finaux
43/92

Mthode des personas et scenarios

Mthode des personas :
I Utilise dans diffrents domaines (plans marketing,
sondages, etc.)
I Introduite aux dbuts des annes 1990 pour la
conception dIHM
Objectifs de la mthode :
I Meilleure comprhension des utilisateurices et de
leurs buts
I Vision partage des utilisateurices
I Cration de scnarios partir des personas
44/92

Mthode des personas et scenarios (2)
Dfinition du persona (ou archtype) :

I Pas un-e utilisateurice rel-le, mais une abstraction
de plusieurs
I Regroupe les traits caractristiques les plus
frquents des utilisateurices
La description dun persona peut inclure :
I Des objectifs, contraintes, environnement de travail
I Ce qui va dclencher leurs actions
I Ce qui peut les influencer
I Ce qui peut les freiner ou les faire fuir
45/92


I Un prnom
I Un titre
I Une photo
I Une devise (par rapport lapplication)
I Une description, ducation, background social
46/92


I Un prnom
I Un titre
I Une photo
I Une devise (par rapport lapplication)
I Une description, ducation, background social
Eviter les super-personas et les strotypes !
46/92

Exemples de personas 47/92

Exemples de personas 47/92


Un scenario est une sorte dhistoire avec :
I Un persona
I Un environnement
I Un but (que le persona doit accomplir)
I Des obstacles
Excution dun scnario orientation pour les choix de

fonctionnalits, interactions, interfaces (et plus tard
valuation de linterface ralise)
http://www.karizmatic.fr/humaniser-lutilisateur/ 48/92
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 lajout de musiques dans le mme genre musical.
49/92

Avantages
I Empathie cognitive (comprendre les tats ou
croyances dune autre personne)
I Applicable au Web / large chelle
Inconvnients
I Mauvaise dfinition des personas chec
I Distance par rapport aux utilisateurices rel-les
I Besoin de modifier les personas en cas de nouveaux
rsultats ou denvironnement diffrent
50/92

Conclusion mthodes de conception IHM
Garder les points forts des diffrentes mthodes :

I Prise en compte prcoce de lutilisateurice ds la
conception
I Prise en compte prcoce de lvaluation ds la
conception
utilisateurice
utilisateurice
conception
conception valuation
valuation
51/92

Conclusion mthodes de conception IHM (2)
Comme lutilisateurice est au centre de ces mthodes,

besoin de techniques pour recueillir les informations
52/92

Plan du cours
53/92


La plupart des mthodes de conception pour IHM
ncessitent de collecter des informations sur les
utilisateurices
Techniques de recueil dinformations possibles :
Scnarios de conception
Inspections cognitives
Magicien dOz
Enqute / entretiens
Observations
Focus group
Tri par cartes
Questionnaires
Remue-mninges (brainstorming)
54/92
Audit ergonomique
But :
I Crer une description raliste de lutilisation du
nouveau systme
Moyen :
I Utiliser les scnarimages (storyboards) du monde du
cinma
I Points cls, commentaires, enchanements
I Pour une vue densemble de linteraction
55/92

Scnarios de conception (2)
Procdure :
I Identifier des activits existantes
I typiques
I inhabituelles
I Crer des scnarios de travail en gnralisant les
histoires
I mlanger les vnements de diffrentes provenances
I incorporer des situations inhabituelles dans des
activits typiques
I inclure des situations qui aboutissent et dautres pas
http://grouplab.cpsc.ucalgary.ca/saul/681/1998/ 56/92
prototyping/survey.html
Figure: Modle pour crire un scnarimage
57/92
http://fr.wikipedia.org/wiki/Storyboard
Example de scenarimage 58/92

Inspections cognitives (cognitive

walkthroughs)
But :
I Evaluer le systme soit par lutilisateurice soit en se
mettant sa place
Moyen :
I Spcification dune srie de tches et des squences
dactions pour les raliser
Procdure :
I Evaluation en imaginant ce que ferait lutilisateur
I comprend-il les messages, le comportement du
systme ?
I Interprtation et prise en compte des rsultats 59/92

Inspections cognitives (2)
Example dinspection cognitive pour lutilisabilit

diTunes
60/92
http://www.youtube.com/watch?v=Ro77wQq0sWo
Magicien dOz
But :
I Simuler les fonctionnalits absentes du systme
I Systme rel inexistant ou partiellement dvelopp
I Technique difficile mettre en place : adapt des
systmes lourds, difficile dvelopper
Moyen :
I Un compre effectue les actions la place du
systme
61/92

Magicien dOz (2)
Procdure :
I Le magicien interprte les entres de
lutilisateurice
I Il supple aux manques du prototype et contrle le
comportement du systme
I Sensation dutiliser un vrai systme
De moins en moins utilis cause des logiciels de

protypage dinterface
62/92
http://fr.wikipedia.org/wiki/Le_Magicien_d%27Oz
Magicien dOz (3)
Example : projet DIALORS, un systme de dialogue pour

rserver un billet de train en langage naturel
Exprimentations relles en 1984 : une opratrice simule

les rponses du systme
Un des points mis en avant : face la machine, les

utilisateurices ont adopt - contrairement aux attentes
des concepteurices - un langage hach simplification
du modle pour le langage naturel
http://www-lium.univ-lemans.fr/~luzzati/recherches/ 63/92
historique_files/DVHM%20luzzati.pdf
Enqute / entretiens
But :
I Identifier des pistes de conception
pour les prochaines itrations
ou des exemples spcifiques
de problmes rencontrs par
les utilisateurices
Caractristiques :
I Interviewer lutilisateur dans son environnement de
travail (face face)
I Dure recommande de 45 minutes / une heure
I Privilgier le magntophone la prise de notes

(traces et concentration sur lchange)
64/92

Enqute / entretiens (2)

Procdure :
I Rassembler un panel reprsentatif dutilisateurices
I Pendant linterview en face face :

I questions semi-directives pour lanalyse (degr de
libert)
I questions plutt directives pour lvaluation (cibler
un lment)
I neutralit de lenquteurice
I reformulation des rponses
I Analyse des rsultats
fr.wikibooks.org/wiki/Outils_mthodologiques_ 65/92
(sociologie)
Possibilit dutiliser les entretiens pour des incidents

critiques :
I Dtcter les points forts et points faibles dun
systme
I Demander de se souvenir dun problme particulier
vcu dans un pass rcent
I Demander de dcrire chaque incident en dtail
I Demander ce qui est habituel et ce qui ne lest pas

dans lincident
66/92

Avantages
Analyse qualitative
Identification des tendances et des priorits, ou dans le
cas dentretiens critiques, des points forts ( renforcer) et
des points faibles ( corriger)
67/92

Avantages
Analyse qualitative
Identification des tendances et des priorits, ou dans le
cas dentretiens critiques, des points forts ( renforcer) et
des points faibles ( corriger)
Inconvnients
Vision subjective (ne pas en tirer des conclusions
chiffres)
67/92

Observations
But :
I Identifier les gros problmes du logiciel (prototype /
systme final)
Procdure :
I En laboratoire ou sur le terrain
I Choisir au moins 2 utilisateurs qui agiront
indpendamment
68/92

Observations (2)
I Dfinir une mission spcifique (rsoudre un

problme, suivre un scnario)
I Dcider de ce que lon veut mesurer
I Demander aux utilisateurs deffectuer la tche
(mthode 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, vido, trace informatique
69/92

Observations : analyse de protocole
Traces papier :
I Cot de traitement
acceptable
I Un seul point de vue,
car pr-analys
70/92

Observations : analyse de protocole (2)

Enregistrements vido (ou audio) :
I Voir le visage, la posture de lutilisateurice
I Voir lcran
Oculomtrie (eye tracking)
71/92


Enregistrements vido (ou audio) :
I Voir le visage, la posture de lutilisateurice
I Voir lcran
Oculomtrie (eye tracking)
Permet de corriger certains biais des protocoles verbaux
Trs long et coteux dpouiller 71/92


Traces informatiques :
I mmorisation de (toutes) les actions de
lutilisateurice
I permet de rejouer la session
I objectif : dpouillement automatiquement
I lanalyse doit tre prvue avant
TRACE PRODUCTIO
13:13:42 Dbut 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 Reprsentation JEAN-
graphique DAUBIAS
13:14:55 Trac libre Stphanie
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 Dsactiver 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] 72/92
13:16:41 Coller : x-2y=-6 0010000000
13:17:52 Enregistrement (a+3)(b+a)
LIF14 -13:17:54 Fin
Conception des IHM [FIN] UCB Lyon 1
Focus group
But :
I Comprendre les motivations des utilisateurices
I En groupe, et donc bnfice de la dynamique de

groupe
I Sance filme, paperboards, et/ou assistant-e-s
73/92

Focus group (2)
Procdure :
I Dfinir diffrents thmes aborder (5 ou 6
recommands)
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 rgles respecter
I exercices de difficult croissante, et portant sur des
points de plus en plus prcis du systme
I synthse des rsultats et discussions
74/92

Focus group (3)
Avantages
Vision globale sur le systme en terme de motivations,
prfrences, priorits, attentes voire conflits.
Sances enrichies par les interactions et par la
rutilisation des rsultats des sances prcdentes.
Emergence dides nouvelles
75/92

Focus group (3)
Avantages
Vision globale sur le systme en terme de motivations,
prfrences, priorits, attentes voire conflits.
Sances enrichies par les interactions et par la
rutilisation des rsultats des sances prcdentes.
Emergence dides nouvelles
Inconvnients
Eviter pour lvaluation (utilisateurices pas en situation
relle)
75/92

Tri par cartes
But :
I Construire larchitecture de linformation dune
application
I Utilis en dbut de conception
I Effectuer plusieurs tris (de 3 10 selon convergence

des rsultats et le mode)
Prparation :
I Panel reprsentatif dutilisateurices
I Sance en mode individuel ou groupe
I Chaque carte = une information ou une

fonctionnalit (dcrite par un ou 2 mots-cls)
76/92

Tri par cartes (2)

Procdure en 3 tapes :
I Validation des mots-cls sur les cartes (rcriture au
besoin)
I Regroupement des cartes qui se ressemblent
I Choix dun nom pour chaque groupe construit
Analyse des rsultats :

I Reprer les groupes les plus frquemment forms
statistiques
I Analyse qualitative base sur les observations lors
des sances
Possibilit de tri ferm (groupes dj dfinis et les
participant-e-s y rangent les cartes) 77/92

Tri par cartes (3)

Avantages
Garantie de trouver ce que lon cherche (organisation
du contenu)
Peu de problmes de navigation entre les fentres /
pages
Combiner le tri ferm puis tri ouvert en cas de nombre de
cartes important (> 100)
78/92

Questionnaires
But :
I Rsumer conomiquement lavis de nombreux
utilisateurs
Procdure :
I Dterminer le public (reprsentatif) destinataire du
questionnaire
I Comment diffuser/rcuprer
I Comment analyser les rsultats

(automatiquement/manuellement)
Types de questions :
I Informations gnrales
I Questions ouvertes, diriges, QCM
I Echelle, classements 79/92

Questionnaires (2)
80/92

Remue-mninges (brainstorming)
But :
I Gnrer un grand nombre dides cratives
Procdure :
I Runir un petit groupe avec diffrents rles et
expertises
I Limiter le temps (1h)
I Dcrire un problme de conception spcifique
81/92

Remue-mninges (2)
I Phase 1 : gnrer une grande quantits de solutions

I faire participer tout le monde, enregistrer toutes les
ides sans les valuer
82/92

Remue-mninges (3)
I Phase 2 : classer les ides en fonction de leur qualit
I chacun annonce les ides quil prfre
I les ides sont classes par nombre de votes
I commencer la conception partir des ides les
mieux classes
I ne pas oublier les ides insolites
83/92

Audit ergonomique
But :
I Evaluation rapide dune interface par des experts en
ergonomie
Procdure :
I Dans lidal, valuation par plusieurs experts
indpendants et confrontation de leurs rsultats
I En pratique, valuation par un expert en ergonomie
et relecture par un expert du domaine (cf cours
dvaluation)
84/92

Audit ergonomique (2)
Avantages
Rapidit de laudit
Pistes pour prioritiser les tapes suivantes de conception
85/92

Avantages
Rapidit de laudit
Inconvnients
Cot de laudit
Aucun retour des utilisateurices finaux de lapplication
85/92

86/92

Conception en parallle
But :
I Crer plusieurs interfaces et slectionner leurs
points forts
Procdure :
I Panel reprsentatif dutilisateurices
I Chaque utilisateurice (ou groupe) ralise

indpendamment une interface (papier, logiciel, etc.)
I Discussion autour des interfaces ralises
87/92
http://www.useit.com/papers/parallel_design/
Conception en parallle (2)
Avantages
Les meilleures ides mergeant de la session sont
gardes
88/92

Conception en parallle (3)
89/92

Conclusion techniques recueil dinformation

Analyse
Conception
Evaluation
Inspections cognitives
Magicien dOz
Enqutes / entretiens
Observations
Questionnaire
Remue-mninges
Focus group
Tri par cartes
Audit ergonomique
Conception en parallle
Quand utiliser quelle technique ?
90/92
http://www.usability.gov
Bilan
Ce quil faut retenir :

I Les mthodes de conception en gnie logiciel sont
insuffisantes pour la conception des IHM
I Conception de lIHM prcoce, mthodique,
itrative, exprimentale
I Pas de mthode scientifique analytique pour la
conception des IHM, mais plutt des mthodes
empiriques
I Combiner diffrentes mthodes de conception IHM
I Leur associer une ou plusieurs techniques de recueil

dinformations
91/92

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

LIF14 conceptionIHM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LIF14 conceptionIHM

Uploaded by

Copyright:

Available Formats

Conception des IHM

Transparents disponibles sur

LIF14 - Conception des IHM UCB Lyon 1

Les IHM doivent tre penses ds la phase danalyse du

I Cots de dveloppement, de maintenance et de

LIF14 - Conception des IHM UCB Lyon 1

Conception en gnie logiciel

Mthodes de conception IHM

Techniques de recueil dinformations

LIF14 - Conception des IHM UCB Lyon 1

Conception en gnie logiciel

Nombreuses mthodes de conception en gnie logiciel :

LIF14 - Conception des IHM UCB Lyon 1

Modle classique du gnie logiciel hrit du BTP (1966) :

I Importance des documents signs par les

Laurent Audibert, UML 2 : De lapprentissage la pratique, El- 9/92

LIF14 - Conception des IHM UCB Lyon 1

LIF14 - Conception des IHM UCB Lyon 1

Modle trs populaire (1980) :

I Importance des documents

I Retours possibles chaque tape mais sans

LIF14 - Conception des IHM UCB Lyon 1

Frederic Brooks, The Mythical Man-Month : Essays on Software En- 12/92

Frederic Brooks, The Mythical Man-Month : Essays on Software En- 12/92

Modle par incrments

LIF14 - Conception des IHM UCB Lyon 1

Modle par incrments

LIF14 - Conception des IHM UCB Lyon 1

Meta-modle dfini en 1986 par Barry Boehm :

I Itrations longues (6 mois 2 ans)

I Chaque cycle est dcoup en 4 phases

LIF14 - Conception des IHM UCB Lyon 1

LIF14 - Conception des IHM UCB Lyon 1

Figure: Itrations (sprints) de la mthode Scrum

Dynamic Systems Development Method

Conclusion conception en gnie logiciel

Le cycle de vie en gnie logiciel concerne les IHM

LIF14 - Conception des IHM UCB Lyon 1

Conclusion conception en gnie logiciel

Le cycle de vie en gnie logiciel concerne les IHM

LIF14 - Conception des IHM UCB Lyon 1

Conclusion conception en gnie logiciel

LIF14 - Conception des IHM UCB Lyon 1

Conclusion conception en gnie logiciel

Mthodes de conception spcifiques aux IHM

LIF14 - Conception des IHM UCB Lyon 1

Conception en gnie logiciel

Mthodes de conception IHM

Techniques de recueil dinformations

LIF14 - Conception des IHM UCB Lyon 1

Mthodes de conception IHM

Diffrentes mthodes existantes :

Pourquoi des mthodes de conception IHM ?

Ncessit dutiliser des mthodes de conception

I Gain de productivit ct utilisateurices

I Rutilisation et amliorations des composants de

I Evaluations des solutions retenues

I Ralisations, modifications jusqu obtention dun

LIF14 - Conception des IHM UCB Lyon 1

LIF14 - Conception des IHM UCB Lyon 1

I De sassurer de lutilisabilit du systme

LIF14 - Conception des IHM UCB Lyon 1

Prototypes informels, sur papier