L'valuation d'une interface consiste mesurer l'utilit et
l'utilisabilit du systme. Une valuation permet de dcouvrir les
problmes qui pourraient empcher les utilisateurs d'accomplir leurs
tches. Les problmes d'utilisabilit sont des aspects du systme
pouvant rduire l'usage du systme pour l'utilisateur, par exemple en
le droutant, ralentissant ou stoppant l'excution de sa tche
[LAVERY&COCKTON97].
Page 3
De nombreuses techniques permettent de raliser cette valuation.
Les diffrences entre les techniques concernent leur centre d'intrt,
la personne responsable pour l'valuation, la prsence
d'utilisateurs,... Chaque mthode d'valuation priviligie un ou
plusieurs critres d'utilit et utilisabilit travers la mesure de
diffrentes variables : la dure d'excution, le taux d'erreurs,...
[FARENC97].
Page 4
Nous allons d'abord faire un rapide tour d'horizon des
diffrentes techniques existantes. Ensuite, nous concentrerons notre
attention sur une mthode d'valuation particulire : Cognitive
Walkthrough. Lewis et Rieman classifient les techniques d'valuation
en deux groupes : les techniques avec utilisateur et celles sans
utilisateur [LEWIS93].
Page 5
Evaluation avec utilisateur Comme le systme conu par le
processus de design doit permettre aux utilisateurs de raliser leur
tche, la non-implication des utilisateurs dans ce processus de
design est impensable. Peu importe la qualit de l'analyse effectue
lors de la conception d'une interface, l'exprience a montr que de
nombreux dfauts d'utilisabilit n'apparaitront qu' l'occasion des
tests effectus avec des utilisateurs. Le profil de ces utilisateurs
doit tre semblable ceux des utilisateurs finaux du systme.
[LEWIS93]
Page 6
Evaluation avec utilisateur Supposons un logiciel
d'architecture destin la production de plan de construction. Les
utilisateurs participant aux tests d'valuation de l'interface
devront bien entendu tre des architectes eux-mmes.
Page 7
Evaluation avec utilisateur L'valution avec utilisateur est
probablement la meilleure mthode pour trouver les problmes
d'utilisabilit causs par une interface. Un utilisateur est plac
devant une interface et doit essayer d'accomplir une ou plusieurs
tches que le systme est cens supporter. Comme dit prcdemment, les
utilisateurs qui participeront aux tests doivent tre choisis de
manire approprie. Trois techniques de tests o les utilisateurs
interviennent peuvent tre envisages : L'observation auprs
d'utilisateurs ; Les rapports verbaux ; Les questionnaires.
Page 8
1.Observation auprs d'utilisateurs Le test ralis en situation
relle d'utilisation ou dans un laboratoire d'utilisabilit, est
dirig par un expert qui prend note des problmes d'utilisabilit
rencontrs par l'utilisateur test. Les donnes sont collectes et
enregistres au vol, avec un expert en utilisabilit notant ses
propres remarques ou les enregistrant, par exemple, sur cassettes
vido Pour tre optimales, de telles techniques requirent
l'implication de tous les intervenants, savoir les utilisateurs,
les experts en utilisabilit et les concepteurs du systme.
Page 9
1.Observation auprs d'utilisateurs Position de la mthode dans
le cycle de vie Cette technique ne peut tre utilise que lorsque le
systme est dans un tat avanc du dveloppement. Il est ncessaire de
disposer d'une interface ralise ou d'un prototype fonctionnel.
Page 10
Avantages Dsavantages L'observation auprs d'utilisateurs,
accomplie avec un nombre suffisant d'utilisateurs, donne
habituellement de bons rsultats en termes de problmes
d'utilisabilit trouvs. Un premier inconvnient de cette technique
est le temps requis. En effet, pour trouver un nombre satisfaisant
de problmes d'utilisabilit, de nombreux tests doivent tre conduits.
De plus, effectuer un seul test prend dj un temps considrable.
Ainsi, un test d'une heure enregistr sur cassettes video ncessite
une analyse par un expert en utilisabilit d'environ 10h. Pour une
seule tche ralise par l'utilisateur!
Page 11
Objectif et principe Le principe de cette mthode est simple
[LEWIS93] : l'expert en utilisabilit demande l'utilisateur
d'accomplir une tche ; l'utilisateur doit dire haute voix ce qu'il
pense lors de son interaction avec le systme, les questions qui lui
viennent l'esprit, les informations qu'il lit,...
Page 12
2.Rapports verbaux Comme l'observation auprs d'utilisateurs, la
mthode des rapports verbaux permet de collecter des informations
concernant l'valuation de l'interface. Durant le test, l'valuateur
doit noter : tous les lments trouvs par l'utilisateur comme
droutant dans l'excution de sa tche ; et si possible, leur origine.
L'valuateur ne doit pas garder un attitude passive durant le test.
Il doit forcer l'utilisateur lui donner un flux continu
d'informations en lui posant certaines questions comme : "A quoi
pensez-vous maintenant ?", "Pourquoi avez-vous choisi ce bouton
?",...
Page 13
2.Rapports verbaux Position de la mthode dans le cycle de vie
Cette mthode convient pour valuer l'interface tous les stades de
son dveloppement : du prototype papier l'interface termine.
Page 14
Avantages Dsavantages Cette approche est largement utilise dans
la conception logicielle : elle apporte des informations valables
et situe prcisment o les utilisateurs prouvent des difficults dans
l'interface. En effet, comme l'valuateur observe l'utilisateur
durant son interaction avec le systme, il peut noter non seulement
les moments de confusion et les vnements imprvus mais aussi
pourquoi ils se sont produits. Enfin, la connaissance du domaine de
l'valuation des IHM requise pour tre capable d'utiliser cette
mthode est relativement faible. L'analyse de rapport de rapports
verbaux est difficile tant donn que les rsultats dpendent de
l'interprtation des remarques des utilisateurs et de la facult de
l'utilisateur verbaliser ses penses. Le fait que les rponses des
utilisateurs puissent tre influences par la manire dont l'valuateur
leur pose les questions est un second dsavantage de cette
mthode.
Page 15
3. Questionnaires Les questionnaires sont des listes crites de
questions distribues aux utilisateurs afin qu'ils y rpondent aprs
un test de l'interface Le but des questionnaires est de collecter
des informations sur les impressions, sur le niveau de satisfaction
des utilisateurs aprs usage du systme. C'est donc une mthode a
posteriori. Position dans le cycle de vie Le questionnaire peut tre
utilis de manire complmentaire aux autres mthodes d'valuation, aprs
que les utilisateurs aient test le produit fini. Directement aprs
que les utilisateurs aient test le systme, il leur est demand de
dterminer leur niveau de satisfaction.
Page 16
Avantages Dsavantages En plus d'tre la moins chre, cette mthode
est galement la plus aisment utilise grande chelle. En effet, une
fois ralis, le questionnaire peut accompagner chaque test ralis sur
le systme. Malgr que cette mthode permette de collecter
l'information de manire peu coteuse, la difficult rside dans la
rdaction de bonnes questions ainsi que dans l'interprtation des
rponses des utilisateurs. Cette mthode est souvent utilise pour
collecter les feedback des utilisateurs ayant acquis le systme et
corriger ainsi les problmes dans les versions futures
Page 17
Evaluation sans utilisateur La mthode d'valuation avec
utilisateur n'est pas toujours possible, et ce, pour trois raisons
: les utilisateurs n'ont que trs peu de temps consacrer aux tests.
Le systme qui leur est propos ce moment doit dj comporter le moins
d'erreurs possibles. pour que les tests soient efficaces, il faut
qu'ils soient raliss par le plus grand nombre d'utilisateurs
possible, chaque utilisateur trouvant un sous-ensemble de problmes.
la mthode cote cher en terme de temps ncessaire l'analyse de chaque
test d'utilisateur.
Page 18
Evaluation sans utilisateur La mthode d'valuation sans
utilisateur comprend deux types de mthodes distinctes les mthodes
centres sur la tche :les mthodes non centres sur la tche : Goals,
Operators, Methods, and Selection Rules (GOMS ); Keystroke-Level
Model (KLM ); Cognitive Walkthrough. Heuristic Evaluation ;
Evaluation par recommandations ergonomiques.
Page 19
G.O.M.S. L'acronyme GOMS signifie Goals, Operators, Methods,
and Selection Rules. Goals Les "Goals" sont les buts que
l'utilisateur tente d'accomplir, habituellement spcifis de manire
hirarchique. La tche se dcompose en buts, sous-buts et sous-buts
lmentaires. Operators Les "Operators" reprsentent l'ensemble des
oprations de niveau atomique avec lesquelles l'utilisateur compose
une solution pour atteindre un but.
Page 20
G.O.M.S. Methods Les "Methods" reprsentent des squences
d'"Operators", regroups afin d'accomplir un but lmentaire.
Selection Rules Les Selection Rules sont utilises afin de dcider
quelle mthode est utiliser pour atteindre un but lorsque plusieurs
mthodes sont applicables Rgle "if... then". GOMS mesure la
performance, c'est dire le temps de ralisation de la tche, des
utilisateurs experts du systme. Le temps de ralisation de la tche
est obtenu en additionnant le temps de ralisation de chaque tape
ncessaire la ralisation la tche.
Page 21
Avantages [JOHN&KIERAS94] Dsavantages ne ncessite pas
d'interface aboutie ou de maquette : elle donne des prdictions.
value la complexit et l'efficacit des tches de l'interface. est
facilement comprise et utilise par les concepteurs tablit seulement
des prdictions sur le temps d'excution de tches effectues sans
erreurs. Elle ne permet pas de considrer un utilisateur novice. est
lourde mettre en oeuvre pour des tches importantes. Position dans
le cycle de vie GOMS est un modle prdictif utiliser trs tt dans le
cycle de dveloppement [FARENC97].
Page 22
K.L.M. Objectif et principes KLM est l'acronyme pour
"Keystroke-Level Model". KLM est l'anctre de GOMS. Etant centre sur
la tche, cette mthode force l'valuateur se concentrer sur la
squence d'actions accomplies par l'utilisateur. Le but est de
calculer le temps ncessaire. Pour le prdire, l'valuateur additionne
le temps requis pour raliser chaque tape physique pour accomplir la
tche. Au contraire de GOMS, cette mthode ne prend pas en
considration le temps consacr par l'utilisateur au choix des
actions et leur valuation, c.--d. les rgles de slection du modle
GOMS. L'valuateur doit avoir accs aux donnes concernant les temps
de prdiction de chaque tape physique. Ces donnes sont constitues en
mesurant le temps moyen d'accomplissement de chaque tape ou
manipulation, partir d'observations directes d'utilisateurs. Des
temps d'excution de tche excessivement lev en comparaison avec une
tche de complexit similaire peuvent rvler un problme.
Page 23
KLM est recommande pour les procdures utilises grande chelle.
Gagner un peu de temps pour une procdure excute des milliers de
fois en vaut la peine [LEWIS93]. Supposons deux systmes de
rservation de vols [SCHNEIDERMAN92] : Il faut rserver un sige sur
le vol A0821 de 15h (0300P) entre l'aroport de Washington (DCA) et
l'aroport de New York, La Guardia (LGA). Le premier systme
totalement en ligne de commande demanderait l'insertion de la
commande : A0821DCALGA0300P. Le second en mode semi-graphique
contiendrait un certain nombre de champs qui ferait qu'une fois
l'un rempli, il faudrait attendre, par exemple 1sec, avant de
passer au suivant : A0821 DCA LGA 0300P KLM peut donc valuer les
diffrences de performance entre ces deux systmes, l'intrt de la
compagnie arienne tant videmment le systme le plus rapide. On peut
noter que dans ce cas le taux d'erreurs, bien plus grand dans le
premier systme, n'est pas valu dans la mthode KLM. Des exemples de
KLM peuvent tre trouvs aux adresses suivantes :
http://bmrc.berkeley.edu/courseware/cs160/fall99/Book/contents.v-1.html
http://www.droit.univ-paris5.fr/HTMLpages/enseignants/staff/futtersack/
francais/ Enseignement/IHM/transparents/IHM1/sld037.ht
Page 24
Position dans le cycle de vie KLM est un modle prdictif
utiliser trs tt dans le cycle de dveloppement [FARENC97] Avantages
[JOHN&KIERAS94] Dsavantages Cette mthode peut facilement tre
utilise par un valuateur novice. Ne considrant que les tapes
physiques, KLM peut tre ralise presque automatiquement KLM est
lourde employer : une tche de quelques minutes doit tre traduite en
centaines d'tapes physiques. Comme dit prcdemment, KLM considre
uniquement les tapes physiques. Les tapes mentales ne sont pas
prises en compte
Page 25
Heuristic Evaluation Objectif et principes Heuristic Evaluation
est une mthode d'valuation o les lments de l'interface sont examins
en fonction d'une liste d'heuristiques d'utilisabilit : cette liste
peut correspondre tout ou partie de la liste des 10 heuristiques
d'utilisabilit de Nielsen ou tout ou partie de la liste des 8
critres de design.
Page 26
Les heuristiques d'utilit et d'utilisabilit sont des
caractristiques communes aux interfaces utiles utilisables. Ce sont
des principes gnraux pouvant s'appliquer pratiquement tout type
d'interface [NIELSEN 93]. La prise en compte de ces principes lors
de la conception de l'interface permet d'obtenir au mieux une
interface utile et utilisable. Nielsen dfinit 10 heuristiques
:
Page 27
Page 28
Les critres de design constituent une dimension reconnue sur le
chemin qui conduit l'laboration d'une interface utile et
utilisable. Ils forment le fondement des choix en matire de
conception des IHM. Ces critres de design sont aux nombre de 8
:
Page 29
Par opposition aux recommandations ergonomiques qui regroupent
gnralement des centaines de rgles, Heuristic Evaluation contient un
petit nombre de principes. Les problmes trouvs par cette technique
correspondent des violations de ces heuristiques.
Page 30
Position dans le cycle de vie L'utilisation d'Heuristic
Evaluation peut se faire ds que la prsentation de l'interface est
ralise [FARENC97]. Avantages Dsavantages Cette mthode ncessite peu
d'apprentissage de la part de l'valuateur ; Elle procure gnralement
de bons rsultats ; Le faible de nombre de principes respecter en
fait une mthode lgre et rapide ; Comme elle n'est pas centre sur la
tche, elle peut tre utilise trs tt dans le processus de conception.
Cette mthode n'offre pas beaucoup de guidance sur la manire de
raliser l'valuation. L'valuateur doit dcider par lui-mme comment
mener l'valuation.
Page 31
Evaluation par recommandations ergonomiques Objectif et
principes Les guides de recommandations ergonomiques rassemblent
gnralement des centaines de recommandations ergonomiques.
L'valuation consiste en l'examen systmatique de l'adquation de
l'interface ces listes de recommandations ergonomiques. Les
problmes rsultent de la non-conformit des caractristiques de
l'interface ces principes. La constitution de tels guides provient
de l'exprience et la connaissance des experts en utilisabilit. La
propre connaissance de l'valuateur l'aide appliquer ces
recommandations durant une valuation.
Page 32
Position dans le cycle de vie Elle peut tre utilise ds qu'une
version mme statique de l'interface est ralise [FARENC97].
Avantages Dsavantages Comme Heuristic Evaluation, cette mthode se
positionne trs tt dans le cycle de vie. Ds qu'une maquette ou un
prototype est disponible, elle/il peut tre valu. Aucune tche n'est
requise. Au vu de l'importance de l'exprience de l'valuateur pour
l'usage de cette mthode, les guides de recommandations ergonomiques
ne sont pas vraiment accessibles l'valuateur novice. De plus, le
passage en revue de centaines de recommandations pour chaque
caractristique de l'interface n'offre pas une mthode rapide et
agrable. Parce que l'mergence de nouvelles recommandations
ergonomiques est toujours postrieure l'apparition d'une nouvelle
technologie, cette mthode n'est pas adapte valuer des interfaces
qui utilisent ces nouvelles technologies.
Page 33
Mth. de la Cognitive Walkthrough (C.W.) Objectif et principes
La mthode d'valuation dite Cognitive Walkthrough est une mthode
d'valuation d'interface centre sur une tche. Elle vise donc mettre
en vidence les problmes d'utilisabilit rencontrs par un utilisateur
pendant l'accomplissement d'une tche donne [LAVERY&COCKTON97
Pour raliser une valuation par la mthode de "Cognitive
Walkthrough", l'analyste doit procder en trois phases
Page 34
Mth. de la Cognitive Walkthrough (C.W.) Phase I Dfinir un
scnario d'utilisation de l'interface valuer Un scnario est une
description de la faon dont une personne utiliserait le systme pour
raliser la tche. Phase II Jeu de questions/rponses Poser
systmatiquement un ensemble de questions pour chaque action
entreprendre pour raliser un sous but. Phase III Analyse des
rponses Analyser les rponses aux questions poses la phase 2 pour
dcouvrir les problmes d'utilisabilit rencontrs dans l'usage de
l'interface.
Page 35
Position dans le cycle de vie Puisque la methode Cognitive
Walkthrough n'oblige pas de disposer de l'interface finale, mais
peut dja tre utilise partir d'une maquette (ou d'un simple dessin)
de cette interface, cette mthode peut donc tre utilise trs tt dans
le cycle de vie de l'IHM (y compris ds la phase de design).
Page 36
Mth. de la Cognitive Walkthrough (C.W.) Position dans le cycle
de vie Puisque la methode Cognitive Walkthrough n'oblige pas de
disposer de l'interface finale, mais peut dja tre utilise partir
d'une maquette (ou d'un simple dessin) de cette interface, cette
mthode peut donc tre utilise trs tt dans le cycle de vie de l'IHM
(y compris ds la phase de design).
Page 37
Avantages Dsavantages 1. Sans recours l'intervention des
utilisateurs 2. Pragmatique 3. Elle peut s'utiliser diffrents
stades d'volution des IHM maquette papier interface statique
interface finale 4. Elle est constructive quand elle est utilise ds
l'tape de design de l'IHM car elle conduit construire une IHM
ergonomique 5. Elle force prendre en compte les lments essentiels
de la conception d'une IHM: analyse et structuration de la tche
connaissance du profil de l'utilisateur critres d'utilit et
d'utilisabilit 6. Parfaitement adaptable l'usage d'un logiciel
d'aide l'application de la mthode 1. Sa lourdeur mais celle-ci
peut-tre rduite si l'on rserve son usage aux tches principales les
plus frquement effectues et qu'elle est supporte par un logiciel
spcialis 2. La qualit des valuations obtenues est dpendante de la
comptence de l'analyste et essentiellemnt de sa capacit se mettre
la place de l'utilisateur
Page 38
Les entres de la C.W.
Page 39
Une interface ou un prototype analyser La maquette, le
prototype ou l'interface aboutie est ce qui doit tre valu en termes
d'utilit et utilisabilit. La maquette peut seulement consister en
une srie d'crans montrs l'utilisateur durant l'excution de la tche.
Mais, dans ce cas, certaines informations peuvent faire dfaut
comme, par exemple, le feedback fourni. Il est important de
spcifier quelle version de l'interface on value afin de pouvoir
diffrencier les valuations ralises sur diffrentes versions.
Page 40
Une tche analyser Cognitive Walkthrough est une mthode
d'valuation de l'utilisabilit centre sur la tche implmente, c.--d.
qu'elle value l'utilisabilit d'une interface en se focalisant
spcifiquement sur certaines tches supportes par le systme. Le
problme est donc de savoir quelle(s) tche(s) choisir pour
l'valuation. "Choosing the right tasks to examine is key, since
aspects of the interface not involved in the tasks that are chosen
will not be examined" [LEWIS97]. Cristophe Grosjean et Samuel Marin
[GROSJEAN&MARIN2000] nous proposent les rgles suivantes pour
effectuer un choix judicieux des (sous) tches valuer :
Page 41
Type de logicielChoix des tches analyser pour un logiciel
gnrique (traitement de texte, diteur d'images,...), applicable par
dfinition des situations qui peuvent tre radicalement diffrentes :
Un logiciel de traitement de texte peut tre utilis pour crire un
roman, une lettre, un formulaire, raliser des transparents avec
graphiques,... Les tches valuer doivent tre : les plus importantes,
c.--d. celles autour desquelles le systme fut construit. les plus
ralistes, c.--d. celles que l'utilisateur va accomplir le plus
frquemment. pour un logiciel spcifique (GPS,...), applicable des
tches bien dfinies dpendant d'un contexte d'utilisation, le mieux
est d'valuer les tches supportant les fonctionnalits importantes,
drives de l'analyse de la tche.
Page 42
Un contexte d'utilisation Les informations ncessaires
concernant le contexte d'utilisation sont : le strotype de
l'utilisateur ; le poste de travail.
Page 43
Strotypes des utilisateurs Le strotype de l'utilisateur dcrit
le profil des utilisateurs finaux de l'interface, en fonction des
utilisateurs potentiels considrs. Cette analyse doit rvler pour
chaque catgorie d'utilisateurs potentiels [VANDERDONCKT97] les
caractristiques suivantes :
Page 44
Page 45
Contexte de travail L'analyse du poste de travail va rvler :
l'environnement physique qui est consitu de : quipements ; univers
ambiant : lumineux, acoustique,... ; conditions de travail :
stress, perturbations, dlais,... l'allocation des tches personne ;
fonction ; rle. l'allocation mono- ou multi-traitement : indique
si, durant l'excution de la tche, d'autres activits sont ralises ou
non. Modalits d'excution d'une tche : niveaux d'interruptibilit,
d'interpntrabilit, de paralllisme qui permet une mesure de
complexit de l'excution.
Page 46
Des critres d'utilit et d'utilisabilit Les critres d'utilit et
utilisabilit, fournis par l'analyse de la tche, permettent d'valuer
la svrit des problmes trouvs. Les critres d'utilit et utilisabilit
sont indpendants de l'interface et donc de la tche implmente. Ils
sont tablis en fonction de la tche abstraite et du contexte de
travail (cfr. Analyse de la tche).
Page 47
C.W. PHASE I: Dfinition d'un scnario Dfinition d'un scnario
d'utilisation d'une interface ([LAVERY&COCKTON97],
[JOHNSON92]). Prem1ire Etape : Structuration de la tche concrte par
une dcomposition en buts et sous-buts
Page 48
Une dcomposition en but/sous-buts procde du but principal A. La
ralisation de ce but principal ncessite l'accomplissement de
plusieurs sous-buts (B, E et F). Certains de ces sous-buts
ncessitant eux-mmes d'tre dcomposs en sous-buts plus lmentaires. La
dcomposition s'arrte lorsqu'un but ne peut plus tre dcompos et
qu'il est ralis par l'accomplissement d'un ensemble d'actions.
Page 49
La mthode propose les rgles suivantes : Le but principal et les
sous-buts sont labelliss alphabtiquement : Le but principal est
toujours "A" ; Le premier sous-but de "A" est toujours "B". Le
premier sous-but d'un but est toujours le suivant dans l'ordre
alphabtique; Si un sous-but ne peut tre dcompos, le sous-but
suivant de mme niveau est le suivant alphabtiquement ; Quand tous
les sous-buts de mme niveau ont t marqus, le sous-but suivant est
le premier non labellis du niveau suprieur.
Page 50
2ime Etape : Description de toutes les actions composant les
sous-buts de derniers niveaux Une action consiste en une opration
excute par l'utilisateur via un moyen d'interaction (clavier,
souris,...). De plus, l'action doit avoir un impact sur l'interface
(quand elle dclenche un feedback) et/ou sur l'tat du systme. Pour
chaque sous-but non dcomposable, la mthode Cognitive Walkthrough
propose de remplir un formulaire qui fournit une description de la
squence d'actions le composant. Ce formulaire a la forme
suivante:
Page 51
C.W. PHASE II : Jeu de Questions/Rponses La mthode d'valuation
Cognitive Walkthrough procde d'un ensemble de questions poser
systmatiquement pour chaque lment de la structuration de la tche.
Rpondre ces questions permet de dcouvrir des problmes
d'utilisabilit. Ces questions permettent d'valuer l'cart existant
entre l'univers physique et les variables psychologiques, cart mis
en vidence par le modle de Norman.
Page 52
Ces questions se regroupent en deux catgories :
Page 53
L'valuateur devra toujours rpondre aux diffrentes questions en
se mettant la place de l'utilisateur dont il a dfini le profil et
le contexte de travail.
Page 54
Questions relatives aux sous-buts Les deux premires questions
de la mthode concernent la structuration de la tche en
but/sous-buts. Elles permettent d'identifier l'cart entre la
structure de la tche abstraite, telle que pense par l'utilisateur,
et la structure de la tche concrte, telle qu'implmente dans le
systme Cet cart peut se traduire par un squencement diffrent des
sous-buts ou encore par des sous-buts supplmentaires imposs par
l'interface. Ces questions sont se poser pour chaque sous-buts de
la dcomposition :
Page 55
Page 56
Question 1 L'utilisateur va-t-il essayer de raliser le sous-but
adquat ? Explication de la questionCette question concerne
l'intention que l'utilisateur a de raliser le sous-but impos par
l'interface. Le sous-but "adquat" est le suivant (dans l'ordre
alphabtique) dans la structure concrte de buts. Cette question met
en vidence la distance entre la structure de la tche abstraite et
concrte : si la distance est trop importante, l'utilisateur ne
saura probablement pas quel est le sous-but adquat accomplir ;
toutefois, l'interface peut fournir des informations permettant de
savoir quel est ce sous-but.
Page 57
Comment rpondre la question ? L'valuateur estime que
l'utilisateur peut essayer de raliser le sous-but adquat en se
basant, par exemple, sur une des justifications suivantes : Par
exprience du systme ou d'un systme similaire Par exemple, par
connaissance de la manipulation de la souris dans Windows. Par
exprience de la tche sur un systme prcdent ou un autre systme ; Par
exprience de la tche abstraite ; Si la structure concrte des
sous-buts telle qu'implmente dans l'interface correspond, pour le
sous-but considr, la structure abstraite telle que pense par
l'utilisateur, l'utilisateur saura donc quel sous- but raliser par
exprience de la tche abstraite. Parce que le systme lui indique,
par exemple par un dialogue modal..
Page 58
Position de la question dans le modle de Norman Les 3 premires
tapes du modle de Norman sont couvertes par cette question. Aprs
avoir ralis un sous-but par l'xcution d'une squence d'actions,
interprt le rsultat obtenu, l'utilisateur slectionne le prochain
sous-but raliser pour l'itration suivante.
Page 59
Question 2 Quelle est la connaissance requise pour raliser le
sous-but adquat ? L'utilisateur aura-t-il cette connaissance ?
Explication de la question Alors que la premire question consiste
savoir si l'utilisateur va essayer de raliser le sous-but adquat,
cette question vise dterminer s'il sera capable de le faire. Donc,
il faut savoir si l'utilisateur sait comment raliser le sous-but ou
si le systme lui donne les informations ncessaires pour le faire.
Si une rponse affirmative est donne, l'valuation peut se poursuivre
normalement. Si une rponse ngative est donne, l'valuateur doit
savoir exactement quelle partie de la connaissance requise fait
dfaut l'utilisateur, c.--d. quel est le sous-but ou action
concern.
Page 60
Comment rpondre la question ?L'utilisateur possde cette
connaissance : Par exprience du systme ou d'un systme similaire ;
Parce que le systme lui fournit la connaissance ncessaire ; Par
exprience de la tche sur un systme prcdent ou un autre
systme....
Page 61
Position de la question dans le modle de Norman Pour les
sous-buts non dcomposables, cette question adresse la connaissance
de l'utilisateur relative la squence d'action raliser pour
accomplir le sous- but. Cette question concerne donc les points A
et B de la "Spcification de la squence d'action" du modle de
Norman.
Page 62
Questions relatives aux actions Aprs avoir rpondu aux questions
relatives aux sous-buts pour un sous-but non dcomposable, l'analyse
doit parcourir la squence d'actions qui le ralise. Les questions
relatives aux actions sont :
Page 63
C.W. PHASE III : Analyse des rponses Une fois que l'valuateur a
rpondu toutes les questions pour les sous-buts et actions, il doit
analyser les problmes d'utilisabilit trouvs. Les problmes sont
associs aux rponses ngatives renontres durant le jeu de questions
et rponse de la phase II. Les informations donner sont les
suivantes : Le numro du problme ; Le point d'interaction o est
apparu le problme : But/Sous-but(s)/action ; La description du
problme et pourquoi c'est un problme ; Cause du problme ; Comment
avez-vous trouv le problme ? Quelle est la question qui a permis de
le dcouvrir ? L'importance des problmes rencontrs sera apprcie en
fonction de la pondration accorde aux critres d'utilit et
utilisabilit. Si le taux d'erreurs pour une application doit tre
nul et si la mthode a rvl une forte probabilit d'erreurs un moment
donn de l'excution de la tche, alors ce problme est srieux.
Page 64
bibliographie [FARENC97] C. Farenc 1997, "Ergoval : une mthode
de structuration des rgles ergonomiques permettant l'valuation
automatique d'interfaces graphiques", thse de doctorat, Universit
de Toulouse 1. [GROSJEAN&MARIN2000] Christophe Grosjean, Samuel
Marin, 2000. " Critical study of a usability inspection method :
the Cognitive Walkthrough ", mmoire, FUNDP Institut d'Informatique.
[JOHN&KIERAS94] Bonnie E.John, David E.Kieras, " The GOMS
family of analysis techniques : tools for design and evaluation ",
Carnegie Mellon, University School of Computer Science. Technical
Report CMU-CS-94-181. Disponible
ftp://reports.adm.cs.cmu.edu/usr/anon/1994/CMU-CS-94-181.ps
[JOHNSON92] P.Johnson, 1992. " Human Computer Interaction ", Mac
Graw-Hill. [LAVERY&COCKTON97] Darryn Lavery, Gilbert Cockton
1997. " Cognitive Walkthrough Usability Evaluation Materials ".
Technical Report TR-1997-20, University of Glasgow. Disponible
http://www.dcs.gla.ac.uk/~darryn/research/publications/TR-1997-20/.
[LEWIS93] Clayton Lewis, John Rieman 1993. "Task-centered user
interface design, a practical introduction". Disponible
ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-Design-Book/.
[SHNEIDERMAN 92] B. Shneiderman, " Designing the User Interface :
Strategies for Effective Human-Computer Interaction ", p284,
Addison-Wesley, 1992, 3rd Edition.