Semaine 2

Activité 1

Analyse de la tâche et du processus de formation de l’action

Sommaire

Théorie de l’action de Norman
Gouffre de l’exécution
Gouffre de l’évaluation
Approche centrée sur l’utilisateur de Norman
Scénarios d’utilisation et cas de conception en UML

Théorie de l’action de Norman

Le but de la théorie de l’action est d’obtenir une représentation mentale de l’état à atteindre. L’état du système est un ensemble de variables physiques et de mécanismes de contrôle qui modifient ces variables physiques.

Nous cherchons à comprendre comment l’usager d’un système exécute une action. Pour cela, il faut analyser les différentes étapes qui permettent à un usager d’exécuter une action afin d’en tirer quelques conclusions et d’améliorer la conception des interfaces.

Pour exécuter une action, l’usager doit franchir sept étapes qui détermineront si l’action peut être complétée. Voici ces étapes.

La formation des buts ou l’établissement d’un but est une représentation mentale de l’état à atteindre en termes de variables psychologiques.
La transformation des buts en actes (ou la formation d’une intention) est la différence entre le but et l’état actuel du système.
La spécification d’une séquence d’actions est une représentation mentale du plan à réaliser ou la traduction du but en l’image physique désirée; exige une connaissance des liens entre variables psychologiques et physiques et une connaissance des relations entre dispositifs de contrôle et variables physiques.
L’exécution de la séquence d’actes est la manipulation des dispositifs physiques de contrôle pour modifier les variables physiques.
La perception de l’état du système se définit comme la représentation mentale de la nouvelle image.
L’interprétation de l’état du système s’effectue sur l’état perçu en fonction des variables psychologiques impliquées dans le but.
L’évaluation de l’interprétation compare le résultat de l’interprétation et le but visé.

Très souvent, les problèmes associés aux interfaces peuvent être catégorisés en fonction de manquements survenant à l’un ou l’autre de ces étapes. La majorité des erreurs se situent dans l’évaluation du système et dans la transformation de buts en actes. La connaissance de ces étapes nous permet d’établir des repères qui permettent d’éviter l’interruption de l’exécution des étapes de l’action :

Est-ce facile de déterminer l’état du système?
Est-ce facile de déterminer si le système est dans l’état désiré?
Est-ce facile de déterminer les fonctionnalités du système?
Est-ce facile d’établir la séquence d’action à exécuter pour réaliser l’action?
Est-ce facile d’exécuter les actions?

Ces questions simples permettent très souvent d’identifier la cause d’un problème d’interface et de trouver une solution simple mais efficace qui permettra à l’usager d’accomplir facilement une tâche.

Il existe des gouffres (appelés aussi distances) qui représentent les différences entre les intentions de l’utilisateur et les actions permises. C’est le reflet de l’effort que doit déployer l’utilisateur pour interpréter l’état physique du système et déterminer si le système a effectivement répondu aux attentes et aux intentions.

Gouffre de l’exécution

Les actions permises du système informatique correspondent aux intentions de l’utilisateur.

Ce gouffre se définit comme l’effort nécessaire pour transformer les intentions ainsi que pour sélectionner et exécuter les commandes.

Un bon système comporte des « mapping » directs entre l’intention et les sélections. Il faut rendre les objets visibles grâce à des mappings utiles. Les mappings permettent d’indiquer visuellement les actions significatives dans un contexte donné. Par exemple, pour imprimer une page, il est préférable de placer l’icône d’une imprimante bien en vue dans le document plutôt que de demander à l’utilisateur d’aller dans un menu et de sélectionner « imprimer ».

Gouffre de l’évaluation

Est-ce que le retour de l’information peut être interprété de la même manière que les intentions?

Ici, le gouffre de l’évaluation est l’effort nécessaire pour interpréter la rétroaction (feedback).

Un bon système donne une rétroaction facilement comprise par les utilisateurs. Un mauvais système ne donnera pas de rétroaction ou son interprétation sera difficile.

Pour conclure, la théorie de l’action est une boucle où on se pose des questions à chaque niveau pour intervenir et savoir ce que l’interface peut faire. Il faut simplifier au maximum pour que l’utilisateur puisse interagir avec l’interface sans difficulté.

Étude de cas sur la théorie de l’action

Le but est de remplir la baignoire pour prendre un bain chaud, c’est-à-dire à une température souhaitée. Les variables physiques sont le débit d’eau chaude et le débit d’eau froide.

Les variables psychologiques sont le débit global et la température.

L’effort dans la conception du système est de se rapprocher des préoccupations de l’utilisateur.

