Transcript IHMs centrées Utilisateurs

Présenté par :
Kenza HARKOUKEN SAIAH
19/03/2010
1


Introduction
Conception participative

Observation et analyse





Génération d’idées




Scénarios de conception
Prototypages
Evaluation



Scénario de travail
Brainstorming
Conception détaillée


Introspection
Observation directe
Questionnaires
Interviews : préparation de l’interview
Design Walkthrough
Tests d’utilisabilité
Conclusion
19/03/2010
2
Modèles de conception :
 Souvent centrés systèmes
 L’utilisateur n’intervient qu’en amont et en aval
de la conception (analyse et évaluation)
Modèle en cascade
Modèle en V
19/03/2010
Modèle en spiral
3

Problème de l’industrie du logiciel

84% d’échecs (temps, fonctionnalités, budgets)


63% d’excès de budgets


Manque d’intervention des utilisateurs, spécification
incomplète, changements par les utilisateurs.
Demande fréquente de changements par les utilisateurs ,
taches trop grandes, manque de compréhension des
propres requis des utilisateurs, mauvaise communication
entre les utilisateurs et les concepteurs
Maintenance : 33% debugging, 67% changement par
l’utilisateur.
40 à 100 fois plus cher de changer l’interface
plutôt que de bien la concevoir pendant la
conception.
19/03/2010
4
Méthode de conception
participative
 L’utilisateur intervient dans toutes
les phases de conception




Permet:




Analyse, conception, évaluation,
walkthrough
Processus itératif
Redéfinition et résolution des
problèmes
Comprendre l’intéraction dans un
contexte réel
Intégrer le contexte dans le système
L’ingénieur et la direction ne sont
plus les seuls concepteurs
19/03/2010
5
Quatre phases :
 Découverte :

qui est l’utilisateur ?
 Invention

:
qu’est-ce qui est possible ?
 Conception

qu’est-ce qu’on fait ?
 Evaluation

:
:
est-ce que ça marche ?
19/03/2010
6
 POURQUOI?
 Comprendre


A priori, on ne connait pas le domaine
Si on le connait, il faut se méfier de ce qu’on
connait
 Répondre


la pratique du travail
à
Pourquoi on me demande de concevoir un
nouveau système?
À quel problème vais-je m’attaquer?
 Redéfinir/mieux
définir/cerner le problème
 Observer l’usage imprévu !! (incident
critique)
19/03/2010
7


Pourquoi ?
Point de vue scientifique



collecter des données
analyser les données
informer les designers


Point de vue du design

inspirer des idées
refléter les activités quotidiennes
 remettre le problème en question

Point de vue de l’ingénierie

s’assurer que ça marche “in situ”
19/03/2010
8
Observation des utilisateurs
 Peuvent être subjectives :

on ne peut pas complètement supprimer le biais
de l'observateur
 Techniques





:
Observation directe
Introspection
Protocole à haute voix
Questionnaires
Interviews
19/03/2010
9
 Le

Est-ce que le système lui convient ?
 Ce




concepteur essaie le système
que l'on peut faire systématiquement :
Commencer avec une vraie tâche
Choisir un temps limité
S’assurer qu’on ne sera pas interrompu
Parler ou écrire pendant que vous travaillez
 Analyser



ce que vous avez observé :
Interactions positives et négatives
Surprises
Idées pour améliorer l’interaction
19/03/2010
10
L’introspection est beaucoup utiliser
mais c’est le plus susceptible d'erreurs

C’est une méthode de design, mais pas une
méthode scientifique
Si vous le faites,
 suivre un protocol (design Walkthrough,
évaluation heuristique ex: Critère de Scapin &
Bastien)
 n’oublier pas que vos opinions et expériences
sont rarement les même que vos utilisateurs
19/03/2010
11

BUT :

Observer et enregistrer les utilisateurs se servant du
système avec un dispositif vidéo ou sans (papiercrayon)!
En laboratoire ou sur le terrain
 Important pour identifier les gros problèmes
 Inconvénients :





Avantages :


méthode intrusive,
prend du temps,
à négocier avec les utilisateurs
permet de voir ce que les gens font et non ce qu’ils
disent (ou ce qu’on dit) qu’ils font
Utilisée en conception et en évaluation
19/03/2010
12

