L

1
Lanalyse des utilisateurset lanalyse des tâches
2
Quen pensez-vous? Conséquences?

• Lutilisation 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 dargent en
  réduisant les rencontres avec les utilisateurs.

3

• 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

4
Étapes à suivre dans le développement dune
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 /
  diagrammesdes utilisateurs, des tâches, des
  observations, etc.)
• Premiers dessins et prototypes (en papier
  dabord), 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

Ce cours
5
Faites les étapes dans le bon ordre !

• Ninvestissez pas beaucoup deffort 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.

6
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

7
Une interface bien conçue

• Rend les utilisateurs plus contentset plus
  productifs
• Augmente la satisfaction de vos clients
• Diminue le nombre dappels de support

8
De plus, une interface bien conçue

• Est basée sur des façons de travailler
  (workflows) qui sont déjà connues par
  lutilisateur
• Utilise des concepts / métaphores / idiomes /
  terminologie déjà connus par lutilisateur
• Permet à lutilisateur deffectuer ses tâches
  sans quil ait besoin de chercher beaucoup ou de
  se questionner beaucoup sur le fonctionnement de
  linterface
• Idéalement, linterface est transparente,c.-à-d.
  lutilisateur ne la remarque presque pas

9
Une interface mal conçuenous coûte cher

• Il faut dabord développer la mauvaise interface
  (basée sur des fausses suppositions concernant
  les utilisateurs, leurs tâches, ce quils
  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 linterface
  dans la prochaine version du logiciel
• Il y aura aussi des ventes perdues dû à leffet
  néfaste de la première version sur notre
  réputation

10
Une interface mal conçue coûte cher à nos clients
aussi

• Leurs employés vont trouver linterface difficile
  à utiliser
• Leurs employés vont faire plus derreurs,et
  passer du temps à corriger ces erreurs
• Leurs employés vont passer du temps à se
  demander, entre eux, comment fonctionner
  linterface
• Leurs employés vont peut-être adopter une façon
  dutiliser linterface qui nest pas efficace
• Leurs employés vont peut-être, à la
  limite,quitter leur emploi par frustration

11
(No Transcript)
12
Limportance dobserver des vrais utilisateurs

• Certains gens (utilisateurs experts,
  gestionnaires) vont peut-être vous dire quils
  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 quils ont fait les
  mêmes tâches)

13
Limportance dobserver 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 dont even notice theyre
  doing (tiré de Hackos et Redish, User and Task
  Analysis for Interface Design, page 7)

14
Des disciplines connexes

• Anthropologie et ethnographie
• Anthropologie létude des êtres humains
• Ethnographie limmersion 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 quon observe,
  et de porter de lattention à leur façon de
  parler et de travailler
• Différences avec lanalyse 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

15
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 à lanalyse 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 lanalyse des utilisateurs et des
  tâches se concentre plus sur les comportements

16
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 dutilisateurs) qui
  réalisent les tâches
• Description de chaque intervenant
• Profils de vrais individus
• Tableau dintervenants 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 dexemples
• Vocabulaire / terminologie / glossaire du domaine
• Artéfacts du domaine
• Documents, outils, etc.
• Photographies, clips de vidéos
• Listes didées clées ou dobservations
  importantes

17
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

18
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

19
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 dusage
  général.
• Degré de familiarité avec le domaine et les
  tâches.
• Exemple système de support technique (centre
  dappels).
• Intervenant type technicien(ne),
  réceptionniste, gérant ?

20
Utilité des profils des intervenants

• Pourrait aider à choisir une interface adaptée
• ExempleTechnicien(ne)en informatique
• Personnel de bureau

21
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

22
Tiré de Hackos et Redish (1998), page 70
23
Tiré de Hackos et Redish (1998), page 33
24
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, bloc-notes,
  facture, etc.

25
Observation directe des activités

• Observer lagent pendant son travail.
• Identifier outils utilisés, comportement de
  lutilisateur, 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
  lutilisateur, 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

26
Observation directe des activités

• Avantages.
• Collecte de données sur le travail réel.
• Recueillir des données non accessibles autrement.
• Désavantages.
• Lobservation change la façon dont la tâche est
  faite.
• Lobservation permet rarement de recueillir des
  données sur les exceptions.
• Demande certaines connaissances pour comprendre
  ce qui se fait.

27
Autres techniques dobservation

• 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
  lutilisateur
• Caméra vidéo cachée
• Techniques ethnographiques
•  Devenir  un utilisateur

28
Entrevues et questionnaires

• Personnes à interroger
• Employé, superviseur, etc.
• Préparer lentrevue/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

29
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
• Naccède pas aux parties inconscientes du travail
  (automatismes)

30
Pour plus dinformations

• Clayton Lewis and John Rieman (1994),
  Task-Centered User Interface DesignA Practical
  Introduction, http//www.hcibib.org/tcuid/
• Hackos et Redish (1998), User and Task Analysis
  for Interface Design

31
Remarque

• Il ny a pas de recette unique pour faire
  lanalyse 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

32
Des arguments possibles contre lanalyse des
utilisateurs et des tâches

• Notre produit est un nouveau logiciel il
  nexiste pas dutilisateurs à 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 quils veulent
• Notre département de marketing connaît déjà les
  utilisateurs
• Nous navons pas assez de temps / dargent pour
  le faire
• Nous avons une trop grande variété
  dutilisateurs on pourra jamais tous les
  consulter
• On na pas dexpertise 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