ENI BAMAKO 2016-2017

Licence /S6/2018

IHM
analyse de tâches
Chargé de cours:
Dr Yacouba GOÏTA
Tél : 72.21.09.60
Email : [email protected]
 THEME:

Cueillette de besoins
usagers et analyse de
tâches
La clé du succès…
(CACM, Mai 1995)

L’analyse de tâches et la cueillette

des besoins sont incontestable-
ment LES SECRETS (ou la CLÉ) du
succès dans la conception d’inter-
faces utilisateurs gagnantes…
Une recommandation clé

La meilleure façon de tailler

un système à la mesure de
ses utilisateurs est de le
baser sur leur modèle
mental.
Définitions de base…

 Une tâche est une unité d’activité

humaine exécutée dans le but d’atteindre
un objectif spécifique

 La réalisation d’une tâche passe habituel-

lement par une séquence d’étapes,
chacune d’elles contribuant à l’atteinte
de l’objectif spécifique de la tâche
Définitions de base…

 Une tâche peut également être constituée

de sous-tâches

 Un processus de travail (ou processus

d’affaires) est constitué d’un ensemble de
tâches inter-reliées et contribuant à
l’atteinte d’un objectif parent commun
Définitions de base…
Quelle est la différence entre une tâche
et une activité ?

 L’activité représente ce qui est fait (c’est

le « comment »)…

 tandis que la tâche désigne ce qui doit

être fait (c’est le « quoi »)….
Définitions de base…
Pourquoi cette différence est-elle essentielle
pour la conception d’interface ?
 La conception s’appuie sur un cahier des
charges  informations sur la tâche et non sur
l’activité. Or, c’est dans un contexte d’activité
que sera utilisé le logiciel
 Importance de bien observer l’utilisateur en
situation pour bien comprendre son activité
(voir séance sur l’évaluation des interfaces)
Définitions de base…
Pourquoi cette différence est-elle essentielle
pour la conception d’interface ?
 Pour que l’interface s’adapte à l’activité réelle des
utilisateurs, elle doit prendre en compte différentes
stratégies d’utilisation en offrant une flexibilité dans les
moyens de dialogue.
 Exemple :
la commande d’impression peut être déclenchée soit
par une fenêtre de dialogue permettant de choisir la
plage d’impression et le nombre de copies, soit
directement par un bouton  adaptation aux
utilisateurs pressés mais aussi aux utilisateurs qui
désirent prendre le temps de paramétrer finement
Définitions de base

Processus, tâches et sous-tâches

Légende

Processus Tâches Sous-tâches

Objectifs de l’analyse de
tâches
 Mieux comprendre les tâches de
l’utilisateur

 Mieux faire cadrer l’interface avec le

modèle mental de l’usager

 Impliquer activement l’utilisateur sur une

base participative
Les 4 dimensions de l’analyse
de tâches

Utilisateurs

Tâches Objectifs

Contexte
Les 4 dimensions de l’analyse
de tâches

La tâche
utilisateur

Tâches
La tâche utilisateur
C’est l’objectif que cherche à atteindre l’utilisateur,
i.e. le résultat qu’il souhaite obtenir.
Ex : traitement de texte  communiquer en
rédigeant un document.

Avant de réaliser une tâche, l’être humain la

décompose « naturellement » en problèmes simples
de façon hiérarchique :
But principal => sous-buts => actions élémentaires

(voir plus loin l’étape 3 de la technique de l’AHT)

Les utilisateurs

Utilisateurs
Les utilisateurs : quelques considérations générales

 L’utilisateur moyen n’existe pas

 Les U ne savent pas exactement ce qu’ils veulent
dans le nouveau système
 Certains U ont de la difficulté à exprimer leurs
besoins
 Les U sont incapables de bien évaluer un système
à partir de ses spécifications fonctionnelles
 Les U ne savant pas bien ce que la technologie
peut faire pour eux
Les utilisateurs : quelques considérations générales

 Les U changent d’idée au cours de la

conception
 Les U ne sont pas de bons concepteurs
 Les U font des erreurs, indépendamment
