Evaluation (suite).

Présentation au sujet: "Evaluation (suite)."— Transcription de la présentation:

1 Evaluation (suite)

2 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 empêcher les utilisateurs d'accomplir leurs tâches. Les problèmes d'utilisabilité sont des aspects du système pouvant réduire l'usage du système pour l'utilisateur, par exemple en le déroutant, ralentissant ou stoppant l'exécution de sa tâche [LAVERY&COCKTON97].

3 De nombreuses techniques permettent de réaliser cette évaluation
De nombreuses techniques permettent de réaliser cette évaluation. Les différences entre les techniques concernent leur centre d'intérêt, la personne responsable pour l'évaluation, la présence d'utilisateurs,... Chaque méthode d'évaluation priviliégie un ou plusieurs critères d'utilité et utilisabilité à travers la mesure de différentes variables : la durée d'exécution, le taux d'erreurs,... [FARENC97].

4 Nous allons d'abord faire un rapide tour d'horizon des différentes techniques existantes. Ensuite, nous concentrerons notre attention sur une méthode d'évaluation particulière : Cognitive Walkthrough. Lewis et Rieman classifient les techniques d'évaluation en deux groupes : les techniques avec utilisateur et celles sans utilisateur [LEWIS93].

5 Evaluation avec utilisateur
Comme le système conçu par le processus de design doit permettre aux utilisateurs de réaliser leur tâche, la non-implication des utilisateurs dans ce processus de design est impensable. Peu importe la qualité de l'analyse effectuée lors de la conception d'une interface, l'expérience a montré que de nombreux défauts d'utilisabilité n'apparaitront qu'à l'occasion des tests effectués avec des utilisateurs. Le profil de ces utilisateurs doit être semblable à ceux des utilisateurs finaux du système. [LEWIS93]

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-mêmes.

7 Evaluation avec utilisateur
L'évalution avec utilisateur est probablement la meilleure méthode pour trouver les problèmes d'utilisabilité causés par une interface. Un utilisateur est placé devant une interface et doit essayer d'accomplir une ou plusieurs tâches que le système est censé supporter. Comme dit précédemment, les utilisateurs qui participeront aux tests doivent être choisis de manière appropriée. Trois techniques de tests où les utilisateurs interviennent peuvent être envisagées : L'observation auprès d'utilisateurs ; Les rapports verbaux ; Les questionnaires.

8 1.Observation auprès d'utilisateurs
Le test réalisé en situation réelle d'utilisation ou dans un laboratoire d'utilisabilité, est dirigé par un expert qui prend note des problèmes d'utilisabilité rencontrés par l'utilisateur test. Les données sont collectées et enregistrées au vol, avec un expert en utilisabilité notant ses propres remarques ou les enregistrant, par exemple, sur cassettes vidéo Pour être optimales, de telles techniques requièrent l'implication de tous les intervenants, à savoir les utilisateurs, les experts en utilisabilité et les concepteurs du système.

9 1.Observation auprès d'utilisateurs
Position de la méthode dans le cycle de vie Cette technique ne peut être utilisée que lorsque le système est dans un état avancé du développement. Il est nécessaire de disposer d'une interface réalisée ou d'un prototype fonctionnel.

10 Avantages Désavantages
L'observation auprès d'utilisateurs, accomplie avec un nombre suffisant d'utilisateurs, donne habituellement de bons résultats en termes de problèmes d'utilisabilité trouvés. Un premier inconvénient de cette technique est le temps requis. En effet, pour trouver un nombre satisfaisant de problèmes d'utilisabilité, de nombreux tests doivent être conduits. De plus, effectuer un seul test prend déjà un temps considérable. Ainsi, un test d'une heure enregistré sur cassettes video nécessite une analyse par un expert en utilisabilité d'environ 10h. Pour une seule tâche réalisée par l'utilisateur!