Cette formalisation met en évidence plusieurs difficultés pour l’utilisateur. D’abord, il existe un problème de correspondance entre les variables physiques et les dispositifs physiques de commande. Grâce à son expérience, l’utilisateur sait qu’il lui faut contrôler les robinets pour obtenir de l’eau. Par contre, comment, dans son image mentale, l’utilisateur peut-il distinguer le robinet d’eau froide du robinet d’eau chaude? Ensuite, dans quel sens doit-il tourner un robinet pour agir sur le débit? Enfin, l’utilisateur se voit dans une situation difficile où il lui faut manipuler simultanément deux robinets dans des sens contraires pour augmenter le débit d’eau froide et diminuer le débit d’eau chaude.

Le but est difficile à atteindre en raison de l’inadéquation des relations entre les variables physiques et psychologiques. Un problème d’évaluation des résultats. Avec deux becs verseurs, il est difficile d’évaluer le débit total et il est encore plus difficile de déterminer la température obtenue.

Cette analyse indique qu’un robinet mélangeur résout le problème de l’évaluation et qu’un robinet thermostatique définit un isomorphisme entre les variables physiques et les variables psychologiques.

Approche centrée sur l’utilisateur de Norman [2]

« L’utilisabilité est l’impact de l’amalgame des caractéristiques humaines et des modèles mentaux sur la performance d’un produit ». William S.Green

La conception centrée sur l’utilisateur renforce le rôle de l’utilisateur et elle intègre ce dernier à toutes les étapes du processus de développement d’un dispositif technique ou d’un produit. Cette démarche suppose :

la prise en considération des besoins d’utilisateurs potentiels ainsi que leurs caractéristiques différentielles lors de la conception d’un produit (capacités cognitives et physiques, mémoire, perception, expérience, etc.);
l’implication et la participation active de l’utilisateur final au cours des différentes phases du développement du produit jusqu’à la mise en marché de celui-ci.

Il faut analyser les besoins des utilisateurs, leurs tâches et activités ainsi que leur contexte de travail (p. ex., variabilité, spécificité, différence).

Le concepteur doit se centrer sur les dimensions humaines, sociales et cognitives de l’utilisation d’un système et faire participer activement les utilisateurs à la conception en faisant appel à une démarche itérative de conception et en faisant intervenir une équipe de conception multidisciplinaire.

Selon les options théoriques et méthodologiques, la manière dont l’utilisateur final est pris en considération dans un système peut revêtir des formes variées :

utilisateur en tant que personne possédant des caractéristiques qui le distinguent d’autres utilisateurs, notamment des handicaps et des déficits sensoriels, moteurs, cognitifs ou sociaux;
utilisateur en interaction avec le contexte dans lequel son activité se déroule ou se déroulera;
utilisateur en tant que personne qui évolue dans un milieu social et interagit avec les autres dans l’exécution de tâches (activités coopératives);
utilisateur doté d’un niveau d’expertise plus ou moins élevé et d’une capacité d’adaptation plus ou moins importante par rapport aux tâches (flexibilité);
utilisateur ancré socialement (valeurs, attitudes, plaisir, etc.).

Selon ces orientations, l’utilisateur occupe une place centrale, mais le regard qu’on lui porte est orienté en fonction des objectifs de la conception et des choix des concepteurs.

La conception centrée sur l’utilisateur (CCU) permet de mieux comprendre le processus de travail des usagers et ainsi d’adapter l’interface aux besoins des utilisateurs plutôt qu’aux besoins du programmeur. De plus, la CCU n’est pas guidée par la technologie ou les fonctionnalités.

Pourquoi utiliser la CCU?