Avec verbalisation simultanée
on demande à l’opérateur de penser à haute voix!
 Avantages : la situation de travail est éclairée sur
l’instant!
 Inconvénients : place les utilisateurs en situation de
double tâche (plus complexe)!


Avec verbalisation consécutive
Dans un environnement sonore bruyant, dans le cas
de tâche automatisée, déplacement continu!
 Impose la vidéo (auto-confrontation) ou un relevé
papier crayon minutieux!
 Auto-confrontation peut-être collective ou croisée

19/03/2010
13
Procédure (Etude d’utilisabilité)
 Utiliser au moins 2 observateurs pour
enregistrer les comportements
 Définir une mission spécifique, résoudre un
problème, dérouler un scénario
 Choisir les utilisateurs parmi le public visé
 Choisir le cadre de l’étude (laboratoire ou
terrain)
 Décider ce que l’on veut mesurer (ex: temps
d’exécution, taux d’erreurs)
 Combiner avec des interviews et des
questionnaires
19/03/2010
14
 Enregistrement



:
Papier: bon marché, peu de détails, incomplet
Audio: parfois utile, difficile à analyser
Vidéo: le plus détaillé, intrusif ?, difficile à
analyser, analyse rétrospective
 Actions
sur le clavier et la souris
 Codage
 Définir
des catégories
 Evénements discrets ou continus
 Mesurer le degré de concordance
19/03/2010
15
But
 Résumé utile des avis de nombreux utilisateurs
Suppositions
 Les utilisateurs répondent honnêtement
 Les questions concernent le phénomène auquel
on s'intéresse
19/03/2010
16
Objectifs






Identification des caractéristiques des utilisateurs (âge,
expérience, sexe, formation…)!
Estimation subjective du niveau de charge de travail!
Identification des attentes, des besoins des préférences!
Recherche des habitudes et des préférences!
Evaluation subjective de l’utilisabilité et de la satisfaction
de l’existant ou du produit conçu (cf. techniques
d’évaluation)
Avantages :
Très utiles pour avoir des informations quantitatives!
 Des retours d’utilisation (formulaires sur un site)!


Inconvénients :

Connaissances déclaratives
19/03/2010
17
Concevoir un questionnaire
 Quelle information recherchez-vous ?
 Demander seulement ce qui est pertinent
 Poser des questions appropriées
 Qui est le public ? 50 - 1000 personnes
 Comment l'envoyer et le récupérer ? En ligne ?
Par courrier ?
 Comment analyser les résultats ?
 Les questions déterminent les statistiques
19/03/2010
18
Styles de questions
 Background :


Informations générales :


Depuis combien d'années utilisez-vous le courrier
électronique ?
Questions dirigées :


Quel est votre âge ?
Combien de messages avez-vous reçu aujourd'hui ?
Choix multiple :

J'utilise la fonction de destruction de message
o souvent
o parfois
o rarement
19/03/2010
o jamais
19
Styles de questions
 Scalaire :


Pas d'accord
-2
-1
Classement :


Je peux facilement gérer mon courrier
0
D'accord
1
2
Classer les fonctions suivantes par ordre d'utilité :
_ Copie aveugle
_ Copie automatique à une liste de distribution
_ Copie automatique à moi-même
Questions ouvertes :

Décrivez comment vous utiliser le courrier électronique ?
19/03/2010
20
Principes de conception des questions






Structure parallèle des phrases
Ordre cohérent : positif vers négatif
Zéro est soit une réponse moyenne soit "je ne sais pas"
Penser à ajouter un degré de confiance
Poser plusieurs fois la même question de façon différente
pour comparer les résultats
Eviter les réponses prévisibles
19/03/2010
21
N’oubliez pas

Les questions dirigées et spécifiques :




sont plus facile à coder
bien au début d’un questionnaire
donne moins de détails intéressant
Questions générales et ouvertes :



sont très difficile à coder
peuvent donner les réponses très intéressant
Risque de donner les réponses stéreotypiques
19/03/2010
22
Objectifs