11 2.Rapports verbaux Objectif et principe
Le principe de cette méthode est simple [LEWIS93] : l'expert en utilisabilité demande à l'utilisateur d'accomplir une tâche ; l'utilisateur doit dire à haute voix ce qu'il pense lors de son interaction avec le système, les questions qui lui viennent à l'esprit, les informations qu'il lit,...

12 2.Rapports verbaux Comme l'observation auprès d'utilisateurs, la méthode des rapports verbaux permet de collecter des informations concernant l'évaluation de l'interface. Durant le test, l'évaluateur doit noter : tous les éléments trouvés par l'utilisateur comme déroutant dans l'exécution de sa tâche ; 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 ?", ...

13 2.Rapports verbaux Position de la méthode dans le cycle de vie
Cette méthode convient pour évaluer l'interface à tous les stades de son développement : du prototype papier à l'interface terminée.

14 Avantages Désavantages
Cette approche est largement utilisée dans la conception logicielle : elle apporte des informations valables et situe précisément où les utilisateurs éprouvent des difficultés dans l'interface. En effet, comme l'évaluateur observe l'utilisateur durant son interaction avec le système, il peut noter non seulement les moments de confusion et les évènements imprévus mais aussi pourquoi ils se sont produits. Enfin, la connaissance du domaine de l'évaluation des IHM requise pour être capable d'utiliser cette méthode est relativement faible. L'analyse de rapport de rapports verbaux est difficile étant donné que les résultats dépendent de l'interprétation des remarques des utilisateurs et de la faculté de l'utilisateur à verbaliser ses pensées. Le fait que les réponses des utilisateurs puissent être influencées par la manière dont l'évaluateur leur pose les questions est un second désavantage de cette méthode.

15 3. Questionnaires Position dans le cycle de vie
Les questionnaires sont des listes écrites de questions distribuées aux utilisateurs afin qu'ils y répondent après un test de l'interface Le but des questionnaires est de collecter des informations sur les impressions, sur le niveau de satisfaction des utilisateurs après usage du système. C'est donc une méthode a posteriori. Position dans le cycle de vie Le questionnaire peut être utilisé de manière complémentaire aux autres méthodes d'évaluation, après que les utilisateurs aient testé le produit fini. Directement après que les utilisateurs aient testé le système, il leur est demandé de déterminer leur niveau de satisfaction.

16 Avantages Désavantages
En plus d'être la moins chère, cette méthode est également la plus aisément utilisée à grande échelle. En effet, une fois réalisé, le questionnaire peut accompagner chaque test réalisé sur le système. Malgré que cette méthode permette de collecter l'information de manière peu coûteuse, la difficulté réside dans la rédaction de bonnes questions ainsi que dans l'interprétation des réponses des utilisateurs. Cette méthode est souvent utilisée pour collecter les feedback des utilisateurs ayant acquis le système et corriger ainsi les problèmes dans les versions futures

17 Evaluation sans utilisateur
La méthode d'évaluation avec utilisateur n'est pas toujours possible, et ce, pour trois raisons : les utilisateurs n'ont que très peu de temps à consacrer aux tests. Le système qui leur est proposé à ce moment doit déjà comporter le moins d'erreurs possibles. pour que les tests soient efficaces, il faut qu'ils soient réalisés par le plus grand nombre d'utilisateurs possible, chaque utilisateur trouvant un sous-ensemble de problèmes. la méthode coûte cher en terme de temps nécessaire à l'analyse de chaque test d'utilisateur.

18 Evaluation sans utilisateur
La méthode d'évaluation sans utilisateur comprend deux types de méthodes distinctes les méthodes centrées sur la tâche : les méthodes non centrées sur la tâche : Goals, Operators, Methods, and Selection Rules (GOMS ); Keystroke-Level Model (KLM ); Cognitive Walkthrough. Heuristic Evaluation ; Evaluation par recommandations ergonomiques.

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 spécifiés de manière hiérarchique. La tâche se décompose en buts, sous-buts et sous-buts élémentaires. Operators Les "Operators" représentent l'ensemble des opérations de niveau atomique avec lesquelles l'utilisateur compose une solution pour atteindre un but.