Parce qu’elle permet de bien connaître les besoins des usagers.
Parce que les mauvaises conceptions échouent.
Parce que sans fonctionnalité, si la conception du logiciel est inadéquate, le produit ne percera pas.
Parce que près de 25 % des projets échouent à cause de dépassements de budget ou de programmes dotés de meilleures interfaces.
Parce qu’elle facilite la maintenance, la production de codes « spaghetti » étant diminuée (https://fr.wikipedia.org/wiki/Programmation_spaghetti).
Parce qu’elle facilite la vente du logiciel, l’interface est plus facile à maîtriser.

Il nous reste à voir le fonctionnement de la CCU et ses étapes.

1. Identification des objectifs du produit

Identification des grandes lignes du produit. Il s’agit ici d’établir ce que sera le produit. Il faut aussi définir ce que le produit ne sera pas afin d’éviter les dépassements de délai et de budget.

Il faut définir clairement les objectifs spécifiques du produit. Il sera alors possible de les revoir en fonction des besoins des utilisateurs.

Il est important d’identifier les fonctionnalités qui ne doivent pas être incorporées au produit afin de ne pas complexifier celui-ci inutilement.
Il est important de respecter les décisions précédentes afin de ne pas alourdir les fonctionnalités et surcharger le logiciel.

2. Identification des besoins spécifiques des usagers

D’abord, il faut identifier les usagers cibles. Ensuite, il faut déterminer leur profil. Ce profil aidera à déterminer l’emplacement des commandes et selon quel niveau de détail l’information sera affichée. Finalement, il faut élaborer la description des tâches à réaliser par l’usager pour l’utilisation complète du produit. Il y a deux façons de recueillir de l’information sur les usagers :

l’interview;
l’observation.

Il est important de faire participer les usagers à la définition des besoins. Aller dans les foires commerciales afin de discuter avec des utilisateurs potentiels est une façon de mieux connaître leurs besoins. Dans le cas de logiciels produits sur demande, il faut se rendre sur le site de l’entreprise afin de mieux comprendre les besoins des utilisateurs.

3. Profil de l’usager

Le profil de l’usager se définit selon sa connaissance de l’informatique, du système à opérer et de la tâche à exécuter. Voici donc les points à prendre en considération au moment de l’établissement du profil d’usager :

expérience liée au matériel;
expérience liée au logiciel;
expérience liée aux applications du même domaine que celui visé par le projet;
expérience liées à la tâche à exécuter.

Scénarios d’utilisation et cas de conception en UML [1]

L’UML (Unified Modeling Language) est couramment utilisé dans les projets logiciels. Il est utilisé en développement logiciel et en conception orientée objet.

Les scénarios d’utilisation permettent d’établir la séquence de sous-tâches que l’usager doit effectuer pour compléter une tâche ou une action. Le scénario d’utilisation doit décrire l’exécution d’une tâche du point de vue de l’utilisateur et non de celui du système. Il est utile d’inclure dans les scénarios les fréquences des tâches afin de permettre une meilleure analyse de l’interaction. Ainsi, l’utilisation d’USE-CASE de l’UML peut se révéler très efficace.

À cette étape de la conception, la première version des scénarios d’utilisation peut être relativement grossière et ne pas comporter toutes les informations nécessaires pour accomplir la tâche.

Un raffinement pourra être effectué à la suite de l’analyse des tâches.

1. Paramètres d’utilisabilité

Établir des paramètres d’utilisabilité permet de définir les améliorations à apporter à l’interface.

Cela permet aussi d’établir des critères d’évaluation de la capacité de votre interface à résoudre certains problèmes. Voici quelques questions qui permettent d’établir des paramètres d’utilisabilité :

Que visez-vous?
Quel paramètre devez-vous considérer pour évaluer l’utilisabilité?
Quel problème veut résoudre la nouvelle interface?
Voici quelques exemples d’attributs d’utilisabilité :
Facilité d’apprentissage;
Exécution rapide des tâches;
Facilité d’utilisation;
Exécution précise des tâches;
etc.

Les paramètres d’utilisabilité ont leurs limites. Les mesures quantitatives nous donnent une autre vision des paramètres d’utilisabilité et peuvent remplacer ces derniers selon les cas.

2. Analyse des tâches

Une fois que la première ébauche des scénarios d’utilisation a été réalisée, il est de mise d’approfondir les besoins par une analyse des tâches de l’utilisateur. Les tâches que l’usager accomplit lorsqu’il utilise la version actuelle d’un programme (le cas échéant) valent la peine d’être étudiées, car elles permettent de découvrir les erreurs que font les usagers. De plus, elles permettent de définir les données que l’usager doit saisir. Par contre, il faut faire attention de ne pas suivre le design de l’ancien logiciel.

Dans le cas de tâches déjà en place, il est important de noter :

le centre d’attention de l’usager lorsqu’il initie, puis accomplit la tâche;
les erreurs courantes;
les plaintes des usagers sur le processus actuel.

Paramètres à évaluer pour chaque tâche :

fréquence;
informations nécessaires pour la prise de décisions;
informations à saisir;
raccourcis utilisés par l’utilisateur;
terminologie et concepts utilisés pour l’exécution de la tâche;
solutions de rechange (« Workarounds ») utilisées.

Une fois les tâches clairement définies, il est temps de revoir nos scénarios d’utilisation et de les adapter en fonction des constatations que l’on vient de faire.

Étude de cas 1

Exemple de scénario d’utilisation : « paiement de factures et impression de chèques ».

Entrer les factures (nom du bénéficiaire + montant dû) dans un tableau.
Visualiser le nouveau solde.
Décider s’il y a suffisamment de fonds pour toutes les factures :
1. si oui (80 % du temps), aller à 4;
2. si non (20% du temps), marquer les factures non payées (50 % du temps) ou changer les montants à payer (50 % du temps) et aller à 4.
Demander aux systèmes de payer les factures.
Préparer les options d’impression de chèques.
Mettre le stock de chèques dans l’imprimante.
Imprimer les chèques.
Vérifier les chèques.
Réimprimer les chèques s’il y a un problème (15 % du temps).
Revoir les chèques mis à jour dans le registre (50 % du temps).
Exécuter les rapports (50 % du temps).

NB : Dans ce scénario, certaines tâches ont leurs propres scénarios.

Étude de cas 2 :