L - PowerPoint PPT Presentation

About This Presentation
Title:

L

Description:

Title: PowerPoint Presentation Last modified by: mjm Created Date: 1/1/1601 12:00:00 AM Document presentation format: Affichage l' cran (4:3) Other titles – PowerPoint PPT presentation

Number of Views:50
Avg rating:3.0/5.0
Slides: 41
Provided by: michaelmc75
Category:
Tags: histoires

less

Transcript and Presenter's Notes

Title: 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, connait 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
  • Exemple focus group

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(ou les parties prenantes)
  • 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.
  • Astuce 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
Dautres 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éressent

29
Entrevues et questionnaires
  • Avantages
  • Permet de recueillir beaucoup de données sur les
    perceptions des tâches
  • Désavantages
  • 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

33
  • "Your most unhappy customers are your greatest
    source of learning." -- Bill Gates

34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com