20 G.O.M.S. Methods Selection Rules
Les "Methods" représentent des séquences d'"Operators", regroupés afin d'accomplir un but élémentaire. Selection Rules Les Selection Rules sont utilisées afin de décider quelle méthode est à utiliser pour atteindre un but lorsque plusieurs méthodes sont applicables Règle "if... then". GOMS mesure la performance, c'est à dire le temps de réalisation de la tâche, des utilisateurs experts du système. Le temps de réalisation de la tâche est obtenu en additionnant le temps de réalisation de chaque étape nécessaire à la réalisation la tâche.

21 Avantages Désavantages Position dans le cycle de vie
GOMS est un modèle prédictif à utiliser très tôt dans le cycle de développement [FARENC97]. Avantages [JOHN&KIERAS94] Désavantages ne nécessite pas d'interface aboutie ou de maquette : elle donne des prédictions. évalue la complexité et l'efficacité des tâches de l'interface. est facilement comprise et utilisée par les concepteurs établit seulement des prédictions sur le temps d'exécution de tâches effectuées sans erreurs. Elle ne permet pas de considérer un utilisateur novice. est lourde à mettre en oeuvre pour des tâches importantes.

22 K.L.M. Objectif et principes
KLM est l'acronyme pour "Keystroke-Level Model". KLM est l'ancêtre de GOMS. Etant centrée sur la tâche, cette méthode force l'évaluateur à se concentrer sur la séquence d'actions accomplies par l'utilisateur. Le but est de calculer le temps nécessaire. Pour le prédire, l'évaluateur additionne le temps requis pour réaliser chaque étape physique pour accomplir la tâche. Au contraire de GOMS, cette méthode ne prend pas en considération le temps consacré par l'utilisateur au choix des actions et à leur évaluation, c.-à-d. les règles de sélection du modèle GOMS. L'évaluateur doit avoir accès aux données concernant les temps de prédiction de chaque étape physique. Ces données sont constituées en mesurant le temps moyen d'accomplissement de chaque étape ou manipulation, à partir d'observations directes d'utilisateurs. Des temps d'exécution de tâche excessivement élevé en comparaison avec une tâche de complexité similaire peuvent révéler un problème.

23 KLM est recommandée pour les procédures utilisées à grande échelle
KLM est recommandée pour les procédures utilisées à grande échelle. Gagner un peu de temps pour une procédure exécutée des milliers de fois en vaut la peine [LEWIS93]. Supposons deux systèmes de réservation de vols [SCHNEIDERMAN92] : Il faut réserver un siège sur le vol A0821 de 15h (0300P) entre l'aéroport de Washington (DCA) et l'aéroport de New York, La Guardia (LGA). Le premier système 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 différences de performance entre ces deux systèmes, l'intérêt de la compagnie aérienne étant évidemment le système le plus rapide. On peut noter que dans ce cas le taux d'erreurs, bien plus grand dans le premier système, n'est pas évalué dans la méthode KLM. Des exemples de KLM peuvent être trouvés aux adresses suivantes : francais/ Enseignement/IHM/transparents/IHM1/sld037.ht

24 Position dans le cycle de vie KLM est un modèle prédictif à utiliser très tôt dans le cycle de développement [FARENC97] Avantages [JOHN&KIERAS94] Désavantages Cette méthode peut facilement être utilisée par un évaluateur novice. Ne considérant que les étapes physiques, KLM peut être réalisée presque automatiquement KLM est lourde à employer : une tâche de quelques minutes doit être traduite en centaines d'étapes physiques. Comme dit précédemment, KLM considère uniquement les étapes physiques. Les étapes mentales ne sont pas prises en compte

25 Heuristic Evaluation Objectif et principes
Heuristic Evaluation est une méthode d'évaluation où les éléments de l'interface sont examinés 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 critères de design .

