Evaluation (suite)

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

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.

15. 3. Questionnaires • 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.

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

19. G.O.M.S. L'acronyme GOMS signifie Goals, Operators, Methods, and SelectionRules. • 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 • Les "Methods" représentent des séquences d'"Operators", regroupés afin d'accomplir un but élémentaire. • SelectionRules • Les SelectionRules 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. 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].

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

24. Position dans le cycle de vieKLM est un modèle prédictif à utiliser très tôt dans le cycle de développement [FARENC97]

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 :

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. Position dans le cycle de vieL'utilisation d'Heuristic Evaluation peut se faire dès que la présentation de l'interface est réalisée [FARENC97].

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 vieElle peut être utilisée dès qu'une version même statique de l'interface est réalisée [FARENC97].

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

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

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 :

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 :

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