de leur niveau d’expertise et de la qualité de
l’interface qu’ils utilisent
 Il existe un écart plus ou moins grand entre
ce que les U disent et ce qu’ils font
réellement
Les utilisateurs : quelques considérations générales

 Les U et les concepteurs ont souvent de la

difficulté à se comprendre à cause de:
– leur formation antérieure
– Leurs priorités
– Leur niveau de connaissance de la tâche
 Les U ont des connaissances qui évoluent avec
l’usage du système
 Les U pensent en termes de logique d’utilisation
alors que les concepteurs pensent en termes de
logique de fonctionnement du système
Les utilisateurs : leurs forces
 Font automatiquement des liens ou des analogies
entre des choses (mémoire associative)
 Peuvent être créatifs, imaginatifs dans les
solutions
 Exercent leur jugement (ex., ça, c’est important,
prioritaire)
 peuvent facilement percevoir des « patrons »
(pattern matching)
 Sont capables de réagir à des propositions
d’interfaces (et dire si telle fonctionnalité leur
semble utile ou non, s’ils aiment ou non, s’ils
veulent ça ou non)
Les utilisateurs : leurs faiblesses
 Font des erreurs
 Manque de fiabilité
 Capacité très limitée de la mémoire à court terme
(ils oublient facilement)
 Ont de la difficulté avec les détails (parce qu’ils
exigent attention, précision
 Sont de mauvais optimiseurs
 Ont de la difficulté à extrapoler, ou prévoir
longtemps d’avance
 Ont un modèle mental pouvant être faux,
incomplet, inégal
Les utilisateurs : comment les identifier et
les caractériser en cours de conception ?

(voir plus loin

l’étape 1 de la
technique
de l’IEEE)
Les objectifs

Objectifs
Les objectifs
 Objectifs d’ordre professionnels ou personnels
des utilisateurs (que le système devra permettre
d’atteindre)
– Personnels
• Finir plus tôt
• Diminuer le stress, faciliter le travail
• Etc.
– Professionnels
• Respecter les échéances
• Augmenter la productivité
• Etc.
Le contexte

Contexte
Le contexte
Rappel de la définition de l’Utilisabilité telle que
Formulée par la norme ISO 9241-11 :

« Degré selon lequel un produit peut être

utilisé, par des utilisateurs identifiés,
pour atteindre des buts définis avec
efficacité, efficience et satisfaction, dans
un contexte d’utilisation spécifié. »
Système ressenti
comme agréable
Réaliser complètement à utiliser
sa tâche En consommant juste les
ressources nécessaires
Le contexte
 Quelques aspects du contexte à considérer et qui
auront un impact sur les choix de conception
– Stress
– Délai de réalisation
– Interactions entre collègues, clients, etc.
– Ergonomie de l’environnement (voir les contre-
exemples anecdotiques sur l’acétate suivante)
– Volatilité du personnel
– etc.
Le contexte
Contre-exemples anecdotiques :
Bip sonore en cas d’erreur dans des bureaux
organisés en « cubicules » ou dans un endroit bruyant
Le contexte
Contre-exemples anecdotiques :

Écran tactile dans une cuisine ou dans un garage

de mécanique
Endroit passant (distraction, mémorisation, etc.)
Volatilité du personnel et langage de commandes
Usage de la couleur pour non-voyants ou daltoniens
Et on pourrait trouver des dizaines d’autres contre-
exemples similaires…
Les conséquences de l’analyse de
tâches
 Objectif : supporter l’activité humaine
(modèle mental)

 Prévient les complications causées par le

système

 Mène à la découverte de nouvelles idées

de design
Rôle de l’analyse de tâches
 Distinctions entre :
– Tâche prescrite,
– Tâche réelle,
– Activité
 Caractéristiques d’une tâche : but, début/fin,
fréquence
 Plusieurs méthodes de description et/ou
d’analyse:
– Représentation sous forme de réseaux, d’organigrammes, etc.
– Analyse Hiérarchique de la Tâche (AHT)

Préconisée
Analyse hiérarchique de la tâche
(AHT)
Exemple : Retrait à partir d’un guichet automatique
0. Retirer X $ du compte chèque (but ou objectif)
exécuter 1, 2, 3, 4 1. S’identifier
exécuter 1.1, 1.2 1.1 Insérer carte
1.2 Entrer NIP

2. Choisir le compte
exécuter 2.1, 2.2 2.1 Lire liste de comptes disponibles
2.2 Sélectionner le compte chèque

3. Spécifier le montant à retirer

exécuter 3.1 3.1 Entrer le montant désiré
si montant exact 3.2 Confirmer le montant
faire 3.2, sinon
refaire 3.1

4. Exécuter le retrait
etc……
Analyse hiérarchique de la tâche
(AHT)
Le même exemple sous forme graphique (diagramme
hiérarchique)
Retirer X $ du
compte chèque
Faire
1,2,3,4

2 - Choisir 3 - Spécifier 4 - Exécuter

1 - S’identifier
le compte le montant le retrait

Faire
1.1, 1.2

1.1 - Insérer
1.2 - Entrer son NIP
sa carte
Analyse hiérarchique de la tâche
(AHT)
 Avantages
– Facile à comprendre et à visualiser
• hiérarchie
• représentation schématique
– De plus en plus utilisée
• soutien à la conception de nouveaux éléments
(partie intégrante de l’analyse de l’activité pour
définir l’interactivité avec le système)
• soutien à l’optimisation d’éléments existants
(réengineering)
Analyse hiérarchique de la tâche
(AHT)
 Inconvénients
– Plus complexe à réaliser qu’à
suivre/comprendre
– La mise en œuvre peut être délicate lorsque
l’activité est complexe
• toutes les tâches ne sont pas « facilement »
organisables hiérarchiquement
• formalisme qui demande un peu de connaissances
spécifiques
Analyse hiérarchique de la tâche
(AHT)
 Comment obtenir l’information
– Sources de données
• De façon privilégiée : à partir de données
empiriques
– Évaluations expertes (du système ou comparables)
– Observations (tests usagers)
– Feedback des usagers (entrevues, focus groups,
questionnaires d’appréciation, courriels de plaintes, etc.)
• De façon traditionnelle : Documents techniques
(manuels, aide, etc.)
• Importance de l’opportunisme
Analyse hiérarchique de la tâche
Acheter le
produit ABC

Vendre les Faire 1,2,3

produits de la
firme XYZ 1 - Consulter la 2 - Choisir le 3 - Commander le
Liste des produits produit ABC produit ABC
disponibles

Permettre au Livrer les

Offrir les client de choisir produits de la 1.1 1.2 1.3
produits et de commander firme XYZ Consulter Consulter par Consulter
des produits par saison catégorie par…

 Fonctions  Tâches
– A quoi sert le produit (mission) – Comment va-t-on utiliser telle
– Comment va-t-il réaliser sa ou telle fonctionnalité ?
mission ?

Analyse fonctionnelle versus Analyse de tâches

Tâches importantes
Tâches clés

Hiérarchie
de tâches
Novices 1

2 3

4 5

6 7 8 9 10
Produits
concurrents
Relations entre tâches et processus
d’affaires
 Confusion courante entre analyse de la
tâche et processus d’affaires
– Analyse de la tâche = du point de vue de
l’individu
• Procédural : verbes d’actions (ex : Trier, Valider,
S’inscrire,…)
– Processus d’affaires = du point de vue de
l’organisation
• Organisationnel (implique plus d’un individu et
parfois plus d’une organisation) : activités
nominales (ex : Tri, Validation, Inscription,…)
Relations entre tâches et processus
d’affaires
 Processus d’affaires :
– Ensemble de (tâches) reliées logiquement pour
atteindre un objectif d’affaires défini
– Ensemble structuré et mesuré (d’activités)
conçues pour produire un extrant spécifique à
un cleint ou à un marché
– Caractéristiques
• Clients internes ou externes
• Traversent les frontières organisationnelles
Relations entre tâches et processus
d’affaires
Processus : admission dans une urgence d’hôpital
Déplacement à l’hôpital
Trier les
Attente avant triage patients

Triage
Accueillir Évaluer Assigner
Déplacement à inscription patients patients priorité

Attente pour inscription

Questionner Prendre
sur symptômes signes vitaux
Inscription

Déplacement salle d’attente

Attente

Examen par médecin

Perspective « processus » versus Perspective « tâche »

Méthode pratique
(IEEE Software, novembre 1994)

1. Identifier et caractériser les utilisateurs

2. Définir les processus de travail
3. Définir des modèles de tâches
4. Créer des scénarios de tâches
5. Créer le modèle de présentation
6. Créer et évaluer des « storyboards »
1. Identifier et caractériser les
utilisateurs…
Grand public ?
Décideurs de l’achat pour d’autres ?
Est-ce des experts ou des novices ?
Utilisateurs primaires et utilisateurs
secondaires ?
Attention aux managers qui vous
écartent des véritables utilisateurs !
1. Identifier et caractériser les
utilisateurs…
Quelques exemples d’utilisateurs « secondaires »

les collègues et supérieurs (directeurs) des véritables

utilisateurs (i.e. primaires);
les clients de l’organisation (ex : tickets de bus, train,…);

les syndicats;

les associations d’employés;

les actionnaires;

les gouvernements.
1. Identifier et caractériser les
utilisateurs…
 Marketing: Qui achète le produit ?
 Design: Qui utilise le produit ?
 Importance d’atteindre les véritables
utilisateurs
– Médecins vs infirmières
– Chefs de services vs employés
– Cadres vs techniciens
– Etc.
1. Identifier et caractériser les
utilisateurs…
1. Rassembler un groupe de personnes de
l’organisation qui interagissent régulière-
ment avec les usagers
2. Élaborer par « brainstorming » une liste
préliminaire d’utilisateurs potentiels
3. Établissez la liste des paramètres que
vous considérez comme typiques de votre
communauté d’utilisateurs
1. Identifier et caractériser les
utilisateurs…
Quelques paramètres à considérer :

Paramètres Explications
lieu de résidence, aspects Dans quelle région ou quel pays le
politiques, économiques et système sera-t-il utilisé ? Quel est
sociaux le contexte politique, économique
et social ?
nombre Développe-t-on un système pour
quelques U seulement, une
catégorie professionnelle ou tout le
monde (« grand public ») ?

âge Enfants, personnes âgées ?

Jeux vidéo : garçons, filles, les
deux ?
1. Identifier et caractériser les
utilisateurs…
Quelques paramètres à considérer (suite) :

Paramètres Explications
sexe Le système s’adresse-t-il aux
personnes d’un seul genre ou des 2
?
langue Quelle langue pour l’interface, le
manuel, la documentation
technique ?
origine ethnique, religion, Ex : Que faire et ne pas faire dans
culture le cas d’une interface destinée à des
pays asiatiques ou à des pays
musulmans ?
1. Identifier et caractériser les
utilisateurs…
Quelques paramètres à considérer (suite) :

Paramètres Explications
niveau d’éducation A généralement un impact sur la
capacité de compréhension du
texte, la vitesse de lecture,
l’autonomie, l’attitude envers le
système
connaissances informatiques Impact sur les outils à fournir à l’U,
(voir plus loin « User cube ») l’aide en ligne, les messages, la
documentation,…
connaissances du domaine Impact sur les fonctionnalités à
(voir plus loin « User cube ») offrir à l’U (tour guidé, tutoriel,
messages, aide en ligne, …)
1. Identifier et caractériser les
utilisateurs…
Quelques paramètres à considérer (suite) :
Paramètres Explications
connaissances de la tâche Novice, intermédiaires ou expert de
(voir plus loin « User cube ») la tâche ? Impact sur la
terminologie de l’IPM, les styles
d’interaction, le type d’aide en
ligne
déficiences sensorielles, -systèmes pour les mal-voyants, les
motrices, mentales mal-entendants, …
- daltoniens : 8,5% des hommes et
0,5% des femmes (le rouge cause le
plus de problèmes)
habiletés Bons ou mauvais clavistes ? Impact
sur les styles d’interaction, les
raccourcis-clavier
Exemple du « Cube usager »
Nature
expertise
« User
cube »
informatique

domaine
Fréquence
peu
fréquent
fréquent
intermittent d'utilisation
novice

expert

intermédiaire
User
Cube : novice
Niveau d’expertise
Fréquence : peu fréquent
Niveau
Nature expertise : informatique
d'expertise
1. Identifier et caractériser les
utilisateurs…
Quelques paramètres à considérer (fin) :

Paramètres Explications
styles cognitifs -Analytique vs intuitif
-Visuel vs auditif
préférences personnelles - styles d’interaction
- dispositifs d’entrée et de pointage
- configuration de l’écran,
-…
attitudes, motivation - positive, négative ou neutre ?
- motivés ou non à apprendre le
système ?
1. Identifier et caractériser les
utilisateurs…
Exemple type (réel)* :
Sexe 30% de femmes
70% d’hommes
Âge X = 32 ans

Niveau 79% ont au moins une formation collégiale

d’éducation
Catégories 50% professions libérales
professionnelles
Niveau de groupe le plus bas : 40 000$ U.S.
revenus groupe le plus élevé : 80 000$ U.S.

*profil-synthèse des utilisateurs qui a été tracé lors de la conception de l’interface du

fureteur multilingue de Alis Technologies (Montréal)
1. Identifier et caractériser les
utilisateurs…
Exemple type (suite) :
Lieu 40% corporations, 30% domestique, 30% autres
d’utilisation
Utilisation 62% : environ 2 heures/semaine
d’Internet
Système 62% Windows, 21% Mac, 7% Unix
d’exploitation
Progression de (en millions) 1996 2000
l’utilisation PC 167 225
courriel 60 200
Internet 23 152

Note : le niveau de connaissance en anglais a fait l’objet d’une étude spécifique

et a donné lieu à l’élaboration d’un tableau dédié non présenté ici.
2. Définir les processus de travail…

Le modèle de processus comprend:

• Source du travail
• Responsabilités ou fonctions
• Types de résultats attendus
• Destination des produits
• Facteurs critiques de succès
• Motivation
Comment faire (techniques) ?
2. Définir les processus de travail…

Exemple : processus Admission (projet de session)

• Source du travail : réception d’une demande

d’admission
• Responsabilités ou fonctions : Bureau du registraire
• Types de résultats attendus : traitement de
l’admissibilité et réponse au candidat
• Destination des produits : (réponse au) candidat
• Facteurs critiques de succès : délai de réponse
• Motivation : recrutement
Comment faire (techniques) ?
2. Définir les processus de travail…

 Observation interactive
– Observer les principaux processus
– Poser des questions spécifiques
 Interviews structurées
– Questions principales (de fond)
– Questions secondaires (clarifier)
 « Focus » group
– Usagers sélectionnés avec soin
2. Définir les processus de travail…

Conséquences possibles et souhaitables

 Réorganisation du travail
 Réduction de la durée de réalisation de tâches
 Identification des principales fonctionnalités que
doit supporter le système
 Organisation de ces fonctions
 Perception du travail par les utilisateurs
3. Définir des modèles de tâches…

• Analyse de chacun des processus pour en

identifier les tâches
• Caractérisation de chacune des tâches
- Nom et description
- Sous-tâches associées
- Élément déclencheur
- Objectifs de la tâche
- Facteurs tels que: fréquence, complexité,
importance ou contraintes de temps
 Passer ensuite à l’élaboration du modèle de tâche
3. Définir des modèles de tâches…

• Attention :

Ne pas confondre « Caractérisation » de

tâche et « modèle » de tâche. Les deux
sont complémentaires et non exclusifs !
3. Définir des modèles de tâches…

Développement des modèles de tâches

• Décomposition de tâches et analyse cognitive de
tâches
 Représentation des caractéristiques
procédurales et mentales d’une tâche
ou
• Collecte d’informations sur les tâches par
interviews structurées ou par formulaire
d’observation de tâches

But: Diagramme hiérarchique de tâches

3. Définir des modèles de tâches…
 Le découpage en fenêtres doit découler
directement de l’architecture de la tâche et de la
façon dont l’utilisateur mène les différentes sous-
tâches (en fait du modèle de tâche). Ex.: si
l’utilisateur réalise les tâches en parallèle, les fenêtres
correspondantes pourront apparaître simultanément

 La connaissance des informations nécessaires à

la réalisation de chaque tâche fournit le contenu
de chaque fenêtre
3. Définir des modèles de tâches…
 Exemple : logiciel destiné à un gérant de magasin

Diagramme
hiérarchique
ou

Modèle de
tâche

Le lecteur remarquera
l’absence dans ce modèle de
tâche de toute référence à
des aspects informatiques
(boutons, menu, fenêtre, etc.)
3. Définir des modèles de tâches…
 Comment faire cadrer le modèle de tâche avec le
prototype d’interface à proposer ?
Établir le bilan des
ventes

Vérifier les
commandes

Contrôler les
stocks

Sous-tâches du modèle
de tâche de l’acétate
précédente
3. Définir des modèles de tâches
 A noter que l’acétate précédente représente un
modèle de présentation (prototype) qui ne vient
normalement qu’à l’étape 5 (voir plus loin) de
cette méthode d’analyse de tâche qui en compte 6.

 Pour des raisons pédagogiques, cette illustration

n’est donc là que pour illustrer l’adéquation qui
doit exister entre le modèle de tâche et le
prototype d’interface.
3. Définir des modèles de tâches
 Certaines tâches peuvent s’exécuter en
séquence, selon un choix ou en parallèle.

 Conventions de notation :

--- Les tâches s’exécutent en séquence

+ Les tâches s’exécutent selon un choix

Les tâches s’exécutent en parallèle

3. Définir des modèles de tâches
 Exemple
Notez que les tâches peuvent T1
être aussi bien informatiques
que manuelles.

T2 T3
---

T4 T5 T6
+

T7 T8 T9 T10 T11
4. Créer des scénarios de tâches…

 Terminologie
– Scénarios
– Histoires, Vignettes
– Storyboards
– Cas d’utilisation (« Use cases »)
– Personas
–…
4. Créer des scénarios de tâches…
 Perspective  Perspective
« scénario » « traditionnelle »
– Descriptions concrètes – Descriptions abstraites
– Accent mis sur des – Accent mis sur des
exemples particuliers types génériques
– Dirigé par le travail – Dirigée par la
– Ouvert, fragmentaire technologie
– Informel, brut, familier – Complet, exhaustif
– Résultats envisagés – Formel, rigoureux
– Résultats spécifiés

( J.M.-Carroll, 1997)
4. Créer des scénarios de tâches…
Co-habitation abstrait/concret

Scénario sous forme

de story-board : « A
day in the life »

(Tollmar, Sandor & Schomer, 1996)

http://www.nada.kth.se/iplab/at-work/at-work-cscw96.html
4. Créer des scénarios de tâches…
Co-habitation formel/informel

Lien entre scénario informel

(« scène de la vie réelle »)
et scénario formel (« modèle
abstrait »)

(Haumer, Heymans & Pohl, 1998)

Scénarios Les scénarios devront
tenir compte des
4 dimensions de
l’analyse de tâche

Utilisateurs

Tâches Objectifs

Contexte
Scénario
 Ce n’est rien d’autre qu’un prototype

 Décrit un méta-contexte d’utilisation

 Permet de soulever des questions

 Complète avantageusement la
documentation du système
 Document narratif décrivant le
déroulement (scénario) d’une tâche
Scénario
Méthodes existantes
 Méthode de Carroll
 Méthode de Mack
 Méthode de Erskine, Carter-Tod & Burston
 Méthode de Urquhart
 Méthode de Potts
 Méthode SUNA (Scenario-based User Needs
Analysis)
 Méthode CREWS
 La mienne (simple)…
Scénario
Méthode simple
 Choisir un problème (tâche à réaliser ou
objectif à atteindre)
 Interviewer et observer les utilisateurs
 Proposer des solutions pour supporter les
activités des utilisateurs
 Rédiger un document narratif (1 à 2 pages +
annexes si nécessaire)
Scénario
Questions à se poser pour l’élaboration du
scénario :
 Quel est l’objectif à atteindre ?
 Quelles sont les motivations de
l’utilisateur ?
 Quels sont les obstacles ? Comment les
surpassera-t-il(elle) ?
Exemple de (bon) scénario
(retrait de 60 $ à un guichet automatique)
1- L’utilisateur s’approche du guichet et
insère sa carte. Peu importe le sens dans
lequel la carte est insérée, le guichet la lit
correctement.
2- Le guichet demande à l’utilisateur de
s’identifier.
3- Le guichet propose à l’utilisateur de
choisir l’une des 4 options : retrait rapide
de 60,00 $, retrait, dépôt ou autre
transaction.

Noter que l’on ne précise pas comment s’identifier. Ceci permet de laisser au
concepteur la possibilité de choisir parmi plusieurs alternatives possibles.
 Exemple de (bon) scénario (suite et
fin)
4- L’utilisateur choisit l’option retrait rapide
de 60,00 $ et le guichet lui remet ce
montant, le déduisant de son compte. Si
l’utilisateur possède plus d’un compte, le
guichet effectue le retrait à partir du
compte ayant le plus haut solde.

5- Le guichet remet la carte à l’utilisateur.

Remarques
a- Aucune référence à des éléments
technologiques ou informatiques
(bouton, souris, menu, etc.)
b- description descriptive et narrative
de la chronologie des opérations de
base à effectuer pour réaliser la
tâche
 Exemple de « mauvais » scénario
a- L’utilisateur est dans le menu
« Création ou Révision » qui offre divers items
(options de formatage et de stockage) possibles.
b- Il y a un prompt: « veuillez entrer la 1ere lettre de
l’item de votre choix puis Retour ».
c- L’utilisateur tape la 1ere lettre de l’item de son
choix puis Retour. Un message apparaît au bas
de l’écran. « La modification au format n’est pas
possible ».
Exemple de « mauvais » scénario
d- Après avoir essayé plusieurs autres
items, produisant le même effet,
l’utilisateur presse Retour pour
passer à l’état suivant du système.

( Tiré et traduit de Carroll & Rosson, 1992)

5. Créer le modèle de
présentation…
6. Créer le modèle de présentation
 A quoi ressemblera le système ?
 Beaucoup pensent que la conception d’une
interface commence ici !
 Le modèle de présentation détermine la façon
dont seront présentées les tâches et les fonctions
aux utilisateurs:
– Regroupement de tâches, de fonctions, de
commandes et de menus pour une efficacité
maximale
– Développement de panoramas d’écrans initiaux et
de principes directeurs
5. Créer le modèle de
présentation
 Le modèle de présentation concerne:
– Dessins d’écrans;
– Texte: fontes, styles, tailles, couleurs;
– Combinaisons de couleurs de fond et de premier
plan;
– Mécanismes de sélection (boutons radios, boîtes à
cocher, etc.)
– Regroupement et aération des informations;
– Styles d’éléments graphiques;
– Taille, style et emplacement des boutons;
– etc.
6. Créer et évaluer des
« storyboards »…
 Version électronique ou papier des écrans
préliminaires pour des scénarios spécifiques
 Simulation de la dynamique de l’interaction
 Faire abstraction du détail
 Les techniques du « brainstorming » ou du
« focus-group » sont bien adaptées à ce stade
 Déroulement du « storyboard » et raffinements
successifs à faible coût
6. Créer et évaluer des
« storyboards »
Technique pratique et facile
 Placer les « storyboards » ou dessins d’écrans
sur des posters affichés sur les murs dans une
salle de conférence
 Chaque poster contient:
– Le « storyboard » lui-même
– Une description orientée tâche de ce que l’usager
devrait faire pour accomplir une tâche donnée
– Une liste de questions et/ou de remarques
 Chaque participant se promène et doit faire ses
commentaires et répondre aux questions sur les
posters (à l’aide de « Post-it » par exemple)
Quelques techniques…

 Observation ethnographique (Enregistrement

vidéo, pensée à haute voix, questionnaires)
 Interviews structurées
 Schémas heuristiques
 « Brainstorming »
 « Focus-group »
Quelques techniques…

Observation
Ethnographique
Issue des
sciences
humaines
(anthropologie)
Quelques techniques…

Interviews
structurées
Issues des
sciences
humaines
(psychologie)
Quelques techniques…

Focus-group
Issue des
sciences
humaines
(psychologie)
Schéma heuristique…

Schéma
Heuristique
(« mind map »)
T. Buzan et B. Buzan
The Mind Map Book
Penguin Group, NY.
1996, pp. 96-114
Schéma heuristique…

 représentation graphique

 basée sur le fonctionnement du cerveau

humain

 concept de Tony Buzan (1996)

Schéma heuristique…

Principe

 idée principale au centre de la page

 ramifier à partir de l’idée principale

 mots ou très courtes phrases

 couleurs et symboles
Exemple de schéma
heuristique
Inconvénients

Vertical

Prototypage Types

Scénario
Trouve
problème
tôt
Avantages Horizontal

Avantage
utilisateurs
Itératif
Schéma heuristique…
Avantages Inconvénients
 idée centrale claire
 importance relative de
Je
chaque idée
 aucune contrainte de n’en
séquence, de priorité vois
 insertion facile de personnellement
nouvelles idées
aucun…
 simple, cerveau
 langage adapté usager
Remue-méninges…

Remue-méninges
« brainstorming »

Imaginée en 1938
par
Alex F. Osborn
Remue-méninges…

Principe
 technique précise de créativité
 solutionne rapidement des problèmes
précis et concrets
 se pratique en groupe
 absence de censure
Remue-méninges…

Exigences

 différer le jugement
 imagination débridée
 quantité plutôt que qualité
 enchaînement des idées
 ne pas ridiculiser les autres
Remue-méninges…

Fonctionnement

 problème simple et concret

 équipe ~ 12 personnes
 équipe: personnes du même rang social
 explication des consignes
 durée: 30 à 40 minutes
Remue-méninges

Consignes

 différer le jugement

 laisser libre cours à son imagination

 enchaînement d’idées (pouce)

 main levée pour signaler une idée

 Claquement des doigts pour enchaînement

Méthode de conception…

La mise en place d’une méthode de

conception sera plus facile si vous:
 mettez sur pied un groupe d’usagers
(« user task force »)
 visitez les utilisateurs dans leur véritable
environnement de travail
 N’appliquez pas aveuglément les standards
 Travail dirigé
Un exemple…

Tâche (objectif
spécifique):
Demande
d’équivalence d’un
cours suivi hors
établissement
Un exemple…
Énoncé de la problématique:
Supposez qu’un étudiant ait suivi un cours
informatique dans une autre université et qu’il
veuille savoir s’il existe un cours de contenu
similaire à Laval dans le programme auquel il
vient d’être nouvellement admis (bacc en IFT par
exemple) afin de demander une équivalence. On
suppose également qu’il ne sait pas comment
procéder pour déposer une telle demande (pièces à
fournir, personne à qui s’adresser, délai, etc.).
Un exemple…
Travail à faire :

 Élaborer le modèle de tâche pour un étudiant qui

voudrait déposer une telle demande;
 Proposer un prototype papier qui découlerait de
l’analyse précédente;
 Élaborer un scénario complet d’illustration;
 Appliquer la technique de la simulation mentale
sur ce scénario pour valider votre prototype.
Références
bibliographiques
Ben Shneiderman (1998). Designing the user
interface: Strategies for Effective Human-
Computer Interaction, Addison-Wesley.
Hackos J.T. & Redish J.C. (1998). User and Task
Analysis for Interface Design. John Wiley & Sons.
T. Buzan et B. Buzan (1996). The Mind Map Book.
Penguin Group, NY.

(voir aussi la Bibliographie)