26 Les heuristiques d'utilité et d'utilisabilité sont des caractéristiques communes aux interfaces utiles utilisables. Ce sont des principes généraux 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 définit 10 heuristiques :

27

28 Les critères 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 matière de conception des IHM. Ces critères de design sont aux nombre de 8 :

29 Par opposition aux recommandations ergonomiques qui regroupent généralement des centaines de règles, Heuristic Evaluation contient un petit nombre de principes. Les problèmes trouvés par cette technique correspondent à des violations de ces heuristiques.

30 Avantages Désavantages
Position dans le cycle de vie L'utilisation d'Heuristic Evaluation peut se faire dès que la présentation de l'interface est réalisée [FARENC97]. Avantages Désavantages Cette méthode nécessite peu d'apprentissage de la part de l'évaluateur ; Elle procure généralement de bons résultats ; Le faible de nombre de principes à respecter en fait une méthode légère et rapide ; Comme elle n'est pas centrée sur la tâche, elle peut être utilisée très tôt dans le processus de conception. Cette méthode n'offre pas beaucoup de guidance sur la manière de réaliser l'évaluation. L'évaluateur doit décider par lui-même comment mener l'évaluation.

31 Evaluation par recommandations ergonomiques
Objectif et principes Les guides de recommandations ergonomiques rassemblent généralement des centaines de recommandations ergonomiques. L'évaluation consiste en l'examen systématique de l'adéquation de l'interface à ces listes de recommandations ergonomiques. Les problèmes résultent de la non-conformité des caractéristiques de l'interface à ces principes. La constitution de tels guides provient de l'expérience et la connaissance des experts en utilisabilité. La propre connaissance de l'évaluateur l'aide à appliquer ces recommandations durant une évaluation.

32 Position dans le cycle de vie Elle peut être utilisée dès qu'une version même statique de l'interface est réalisée [FARENC97]. Avantages Désavantages Comme Heuristic Evaluation, cette méthode se positionne très tôt dans le cycle de vie. Dès qu'une maquette ou un prototype est disponible, elle/il peut être évalué. Aucune tâche n'est requise. Au vu de l'importance de l'expérience de l'évaluateur pour l'usage de cette méthode, 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 caractéristique de l'interface n'offre pas une méthode rapide et agréable. Parce que l'émergence de nouvelles recommandations ergonomiques est toujours postérieure à l'apparition d'une nouvelle technologie, cette méthode n'est pas adaptée à évaluer des interfaces qui utilisent ces nouvelles technologies.

33 Méth. de la Cognitive Walkthrough (C.W.)
Objectif et principes La méthode d'évaluation dite Cognitive Walkthrough est une méthode d'évaluation d'interface centrée sur une tâche. Elle vise donc à mettre en évidence les problèmes d'utilisabilité rencontrés par un utilisateur pendant l'accomplissement d'une tâche donnée [LAVERY&COCKTON97 Pour réaliser une évaluation par la méthode de "Cognitive Walkthrough", l'analyste doit procéder en trois phases

34 Méth. de la Cognitive Walkthrough (C.W.)
Phase I Définir un scénario d'utilisation de l'interface à évaluer Un scénario est une description de la façon dont une personne utiliserait le système pour réaliser la tâche. Phase II Jeu de questions/réponses Poser systématiquement un ensemble de questions pour chaque action à entreprendre pour réaliser un sous but. Phase III Analyse des réponses Analyser les réponses aux questions posées à la phase 2 pour découvrir les problèmes d'utilisabilité rencontrés dans l'usage de l'interface.

35 Position dans le cycle de vie
Puisque la methode Cognitive Walkthrough n'oblige pas de disposer de l'interface finale, mais peut déja être utilisée à partir d'une maquette (ou d'un simple dessin) de cette interface, cette méthode peut donc être utilisée très tôt dans le cycle de vie de l'IHM (y compris dès la phase de design).

36 Méth. 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 déja être utilisée à partir d'une maquette (ou d'un simple dessin) de cette interface, cette méthode peut donc être utilisée très tôt dans le cycle de vie de l'IHM (y compris dès la phase de design).