Constitution d’un glossaire des termes des utilisateurs!
Création de répertoires de raisonnement!
Détermination des processus cognitifs qui régissent les
activités!
Définition des enchaînements logiques des actions de
l’utilisateur!
Recensement des besoins!
Enrichissement des données recueillies
Suppositions
 Les opinions sont subjectives
 Les utilisateurs rationalisent souvent les événements
19/03/2010
23
Concevoir un interview
Allez du spécifique
à l’ouvert

Allez du dirigée
à l’ouverte

19/03/2010
24
Concevoir un interview

Questions spécifique et dirigées :



Questions spécifique et ouvertes :




Mêmes questions, même format pour tout le monde
Ajouter des questions et re-interroger les sujets
e.g., Technique de l'incident critique
Interroger à propos d'un événement marquant récent (la semaine
dernière)
Généraliser à partir d'un cas particulier
Questions générales et ouvertes :

Permettre aux utilisateurs d'expliquer ce qu'ils font à leur manière
19/03/2010
25
Questions spécifique et ouvertes
 Variantes : Aider l’utilisateur de reconstruire la mémoire

Technique de l'incident critique


Heure spécifiée par l’interviewer


Qu’est-ce qui c’est passé à ce moment précis
<heure, date, endroit spécifique> ?
Object spécifique


Raconter un événement récent et mémorable
Décrire la dernière fois que vous avez utiliser
<cet objet-là>.
Situation spécifique

Raconter qu’est-ce qui c’est passé la dernière fois que vous étiez
dans <situation spécifique>
19/03/2010
26
Exemple Information Lens




Filtrage du courrier électronique
Etude de 2 ans à Xerox PARC
Les utilisateurs ont changé leur façon de gérer le courrier
Les utilisateurs ont changé le modèle des concepteurs du
système
19/03/2010
27
Questions spécifique et dirigées
1. Combien de messages avez-vous reçu aujourd'hui ?
2. Est-ce une journée typique ? sinon expliquez pourquoi.
3. Vous lisez votre courrier tous les combien ?
4. Lisez-vous tout votre courrier ? sinon, expliquer pourquoi.
5. Quel est le pourcentage de messages que vous voudriez
n'avoir jamais vu ?
6. Combien de règles de filtrage avez-vous ?
7. Est-ce que l'une d'elles a été utilisée quand vous avez lu
votre courrier ce matin ?
19/03/2010
28
Technique de l'incident critique
1. Vous souvenez-vous avoir, la semaine dernière, cherché un
ancien message ?
Décrivez ce que vous avez fait pour le trouver.
2. Vous souvenez-vous avoir eu besoin, la semaine dernière,
d'une information technique ?
Décrivez ce que vous avez fait pour la trouver.
3. Vous souvenez-vous si, la semaine dernière, l'une de vos
règles de filtrage n'a pas fonctionné comme vous vous y
attendiez ?
Qu'avez-vous fait ?
19/03/2010
29
Questions ouvertes
1. Décrivez comment vous utilisez la messagerie.
2. Décrivez comment vous classez vos messages.
3. Quand préférez vous utiliser le courrier électronique ? le
téléphone ? une conversation face-à-face ?
4. L'utilisation de Information Lens a-t-il changé la façon dont
vous communiquez avec vos collègues ?
19/03/2010
30
L’ordre est-il important !!!

Questions spécifiques
avant les questions générales

Questions dirigées
avant les questions ouvertes

Pourquoi ?
La forme de la question influence beaucoup le style de la
réponse
19/03/2010
31
Synthèse


Multiplier les perspectives!
Croiser les informations!





Étude des documents de formation, consignes etc.!
Entretiens, Observations, Enquêtes!
Croiser les interprétations!
Faites parler les gens, ET les regarder faire!
Synthétiser les données!


Analyse de tâches!
Scénarios de travail
19/03/2010
32
Pourquoi?
 Trop souvent on développe un solution
« évidente »
 La phase d’exploration des solutions est
inexistante (en générale l’informaticien fait
des choix pour tout le monde)
But :
 Trouver des solutions aux problèmes soulevés
dans l’analyse
 Élargir l’espace de design !
19/03/2010
33
Techniques de conception
Phase de production et d’évaluation des solutions
de conception!
 La conception est itérative!
 La conception est un processus collectif!
