L'évaluation d'une interface consiste à mesurer l'utilité et l'utilisabilité du système. Une évaluation permet de découvrir les problèmes qui pourraient

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].

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].

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].

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]

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.

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.

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.

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.

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!

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,...

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 ?",...

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.

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.

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.

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

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.

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.

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.

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.

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].

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.

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

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

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.

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 :

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 :

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.

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.

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.

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.

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

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.

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).

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).

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

Les entres de la C.W.

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.

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 :

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.

Un contexte d'utilisation Les informations ncessaires concernant le contexte d'utilisation sont : le strotype de l'utilisateur ; le poste de travail.

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 :

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.

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).

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

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.

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.

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:

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.

Ces questions se regroupent en deux catgories :

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.

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 :

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.

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..

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.

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.

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....

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.

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 :

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.

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.

Documents

L'évaluation d'une interface consiste à mesurer l'utilité et l'utilisabilité du système. Une évaluation permet de découvrir les problèmes qui pourraient