37 Avantages Désavantages
1. Sans recours à l'intervention des utilisateurs 2. Pragmatique 3. Elle peut s'utiliser différents stades d'évolution des IHM maquette papier interface statique interface finale 4. Elle est constructive quand elle est utilisée dès l'étape de design de l'IHM car elle conduit à construire une IHM ergonomique 5. Elle force à prendre en compte les éléments essentiels de la conception d'une IHM: analyse et structuration de la tâche connaissance du profil de l'utilisateur critères d'utilité et d'utilisabilité 6. Parfaitement adaptable à l'usage d'un logiciel d'aide à l'application de la méthode 1. Sa lourdeur mais celle-ci peut-être réduite si l'on réserve son usage aux tâches principales les plus fréquement effectuées et qu'elle est supportée par un logiciel spécialisé 2. La qualité des évaluations obtenues est dépendante de la compétence de l'analyste et essentiellemnt de sa capacité à se mettre à la place de l'utilisateur

38 Les entrées de la C.W.

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 série d'écrans montrés à l'utilisateur durant l'exécution de la tâche. Mais, dans ce cas, certaines informations peuvent faire défaut comme, par exemple, le feedback fourni. Il est important de spécifier quelle version de l'interface on évalue afin de pouvoir différencier les évaluations réalisées sur différentes versions.

40 Une tâche à analyser Cognitive Walkthrough est une méthode d'évaluation de l'utilisabilité centrée sur la tâche implémentée, c.-à-d. qu'elle évalue l'utilisabilité d'une interface en se focalisant spécifiquement sur certaines tâches supportées par le système. Le problème est donc de savoir quelle(s) tâche(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 règles suivantes pour effectuer un choix judicieux des (sous) tâches à évaluer :