Concepteurs de différents métiers (informaticiens,
graphistes, fiabiliste, télécom…)!
 Utilisateurs!
 Ergonomes!
 Client, décideurs (maître d#ouvrage)!


La conception est outillée par des techniques de
réunions et de matérialisation des solutions de
conception
19/03/2010
34
But

Description réaliste d’une suite d’événements possibles réalisés
par les utilisateurs

Forme :


histoire, « story board », video, tableau, description formelle!
Catégories :
scénarios d’utilisation décrivent l’utilisation d’un système existant!
 scénarios de conception (ou de travail) imaginent l’utilisation de
systèmes futurs


Pourquoi utiliser des scénarios ?

Pour stimuler l’imagination et la créativité, susciter des
questionnements (« et si ? »), pour un design pertinent pour de vrais
utilisateurs dans un vrai contexte, pour pallier aux insuffisances et à la
rigidité des analyses hiérarchiques
19/03/2010
35
Principes :





Descriptions concrètes
Accent mis sur des exemples particuliers (pas génériques)!
Dirigé par le travail (pas par la technologie)!
Ouvert, fragmentaire (ni complet, ni exhaustif)!
Informel, brut, familier!
En pratique :
 Création d’un ou plusieurs personnages
Buts, attentes, motivations!
 Qui ? Age, sexe, éducation, expérience en informatique et sur
internet!
 Contexte Quand ? Où ? Sur quel ordinateur ? Taille de l’écran ? Sur
quel navigateur ? Quelle connexion ?


Raconter une histoire dans un intervalle de temps donné;
inclure des événements courants ou moins et des incidents
en s’inspirant des données récoltées [Carroll, 1997]
19/03/2010
36
Procédure :
 À partir des observations ( incidents critiques,
activités habituelles, …)
 Choisir un jour précis et un utilisateur
imaginaire
 Développer un scénario ou une description
détaillée de l’utilisateur au travail
 Inclure des situations:



Habituelles et inhabituelles
Planifiées et non planifiées
Qui aboutissent et qui n’aboutissent pas.
19/03/2010
37
But :

Générer le plus grand nombre possible d'idées créatives en
un minimum de temps (20min à 1h)
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
Générer autant d'idées que possible et les lister au tableau
ou au rétroprojecteur
Sélectionner les meilleures idées
Peut intervenir à différentes phases
Idées de conception
 Dessin des écrans
 Evaluation

19/03/2010
38
Quelques règles
 Phase 1
Générer une grande quantités d'idées
Faire participer tout le monde
Enregistrer toutes les idées
 Ne pas évaluer les idées




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




19/03/2010
39
Problème

Complexité des spécifications techniques
 Problèmes ouverts et difficiles à spécifier
 Communication au sein de l'équipe, avec les utilisateurs,
les clients!
But :



Chercher ensemble (utilisateurs, concepteurs) la forme du
nouveau système
Faire les bons choix, et qui correspondent aux problèmes
relevés
Pouvoir tester, rapidement et à moindre coût une version
du nouveau système
19/03/2010
40
Différents des scénarios de travail)
But :

Créer une description réaliste de l’utilisation du nouveau système.
Procédure :

Prendre un scénario de travail existant

Utiliser les idées générées pendant le brainstorming

Modifier le scénario de travail pour inclure le nouveau système

Faire un storyboard avec texte et images
19/03/2010
41
But :
 Créer l’illusion d’une interaction réelle entre les utilisateurs et le
nouveau système.
Intérêt des maquettes et prototypes:
 étudier des alternatives de conception
 s'assurer de l'utilisabilité dans différentes conditions
 aider les concepteurs, les utilisateurs (ou les clients) à imaginer
l'interface
 se concentrer sur les parties problématiques de l'interface
 se concentrer sur des détails qui font qu'un système bon en
théorie est inutilisable
 En pratique Garder trace des évaluations de solutions et du
«pourquoi?» une solution a été ou non retenue (logique de
conception)
 Inconvénients contraintes de temps et d'argent perturbent ce
cycle idéal
19/03/2010
42
Matériel :




Papier, crayons, post-it, transparents …
tableaux de papier
logiciels de présentation
générateurs d'interface
Intérêt :



