Transcript L’analyse des utilisateurs et l’analyse des tâches Qu’en pensez-vous? Conséquences? • L’utilisation des abréviations et des acronymes dans les interfaces (menus, boîtes de.

L’analyse des utilisateurs
et l’analyse des tâches
Qu’en pensez-vous? Conséquences?
• L’utilisation des abréviations et des acronymes dans les
interfaces (menus, boîtes de dialogues, etc.) sauve du
temps d’écriture et de lecture.
• Les raccourcis clavier sont bon pour les experts, mais
pas pour les utilisateurs typiques. Les ajouter à la
programmation fait perdre du temps.
• Un ingénieur/programmeur qui passe 7+ heures/jour à
concevoir et à coder, et 1 heure/jour à utiliser un logiciel
de dessin, connais bien les besoins des artistes qui
auront à se servir du même logiciel 8+ heures/jour.
• On peut sauver beaucoup de temps et d’argent en
réduisant les rencontres avec les utilisateurs.
• Comment peut-on satisfaire les utilisateurs
si on ne sait pas ce qu'ils font et comment
ils le font ?
• Une approche centrée utilisateur
commence par l'analyse des tâches et des
façons de faire actuelles
Étapes à suivre dans le développement
d’une interface utilisateur
• Analyse des utilisateurs et des tâches
– Collecte de données (entrevues et observations)
– Analyse, synthèse, et présentation des données
(résumés / listes / tableaux / diagrammes
des utilisateurs, des tâches, des observations, etc.)
Ce cours
• Premiers dessins et prototypes (en papier d’abord),
possiblement développés avec des utilisateurs
(prototypage participatoire)
– Tester ces prototypes avec des utilisateurs
• Itérer:
– Prototypes rafinés (en papier ou dessiné sur ordinateur,
et plus tard programmé)
– Tester avec des utilisateurs
Faites les étapes dans le bon ordre !
• N’investissez pas beaucoup d’effort dans la conception,
ni la programmation (!), avant de consulter avec des
vrais utilisateurs.
• Ne suppossez même pas que vous connaissez les buts
ou les tâches des utilisateurs, ni les fonctionnalités
nécessaires ou souhaités, avant de consulter avec des
vrais utilisateurs.
• Vous aurez la chance de vous servir de votre créativité
et de votre imagination dans la conception, mais il est
beaucoup mieux de faire cela suite à des consultations
avec des vrais utilisateurs et suite à une analyse des
utilisateurs et de leurs tâches.
Pour bien concevoir une interface,
il faut …
•
•
•
•
•
•
•
•
Comprendre les utilisateurs ET la technologie
Connaître les buts et les tâches des utilisateurs
Connaître leurs façons habituelles de travailler et de penser
Connaître le jargon et les termes employés dans le domaine de
travail des utilisateurs
Connaître le modèle conceptuel des utilisateurs par rapport à leur
travail (comment ils voient leur tâches)
Savoir comment font les utilisateurs pour collaborer et travailler en
groupes (“workflows” de groupe)
Connaître le(s) environnement(s) et les conditions dans le(s)quel(s)
les utilisateurs travaillent (ex: Peu éclairé et sal? Mobile?
Hospitaliaire? Etc.)
Connaître les limitations (ex: limitations physiques) des utilisateurs
Une interface bien conçue …
• Rend les utilisateurs plus contents
et plus productifs
• Augmente la satisfaction de vos clients
• Diminue le nombre d’appels de support
De plus, une interface bien conçue …
• Est basée sur des façons de travailler
(“workflows”) qui sont déjà connues par
l’utilisateur
• Utilise des concepts / métaphores / idiomes /
terminologie déjà connus par l’utilisateur
• Permet à l’utilisateur d’effectuer ses tâches sans
qu’il ait besoin de chercher beaucoup ou de se
questionner beaucoup sur le fonctionnement de
l’interface
– Idéalement, l’interface est transparente,
c.-à-d. l’utilisateur ne la remarque presque pas
Une interface mal conçue
nous coûte cher
• Il faut d’abord développer la mauvaise interface
(basée sur des fausses suppositions concernant
les utilisateurs, leurs tâches, ce qu’ils désirent,
etc.)
• Ensuite, il faut payer pour le support (appels,
etc.) à donner aux utilisateurs qui auront sans
doute des problèmes
• Ensuite, il faut payer pour modifier l’interface
dans la prochaine version du logiciel
• Il y aura aussi des ventes perdues dû à l’effet
néfaste de la première version sur notre
réputation
Une interface mal conçue coûte
cher à nos clients aussi
• Leurs employés vont trouver l’interface difficile à
utiliser
• Leurs employés vont faire plus d’erreurs,
et passer du temps à corriger ces erreurs
• Leurs employés vont passer du temps à se
demander, entre eux, comment fonctionner
l’interface
• Leurs employés vont peut-être adopter une
façon d’utiliser l’interface qui n’est pas efficace
• Leurs employés vont peut-être, à la limite,
quitter leur emploi par frustration
L’importance d’observer des vrais
utilisateurs
• Certains gens (utilisateurs experts,
gestionnaires) vont peut-être vous dire
qu’ils connaissent les besoins et les
façons de travailler des utilisateurs
ordinaires, mais souvent ils peuvent avoir
tort (ex: cela fait peut-être longtemps
depuis qu’ils ont fait les mêmes tâches)
L’importance d’observer des vrais
utilisateurs (suite)
• Si vous demandez aux utilisateurs des questions
concernant leurs tâches, leurs réponses vont souvent
omettre des détails importants. Ils auront tendence à
mentionner plus les parties ennuyantes et/ou difficiles de
leurs tâches, et de pas mentionner les choses très
habituelles qui sont aussi importantes.
• “experience has shown that users themselves do not
know how to articulate what they do, especially if they
are very familiar with the tasks they perform […] their
testimony is often incomplete and inaccurate […] [they]
leave out activities that they don’t even notice they’re
doing” (tiré de Hackos et Redish, “User and Task
Analysis for Interface Design”, page 7)
Des disciplines connexes
• Anthropologie et ethnographie
– Anthropologie: l’étude des êtres humains
– Ethnographie: l’immersion de soi-même dans une culture pour la
comprendre
– Observation discrète
• Observer de loin
– Observation participatoire
• Vivre dans un groupe / peuple / culture pour mieux comprendre
– Notions de respect pour les gens qu’on observe, et de porter de
l’attention à leur façon de parler et de travailler
– Différences avec l’analyse des utilisateurs et des tâches:
• Ethnographie: observation pendant 1-2 ans, dans le but de décrire
une culture
• Analyse des utilisateurs et des tâches: observation pendant des
heures / jours / semaines, dans le but de décrire et ensuite de
concevoir quelque chose de nouveau
Des disciplines connexes (suite)
• Marketing et le “Market research”
– Comprend l’étude des désirs et des préférences des
clients potentiels
– Les gens dans ce domaine ont souvent des
informations utiles à l’analyse des utilisateurs et des
tâches, par exemple: la taille et la composition des
segments du marché, ou des informations sur les
équipements de clients particuliers
– Le “market research” se concentre sur les attitudes et
les opinions des clients potentiels, tandis que
l’analyse des utilisateurs et des tâches se concentre
plus sur les comportements
Pour effectuer une analyse des utilisateurs et des tâches,
il faut construire un “inventaire” de plusieurs éléments
• Une définition du contexte / domaine / secteur industriel
• Les intervenants (types d’utilisateurs) qui réalisent les tâches
– Description de chaque intervenant
– Profils de vrais individus
– Tableau d’intervenants vs caractéristiques
• Les tâches / workflows / procédures
–
–
–
–
–
Liste des tâches
Hiérarchie de tâches et sous-tâches
Organigramme (“flow chart”) de tâches
Tableau de tâches vs caractéristiques
Tableau de tâches vs intervenants
• Scénarios
– Histoires servant d’exemples
• Vocabulaire / terminologie / glossaire du domaine
• Artéfacts du domaine
– Documents, outils, etc.
• Photographies, clips de vidéos
• Listes d’idées clées ou d’observations importantes
Domaine de l'application
• Le domaine décrit l'activité générale pour
laquelle l'application sera utilisée.
– Exemples de domaines : comptabilité, gestion de
portefeuille, conception de circuits imprimés...
• Il faut se familiariser avec la terminologie et les
concepts du domaine
– Indispensable pour une compréhension minimum des
tâches.
– Permet un meilleur dialogue avec les intervenants
Intervenants
• Personnes jouant un rôle dans la réalisation des
tâches.
– Aussi appelés agents, acteurs, stakeholders.
– Dans un sens plus large, tous ceux qui sont
concernés ou touchés par la tâche
• Exemples:
–
–
–
–
Responsable
Intervenants qui participent toujours à la tâche
Internes ou externes à l'entreprise
Clients
Intervenants (suite)
• Donner un profil des intervenants qui utiliseront
l'application. Idéalement le plus précis possible, sans
être spéculatif.
• Caractéristiques professionnelles.
• Caractéristiques socio-démographiques.
– Profession, années d’études (en moyenne), langue maternelle...
• Degré de familiarité avec les interfaces graphiques.
– Utilisation de logiciels similaires ou d’usage général.
• Degré de familiarité avec le domaine et les tâches.
– Exemple: système de support technique (centre d’appels).
– Intervenant type = technicien(ne), réceptionniste, gérant ?
Utilité des profils des intervenants
• Pourrait aider à choisir une interface adaptée
• Exemple:
Technicien(ne)
en informatique
• Personnel de bureau
Tâches
• Exemples de caractéristiques à noter:
– Fréquence à laquelle différents intervenants
réalisent une tâche
– Performances de chacun (temps d'exécution,
taux d'erreur)
– Degré de difficulté de la tâche pour différents
intervenants
Tiré de Hackos et Redish (1998), page 70
Tiré de Hackos et Redish (1998), page 33
Vocabulaire et artéfacts du
domaine
• Vocabulaire du domaine, termes
employées, concepts, etc.
• Outils, équipements, accessoires utilisés
ou produits lors des tâches: Exemples :
photocopieuse, déchiqueteuse, stylo, blocnotes, facture, etc.
Observation directe des activités
• Observer l’agent pendant son travail.
– Identifier: outils utilisés, comportement de l’utilisateur,
comportement des technologies, les communications liées au
travail, les procédures de prise de décisions, les intrants et
extrants des tâches, les problèmes rencontrés par l’utilisateur,
etc.
– Tip: demander à l'agent de verbaliser (« think aloud »)
– Noter le verbal et non-verbal.
• Tip: essayer de se faire oublier.
– Définir clairement l'objectif (PAS espionner, mais comprendre).
– Minimiser les questions et interférences.
– Les appareils d'enregistrement : plus objectifs, mais peuvent être
mal perçus, et génèrent beaucoup de données
Observation directe des activités
• Avantages.
– Collecte de données sur le travail réel.
– Recueillir des données non accessibles autrement.
• Désavantages.
– L’observation change la façon dont la tâche est faite.
– L’observation permet rarement de recueillir des
données sur les exceptions.
– Demande certaines connaissances pour comprendre
ce qui se fait.
Autres techniques d’observation
• Un journal (journal de bord, « diary ») qui
est entretenu par un intervenant
– Permet une étude longitudinal peu couteux
– Demande beaucoup de discipline de la part
de l’utilisateur
• Caméra vidéo cachée
• Techniques ethnographiques
– « Devenir » un utilisateur
Entrevues et questionnaires
• Personnes à interroger
– Employé, superviseur, etc.
• Préparer l’entrevue/le questionnaire
– Définir des objectifs clairs.
– Préparer sa stratégie et ses questions.
• Types:
– Dirigiste: questions fermées (quand, comment, combien de fois).
– Non-dirigiste: questions ouvertes (permettre des
développements).
– Libre: laisser l'interviewé aborder les sujets qui l'intéresse
Entrevues et questionnaires
• Avantages
– Permet de recueillir beaucoup de données sur
les perceptions des tâches
• Désavantages
– Données non rigoureuses
– Biais des interviewés
– N’accède pas aux parties inconscientes du
travail (automatismes)
Pour plus d’informations:
• Clayton Lewis and John Rieman (1994),
“Task-Centered User Interface Design:
A Practical Introduction”,
http://www.hcibib.org/tcuid/
• Hackos et Redish (1998), “User and Task
Analysis for Interface Design”
Remarque
• Il n’y a pas de recette unique pour faire
l’analyse des utilisateurs et des tâches !
• Prenez les techniques qui vous semble les
mieux adaptés et les plus utiles pour vous,
dans votre contexte
Des arguments possibles contre
l’analyse des utilisateurs et des tâches
• Notre produit est un nouveau logiciel; il n’existe pas d’utilisateurs à
observer
• Un des membres de l’équipe de programmation était lui-même un
utilisateur pendant 25 ans
• On a déjà fait des sondages / focus groups pour demander aux
utilisateurs ce qu’ils veulent
• Notre département de marketing connaît déjà les utilisateurs
• Nous n’avons pas assez de temps / d’argent pour le faire
• Nous avons une trop grande variété d’utilisateurs; on pourra jamais
tous les consulter
• On n’a pas d’expertise en analyse de tâches, donc on ne peut pas
bien le faire
• On a déjà de très bonnes idées pour le design du logiciel
• Les utilisateurs savent pas comment bien concevoir un logiciel