41 Type de logiciel Choix des tâches à analyser pour un logiciel générique (traitement de texte, éditeur d'images,...), applicable par définition à des situations qui peuvent être radicalement différentes : Un logiciel de traitement de texte peut être utilisé pour écrire un roman, une lettre, un formulaire, réaliser des transparents avec graphiques,... Les tâches à évaluer doivent être : les plus importantes, c.-à-d. celles autour desquelles le système fut construit. les plus réalistes, c.-à-d. celles que l'utilisateur va accomplir le plus fréquemment. pour un logiciel spécifique (GPS,...), applicable à des tâches bien définies dépendant d'un contexte d'utilisation, le mieux est d'évaluer les tâches supportant les fonctionnalités importantes, dérivées de l'analyse de la tâche.

42 Un contexte d'utilisation
Les informations nécessaires concernant le contexte d'utilisation sont : le stéréotype de l'utilisateur ; le poste de travail.

43 Stéréotypes des utilisateurs
Le stéréotype de l'utilisateur décrit le profil des utilisateurs finaux de l'interface, en fonction des utilisateurs potentiels considérés. Cette analyse doit révéler pour chaque catégorie d'utilisateurs potentiels [VANDERDONCKT97] les caractéristiques suivantes :

44

45 Contexte de travail L'analyse du poste de travail va révéler :
l'environnement physique qui est consitué de : équipements ; univers ambiant : lumineux, acoustique,... ; conditions de travail : stress, perturbations, délais,... l'allocation des tâches personne ; fonction ; rôle. l'allocation mono- ou multi-traitement : indique si, durant l'exécution de la tâche, d'autres activités sont réalisées ou non. Modalités d'exécution d'une tâche : niveaux d'interruptibilité, d'interpénétrabilité, de parallélisme qui permet une mesure de complexité de l'exécution.

46 Des critères d'utilité et d'utilisabilité
Les critères d'utilité et utilisabilité, fournis par l'analyse de la tâche, permettent d'évaluer la sévérité des problèmes trouvés. Les critères d'utilité et utilisabilité sont indépendants de l'interface et donc de la tâche implémentée. Ils sont établis en fonction de la tâche abstraite et du contexte de travail (cfr. Analyse de la tâche).

47 C.W. PHASE I: Définition d'un scénario
Définition d'un scénario d'utilisation d'une interface ([LAVERY&COCKTON97], [JOHNSON92]). Prem1ière Etape : Structuration de la tâche concrète par une décomposition en buts et sous-buts

48 Une décomposition en but/sous-buts procède du but principal A
Une décomposition en but/sous-buts procède du but principal A. La réalisation de ce but principal nécessite l'accomplissement de plusieurs sous-buts (B, E et F). Certains de ces sous-buts nécessitant eux-mêmes d'être décomposés en sous-buts plus élémentaires. La décomposition s'arrête lorsqu'un but ne peut plus être décomposé et qu'il est réalisé par l'accomplissement d'un ensemble d'actions.

49 La méthode propose les règles suivantes :
Le but principal et les sous-buts sont labellisés alphabétiquement : 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 alphabétique; Si un sous-but ne peut être décomposé, le sous-but suivant de même niveau est le suivant alphabétiquement ; Quand tous les sous-buts de même niveau ont été marqués, le sous-but suivant est le premier non labellisé du niveau supérieur.

50 2ième Etape : Description de toutes les actions composant les sous-buts de derniers niveaux Une action consiste en une opération exécutée par l'utilisateur via un moyen d'interaction (clavier, souris,...). De plus, l'action doit avoir un impact sur l'interface (quand elle déclenche un feedback) et/ou sur l'état du système. Pour chaque sous-but non décomposable, la méthode Cognitive Walkthrough propose de remplir un formulaire qui fournit une description de la séquence d'actions le composant. Ce formulaire a la forme suivante:

51 C.W. PHASE II : Jeu de Questions/Réponses
La méthode d'évaluation Cognitive Walkthrough procède d'un ensemble de questions à poser systématiquement pour chaque élément de la structuration de la tâche. Répondre à ces questions permet de découvrir des problèmes d'utilisabilité. Ces questions permettent d'évaluer l'écart existant entre l'univers physique et les variables psychologiques, écart mis en évidence par le modèle de Norman.

52 Ces questions permettent d'évaluer l'écart existant entre l'univers physique et les variables psychologiques, écart mis en évidence par le modèle de Norman. Ces questions se regroupent en deux catégories :

53 L'évaluateur devra toujours répondre aux différentes questions en se mettant à la place de l'utilisateur dont il a défini le profil et le contexte de travail.

54 Questions relatives aux sous-buts
Les deux premières questions de la méthode concernent la structuration de la tâche en but/sous-buts. Elles permettent d'identifier l'écart entre la structure de la tâche abstraite, telle que pensée par l'utilisateur, et la structure de la tâche concrète, telle qu'implémentée dans le système Cet écart peut se traduire par un séquencement différent des sous-buts ou encore par des sous-buts supplémentaires imposés par l'interface. Ces questions sont à se poser pour chaque sous-buts de la décomposition :

55

56 Question 1 L'utilisateur va-t-il essayer de réaliser le sous-but adéquat ?
Explication de la question Cette question concerne l'intention que l'utilisateur a de réaliser le sous-but imposé par l'interface. Le sous-but "adéquat" est le suivant (dans l'ordre alphabétique) dans la structure concrète de buts. Cette question met en évidence la distance entre la structure de la tâche abstraite et concrète : si la distance est trop importante, l'utilisateur ne saura probablement pas quel est le sous-but adéquat à accomplir ; toutefois, l'interface peut fournir des informations permettant de savoir quel est ce sous-but.

57 Comment répondre à la question ?
L'évaluateur estime que l'utilisateur peut essayer de réaliser le sous-but adéquat en se basant, par exemple, sur une des justifications suivantes : Par expérience du système ou d'un système similaire Par exemple, par connaissance de la manipulation de la souris dans Windows. Par expérience de la tâche sur un système précédent ou un autre système ; Par expérience de la tâche abstraite ; Si la structure concrète des sous-buts telle qu'implémentée dans l'interface correspond, pour le sous-but considéré, à la structure abstraite telle que pensée par l'utilisateur, l'utilisateur saura donc quel sous-but réaliser par expérience de la tâche abstraite. Parce que le système lui indique , par exemple par un dialogue modal ..