phases initiales de la conception (analyse des besoins, spécification )
réalisables rapidement et par des non-informaticiens (ergonomes,
futurs utilisateurs) facilement modifiables et paramétrables
supports de communication au sein de l'équipe de conception
faire surgir de nouvelles idées, fonctionnalités, difficultés (réactions
spontanées)
 vérifier l'adéquation des choix aux besoins des utilisateurs, des clients
 éviter les malentendus

19/03/2010
43
 Exemple
de prototype papier
19/03/2010
44
Simulation

Comprend l’ensemble des fonctionnalités du système
N’atteint pas les performances maximales du système

Matériel :

générateurs d'interface
 plate-forme de développement


Intérêt
vérifier la faisabilité technique ou l'interopérabilité
 valider une solution
 mesurer un temps de réponse

19/03/2010
45
Simulation : Le Magicien d’Oz

Un humain supplée les
déficiences du prototype et
simule le futur système

intelligence naturelle pas
artificielle

Interprétation des entrées de
l’utilisateur par le le "Magicien"

Contrôle du comportement du
système

Sensation d’utilisation d’un vrai
système

Enregistrement des sessions
19/03/2010
46
Techniques d’évaluation :
Enquête d’usage qui analyse la manière dont les utilisateurs
agissent avec le produit dans une situation réelle
 Revues de conception


Techniques d’inspection : s’appuie sur les connaissances
d’un expert en facilité d’usage qui examine, selon des
critères éprouvés, l’utilisabilité d’un produit mais sans
utilisateur (Design Walkthrough)

Tests d’utilisabilité : permettent l’observation
d’utilisateurs réels lorsqu’ils interagissent avec un
système. Les utilisateurs sont priés d’effectuer des tâches
(scénario d’utilisation) pendant que des experts
enregistrent et interprètent.
19/03/2010
47
Design Walkthrough
But :
Déterminer le meilleur choix de conception qualitativement.
Évaluation légère
 Montrer/simuler et collecter des avis (utilisateurs, spécialistes
IHM, informaticiens)
 Se fait plutôt en phase d’exploration;

Procédure:
 Montrer la vidéo de chaque prototype
 Le présentateur déroule le scénario
 Le groupe identifie autant de problèmes que possible
On cherche à rassembler le plus de critiques (un peu à la
manière de brainstorming)
 Les critiques doivent être constructives.

19/03/2010
48
Tests d’utilisabilité
But :

Trouver les problèmes d’interaction s’il y en a, en
observant le comportement dans une situation réaliste.
Non-But :


Recueillir des commentaires
Faire en sorte que les utilisateurs réussissent les tests
pour pouvoir dire « ils ont réussi le test »
 S’assurer que ça marche vraiment
 Vous serez tenu pour responsable si ça ne marche pas
vraiment
19/03/2010
49
Tests d’utilisabilité

Avant le test :
Faire des évaluations pilotes du matériel et des tâches
 Préparer les tâches à accomplir par vos participants (et non cobaye)


Pendant le test :
Penser au confort des participants (au calme et seul), ne pas les
angoisser pour qu’ils réussissent
 C’est pas les utilisateurs qu’on teste mais c’est le système
 Ne jamais avoir l’air déçu, les mettre à l’aise pour éviter qu’ils se
sentent bêtes face aux observateurs
 Le participant peut abandonner si il le veut.


Après le test :
Expliquer en quoi ils ont aidé, répondre aux questions qu’il a fallu
repousser pour ne pas biaiser le test
 Rendre anonyme les données, ne pas montrer la vidéo sans l’accord
des participants.

19/03/2010
50
La conception participative

Produit des systèmes adéquats et efficaces pour assister les
activités des utilisateurs

La conception prend du temps mais elle est cruciale

L’utilisateur est en permanence dans la boucle

Les équipes sont pluridisciplinaires

4 phases itérées :
19/03/2010
51
 http://www.anneroudaut.fr/CIE/
 http://www.infres.enst.fr/~elc/graph/
 http://www.infres.enst.fr/~elc/graph/conce
ption/
 http://www.infres.enst.fr/~elc/graph/coursergo-ENST-09.pdf
19/03/2010
52