58 Position de la question dans le modèle de Norman
Les 3 premières étapes du modèle de Norman sont couvertes par cette question. Après avoir réalisé un sous-but par l'éxécution d'une séquence d'actions, interprété le résultat obtenu, l'utilisateur sélectionne le prochain sous-but à réaliser pour l'itération suivante.

59 Question 2 Quelle est la connaissance requise pour réaliser le sous-but adéquat ? L'utilisateur aura-t-il cette connaissance ? Explication de la question Alors que la première question consiste à savoir si l'utilisateur va essayer de réaliser le sous-but adéquat, cette question vise à déterminer s'il sera capable de le faire. Donc, il faut savoir si l'utilisateur sait comment réaliser le sous-but ou si le système lui donne les informations nécessaires pour le faire. Si une réponse affirmative est donnée, l'évaluation peut se poursuivre normalement. Si une réponse négative est donnée, l'évaluateur doit savoir exactement quelle partie de la connaissance requise fait défaut à l'utilisateur, c.-à-d. quel est le sous-but ou action concerné.

60 Comment répondre à la question ?
L'utilisateur possède cette connaissance : Par expérience du système ou d'un système similaire ; Parce que le système lui fournit la connaissance nécessaire ; Par expérience de la tâche sur un système précédent ou un autre système. ...

61 Position de la question dans le modèle de Norman
Pour les sous-buts non décomposables, cette question adresse la connaissance de l'utilisateur relative à la séquence d'action à réaliser pour accomplir le sous-but. Cette question concerne donc les points A et B de la "Spécification de la séquence d'action" du modèle de Norman.

62 Questions relatives aux actions
Après avoir répondu aux questions relatives aux sous-buts pour un sous-but non décomposable, l'analyse doit parcourir la séquence d'actions qui le réalise. Les questions relatives aux actions sont :

63 C.W. PHASE III : Analyse des réponses
Une fois que l'évaluateur a répondu à toutes les questions pour les sous-buts et actions, il doit analyser les problèmes d'utilisabilité trouvés. Les problèmes sont associés aux réponses négatives renontrées durant le jeu de questions et réponse de la phase II. Les informations à donner sont les suivantes : Le numéro du problème ; Le point d'interaction où est apparu le problème : But/Sous-but(s)/action ; La description du problème et pourquoi c'est un problème ; Cause du problème ; Comment avez-vous trouvé le problème ? Quelle est la question qui a permis de le découvrir ? L'importance des problèmes rencontrés sera appréciée en fonction de la pondération accordée aux critères d'utilité et utilisabilité. Si le taux d'erreurs pour une application doit être nul et si la méthode a révélé une forte probabilité d'erreurs à un moment donné de l'exécution de la tâche, alors ce problème est sérieux.

64 bibliographie [FARENC97] C. Farenc 1997, "Ergoval : une méthode de structuration des règles ergonomiques permettant l'évaluation automatique d'interfaces graphiques", thèse de doctorat, Université de Toulouse 1. [GROSJEAN&MARIN2000] Christophe Grosjean, Samuel Marin, " Critical study of a usability inspection method : the Cognitive Walkthrough ", mémoire, 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 Disponible à ftp://reports.adm.cs.cmu.edu/usr/anon/1994/CMU-CS ps [JOHNSON92] P.Johnson, " Human Computer Interaction ", Mac Graw-Hill. [LAVERY&COCKTON97] Darryn Lavery, Gilbert Cockton " Cognitive Walkthrough Usability Evaluation Materials ". Technical Report TR , University of Glasgow. Disponible à [LEWIS93] Clayton Lewis, John Rieman "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.