Critères et heuristiques

Critères Ergonomiques pour l’Évaluation d’Interfaces Utilisateurs de Bastien et Scapin

Utilisez les critères de Bastien et Scapin pour faire des évaluations heuristiques et des audits ergonomiques plus rapidement avec Capian.

Introduction aux critères de Bastien et Scapin

Qui sont Christian Bastien et Dominique Scapin ? Ce sont deux chercheurs en psychologie ergonomique et en ergonomie cognitive qui ont choisi de s'intéresser à l'expérience utilisateur et aux interfaces homme-machine. Les critères ergonomiques que l'on vous présente ci-dessous ont été créés dans le cadre d'un projet de recherche au milieu des années 90.

Le but de cette recherche était de trouver une méthode ou des outils permettant l'intégration des facteurs humains dans le processus de conception des interfaces personne-machine. La nécessité d'avoir des critères se fait ressentir lorsque le besoin d'obtenir des explications est exprimé.

Téléchargez la version complète Téléchargez la cheat sheet Téléchargez le guide sur les évaluations heuristiques

Critères heuristiques

Grâce à ces critères, il est maintenant possible de définir ce qui est bon ou mauvais dans le cadre de l’évaluation d’interface homme-machine. L’importance d’avoir des critères permet aussi plusieurs autres avancées :

  • • Très fort gain de temps, car dorénavant, nous savons quoi examiner.

  • • Les critères étant très explicite il y a une possibilité pour que des non-spécialistes puissent s’en servir.

  • • Étant donné la pluralité et la précision des critères de Bastien & Scapin, ils sont réutilisables à l'infini.

  • • Ils sont utiles sur les différentes plateformes : desktop, tablette, téléphone

  • • Et dans différents domaines, jeux vidéos, site web, application mobile, logiciel métier, et SaaS

Basés sur plusieurs centaines de recommandations, les critères ont été créés grâce à un système de tri, une fois que toutes les recommandations ont été réunies, Bastien & Scapin ont commencé à étiqueter les recommandations pour les réunir sous des critères. Les critères ergonomiques de “Bastien et Scapin” s’adaptent parfaitement à la nomenclature actuelle de tout environnement numérique, que ce soit une interface mobile, ou web.

Voici une interview de Christian Bastien qui revient sur la création et l’évolution des critères ergonomiques.

Pour cette page, nous avons extrait les critères à partir du PDF original de J. M. Christian Bastien et Dominique L. Scapin.

Heuristiques principaux

Guidage

L’ensemble des moyens mis en oeuvre pour conseiller, orienter, informer, et conduire l’utilisateur lors de ses interactions avec l’ordinateur.

Lire plus

Charge de travail

Concerne l’ensemble des éléments de l’interface qui ont un rôle dans la réduction de la charge perceptive ou mnésique des utilisateurs et dans l’augmentation de l’efficacité du dialogue.

Lire plus

Contrôle explicite

Concerne à la fois la prise en compte par le système des actions explicites des utilisateurs et le contrôle qu’ont les utilisateurs sur le traitement de leurs actions.

Lire plus

Adaptabilité

Concerne sa capacité à réagir selon le contexte, et selon les besoins et préférences des utilisateurs.

Lire plus

Gestion des erreurs

Concerne tous les moyens permettant d’une part d’éviter ou de réduire les erreurs, et d’autre part de les corriger lorsqu’elles surviennent.

Lire plus

Homogénéité / Cohérence

Réfère à la façon avec laquelle les choix de conception de l’interface sont conservés pour des contextes identiques, et sont différents pour des contextes différents.

Lire plus

Signifiance des codes et dénominations

Concerne l’adéquation entre l’objet ou l’information affichée ou entrée, et son référent. Des codes et dénominations “signifiants” disposent d’une relation sémantique forte avec leur référent.

Lire plus

Compatibilité

Réfère à l’accord pouvant exister entre les caractéristiques des utilisateurs et des tâches, d’une part, et l’organisation des sorties, des entrées et du dialogue d’une application donnée, d’autre part.

Lire plus

Essayez Capian

Et évaluez rapidement les sites et applications avec les critères de Bastien et Scapin.

Inscrivez-vous gratuitement

1. Guidage

Définition :

Le Guidage est l’ensemble des moyens mis en oeuvre pour conseiller, orienter, informer, et conduire l’utilisateur lors de ses interactions avec l’ordinateur (messages, alarmes, labels, etc.), y compris dans ses aspects lexicaux.

Quatre sous-critères participent au Guidage : Incitation, Groupement/Distinction entre Items, Feedback Immédiat et Lisibilité.

Justification(s) :

Un bon guidage facilite l’apprentissage et l’utilisation du système en permettant à l’utilisateur : de savoir, à tout moment, où il se trouve dans une séquence d’interactions, ou dans l’accomplissement d’une tâche; de connaître les actions permises ainsi que leurs conséquences; et d’obtenir de l’information supplémentaire(éventuellement sur demande). La facilité d’apprentissage et d’utilisation qui s’ensuivent conduisent à de meilleures performances et occasionnent moins d’erreurs.

1.1 Incitation *

Définition :

Le terme Incitation a ici une définition plus large que celle qu'on lui confère généralement. Ce critère recouvre les moyens mis en œuvre pour amener les utilisateurs à effectuer des actions spécifiques, qu'il s'agisse d'entrée de données ou autre. Ce critère englobe aussi tous les mécanismes ou moyens faisant connaître aux utilisateurs les alternatives, lorsque plusieurs actions sont possibles, selon les états ou contextes dans lesquels ils se trouvent. L'Incitation concerne également les informations permettant aux utilisateurs de savoir où ils en sont, d'identifier l'état ou contexte dans lequel ils se trouvent, de même que les outils d'aide et leur accessibilité.

Justification(s) :

Une bonne incitation guide les utilisateurs et leur évite par exemple d'avoir à apprendre une série de commandes. Elle permet aussi aux utilisateurs de savoir quel est le mode ou l'état en cours, où ils se trouvent dans le dialogue et ce qu'ils ont fait pour s'y trouver. Une bonne incitation facilite donc la navigation dans une application et permet d'éviter les erreurs.

Exemples de recommandations :

  • Guider les entrées de données en indiquant le format adéquat et les valeurs acceptables; par exemple, fournir, au niveau du label, des indices supplémentaires sur le format d'entrée des données (ex.: date (jj/mm/aa) : / / ).

  • Afficher les unités de mesure des données à saisir.

  • Indiquer toutes les informations d'état (ex.: modes, valeurs, etc.).

  • Pour chaque champ de données, fournir un label.

  • Fournir des indices sur la longueur autorisée des entrées dans un champ.

  • Donner un titre à chaque fenêtre.

  • Fournir des aides accessibles en ligne.

Commentaires

Incitation vs Groupement/Distinction par le Format

L'Incitation permet de préciser aux utilisateurs de manière directe les actions possibles. Ainsi, lorsque les utilisateurs ont la possibilité d'effectuer différentes actions (ex.: confirmer, annuler, copier, etc.), on peut présenter uniquement les options disponibles, ou bien indiquer ces actions dans un message.

D'autres moyens sont disponibles pour guider les utilisateurs, lesquels peuvent être moins directs. Ainsi, dans le cas ci-dessus, on peut, si toutes les options sont présentées, indiquer par des formats différents celles qui peuvent être utilisées.

Dans les cas où plusieurs choix ou actions sont possibles, il arrive par exemple, que le bouton de commande le plus fréquent ou le plus probable soit distingué par un contour surajouté auquel correspond un retour chariot. Dans ce cas il s'agit du critère Groupement/Distinction par le Format et non du critère Incitation car l'information retour chariot n'est pas explicite.

L'Incitation consiste à présenter directement les différentes actions possibles alors que le Groupement/Distinction par le Format pourra permettre de faire apparaître des caractéristiques particulières de ces actions possibles.

Incitation vs Feedback Immédiat

La distinction entre l'Incitation et le Feedback Immédiat est parfois ténue. Suite à une action par exemple, un message peut indiquer aux utilisateurs d'une part que leur demande a été exécutée et, d'autre part que pour continuer ils doivent faire telle ou telle autre action. Il peut donc y avoir un feedback sur les actions précédentes et une incitation pour les actions subséquentes. Si le message informe les utilisateurs sur les actions accomplies, il s'agit du critère Feedback Immédiat. Si le message guide les utilisateurs vers des actions ultérieures ou s'il demande à aux utilisateurs d'effectuer une action particulière, alors il s'agit du critère Incitation.

Incitation vs Lisibilité

Les caractéristiques lexicales qui peuvent avoir un effet sur la facilité de lecture (ex.: taille des caractères, type de police, etc.), dans le cas de l'incitation, concernent le critère Lisibilité.

Incitation vs Concision

Une bonne incitation, telle une consigne, ou un message indiquant aux utilisateurs ce qu'il faut faire peut être trop longue. Ce défaut dans un message d'incitation concerne le critère Concision. De la même façon on peut indiquer correctement,donc en utilisant une bonne incitation, la façon dont les données doivent être saisies mais induire un problème de Concision si, en plus des données, on demande par exemple aux utilisateurs d'indiquer des unités de mesure.

Incitation vs Protection Contre les Erreurs

Plusieurs façons d'offrir une protection contre les erreurs sont possibles. On peut par exemple mettre en place un mécanisme automatique de vérification des entrées.Ainsi, au moment de la validation des entrées, un message d'erreur apparaît si le format d'entrée n'est pas conforme à ce qui est attendu. Il s'agit bien dans ce cas-ci du critère Protection Contre les Erreurs. Une autre façon consiste à fournir une information renseignant les utilisateurs sur le type de données attendues ou encore sur le format de ces entrées : il s'agit alors du critère Incitation. Ces deux mécanismes peuvent aussi coexister.

Incitation vs Qualité des Messages d'Erreur

Un message d'erreur, peut comporter des incitations sur la manière de corriger une erreur. Il s'agit là du critère Qualité des Messages d'Erreur et non pas du critère Incitation. L'Incitation concerne uniquement le guidage en situation normale.

Incitation vs Homogénéité/Cohérence

Dès qu'il s'agit de considérer ou de comparer plusieurs interactions, plusieurs objets, etc., y compris avec un objectif d'incitation, il s'agit en fait du critère Homogénéité/Cohérence. Par exemple, présenter les titres des fenêtres dans des positions identiques concerne le critère Homogénéité/Cohérence.

Incitation vs Compatibilité

Lorsque les termes utilisés lors de l'incitation ne sont pas ceux couramment employés par les utilisateurs, on est en présence d'un problème de Compatibilité.

1.2 Groupement/Distinction entre Items

Définition :

Le critère Groupement/Distinction entre Items concerne l’organisation visuelle des items d’information les uns par rapport aux autres. Ce critère prend en compte la topologie (localisation) et certaines caractéristiques graphiques (format) afin d’illustrer les relations entre les divers items affichés, leur appartenance ou non-appartenance à une même classe, ou encore dans le but de montrer la distinction entre différentes classes d’items. Ce critère concerne aussi l’organisation des items à l’intérieur d’une même classe.

Deux sous-critères participent au Groupement/Distinction entre Items : Groupement/Distinction par la Localisation et Groupement/Distinction par le Format.

Justification(s) :

La compréhension d’un écran dépend, entre autres choses, de l’arrangement, du positionnement et de la distinction des objets (images, textes, commandes, etc.) qui y sont présentés. Les utilisateurs auront plus de facilité à repérer les items et/ou groupes d’items et à connaître leurs liens si ils sont présentés de façon organisée (ex.:alphabétique, fréquence d’utilisation, etc.) d’une part, et si ces items ou groupes d’items sont présentés dans des formats ou codages qui permettent d’illustrer leurs similitudes ou leurs différences, d’autre part. De même, les utilisateurs pourront mieux les apprendre et s’en rappeler. Le groupement/distinction entre items entraîne un meilleur guidage.

1.2.1 Groupement/Distinction par la Localisation

Définition :

Le critère Groupement/Distinction par la Localisation concerne le positionnement des items les uns par rapport aux autres dans le but d’indiquer leur appartenance ou non-appartenance à une même classe, ou encore dans le but de montrer la distinction entre différentes classes. Ce critère concerne aussi l’organisation des items dans une même classe.

Justification(s) :

La compréhension d’un écran dépend, entre autres choses, de l’arrangement des objets (images, textes, commandes, etc.) qui y sont présentés. Les utilisateurs auront plus de facilité à repérer les différents items si ils sont présentés de façon organisée(ex.: alphabétique, fréquence d’utilisation, etc.). De même, ils pourront mieux les apprendre et s’en rappeler. Le critère groupement/distinction par la localisation entraîne un meilleur guidage.

Exemples de recommandations :

  • Organiser les items en listes hiérarchiques.
  • Grouper les options de menus en fonction des objets sur lesquels elles s’appliquent.
  • Lorsque plusieurs options sont présentées, l’organisation de ces dernières doit être logique, i.e. représenter une organisation fonctionnelle pertinente ou significative(arrangement alphabétique, fonctionnel, fréquence d’utilisation, etc.).

Commentaire(s) :

Groupement/Distinction par la Localisation vs Groupement/Distinction par le Format

Le groupement et/ou la distinction entre items peut être obtenu par le format et/ou par la localisation. La localisation et le format correspondent à différents moyens d’affichage (topologie vs caractéristiques graphiques surajoutées). Par exemple, des options de menu peuvent être distinguées par leur localisation (ex.: les options les plus fréquentes vers le haut, les moins fréquentes vers le bas) et/ou par leur format(ex.: une ligne de séparation entre un ensemble d’options liées à la présentation d’un texte et un ensemble d’options concernant les types de caractères).

1.2.2 Groupement/Distinction par le Format

Définition :

Le critère Groupement/Distinction par le Format concerne plus particulièrement les caractéristiques graphiques (format, couleur, etc.) permettant de faire apparaître l’appartenance ou la non-appartenance d’items à une même classe, ou encore permettant d’indiquer des distinctions entre classes ou bien encore des distinctions entre items d’une même classe.

Justification(s) :

Les utilisateurs auront plus de facilité à connaître les liens entre items ou classes d’items si des formats, ou codages permettent d’illustrer leurs similitudes ou leurs différences. De tels liens seront ainsi mieux appris et mieux rappelés. Un bon groupement/distinction par le format entraîne un meilleur guidage.

Exemples de recommandations :

  • Établir une distinction visuelle entre des aires ayant des fonctions différentes (commande, message, etc.).
  • Établir une distinction visuelle entre les labels et les champs d’entrée.

Commentaire(s) :

Groupement/Distinction par le Format vs Incitation

L’Incitation permet de préciser aux utilisateurs de manière directe les actions possibles. Ainsi, lorsque les utilisateurs ont la possibilité d’effectuer différentes actions (ex.: confirmer, annuler, copier, etc.), on peut présenter uniquement les options disponibles, ou bien indiquer ces actions dans un message.

D’autres moyens sont disponibles pour guider les utilisateurs, lesquels peuvent être moins directs. Ainsi, dans le cas ci-dessus, on peut, si toutes les options sont présentées, indiquer par des formats différents celles qui peuvent être utilisées.

Dans les cas où plusieurs choix ou actions sont possibles, il arrive par exemple, que le bouton de commande le plus fréquent ou le plus probable soit distingué par un contour surajouté auquel correspond un retour chariot. Dans ce cas il s’agit du critère Groupement/Distinction par le Format et non du critère Incitation car l’information retour chariot n’est pas explicite.

L’Incitation consiste à présenter directement les différentes actions possibles alors que le Groupement/Distinction par le Format pourra permettre de faire apparaître des caractéristiques particulières de ces actions possibles.

Groupement/Distinction par le Format vs Groupement/Distinction par la Localisation

Le groupement et/ou la distinction entre items peut être obtenu par le format et/ou par la localisation. La localisation et le format correspondent à différents moyens d’affichage (topologie vs caractéristiques graphiques surajoutées). Par exemple, des options de menu peuvent être distinguées par leur localisation (ex.: les options les plus fréquentes vers le haut, les moins fréquentes vers le bas) et/ou par leur format (ex.: une ligne de séparation entre un ensemble d’options liées à la présentation d’un texte et un ensemble d’options concernant les types de caractères).

1.3 Feedback Immédiat

Définition :

Le Feedback Immédiat concerne les réponses de l’ordinateur consécutives aux actions des utilisateurs, lesquelles peuvent être le simple appui sur une touche ou l’entrée d’une séquence de commandes. Dans tous les cas, l’ordinateur doit répondre, dans les plus brefs délais, avec un délai de réponse approprié et homogène selon les types de transactions. Dans tous les cas, une réponse aussi immédiate que possible doit être fournie à l’utilisateur le renseignant sur l’action accomplie et sur son résultat.

Justification(s) :

La qualité et la rapidité du feedback sont deux facteurs importants pour l’établissement de la confiance et de la satisfaction des utilisateurs ainsi que pour leur compréhension du dialogue. Ces facteurs permettent aux utilisateurs de se faire une bonne représentation du fonctionnement du système.

L’absence de feedback ou des délais trop importants entre les actions utilisateur et le feedback, peuvent déconcerter les utilisateurs, ce qui augmente les chances que les utilisateurs entreprennent des actions qui risquent d’entraver les transactions encours.

Exemples de recommandations :

  • Toujours faire apparaître sur l’écran les entrées effectuées par les utilisateurs, sauf pour les entrées confidentielles. Cependant, même dans ce cas, un feedback perceptible doit être fourni (ex.: l’affichage d’astérisques correspondant aux entrées clavier).
  • Suite à l’interruption d’un traitement par l’utilisateur, le système devrait fournir un message indiquant le retour à l’état précédent.
  • Dans les cas où les traitements sont longs, une information indiquant aux utilisateurs que les traitements sont en cours devrait leur être fournie.

Commentaire(s) :

Feedback Immédiat vs Incitation

La distinction entre l’Incitation et le Feedback Immédiat est parfois ténue. Suite à une action par exemple, un message peut indiquer aux utilisateurs d’une part que leur demande a été exécutée et, d’autre part que pour continuer ils doivent faire telle ou telle autre action. Il peut donc y avoir un feedback sur les actions précédentes et une incitation pour les actions subséquentes. Si le message informe les utilisateurs sur les actions accomplies, il s’agit du critère Feedback Immédiat. Si le message guide les utilisateurs vers des actions ultérieures ou s’il demande à aux utilisateurs d’effectuer une action particulière, alors il s’agit du critère Incitation.

Feedback Immédiat vs Lisibilité

Quand la qualité du feedback n’est pas satisfaisante, même du point de vue lexical, il s’agit du critère Feedback Immédiat, et non du critère Lisibilité. Le Feedback Immédiat concerne toutes les caractéristiques des réponses consécutives aux actions des utilisateurs (présence ou absence de feedback, qualité du feedback du point de vue sémantique et lexical).

1.4 Lisibilité

Définition :

Le critère Lisibilité concerne les caractéristiques lexicales de présentation des informations sur l’écran pouvant entraver ou faciliter la lecture de ces informations(luminance des caractères, contraste caractères fond, dimension des lettres,espacement entre les mots, espacement entre les lignes, espacement entre les paragraphes, longueur des lignes, etc.).

Par convention, le critère Lisibilité ne concerne ni le feedback ni les messages d’erreurs.

Justification(s) :

La performance est accrue lorsque la présentation des informations à l’écran tient compte des caractéristiques cognitives et perceptives des utilisateurs. Une bonne lisibilité facilite la lecture des informations présentées. Ainsi par exemple, les lettres sombres sur fond clair sont plus faciles à lire que l’inverse; le texte présenté en lettres majuscules et minuscules est lu plus rapidement que le texte présenté seulement en lettres majuscules.

Exemples de recommandations :

  • Les titres doivent être centrés.
  • Les labels doivent être en majuscule.
  • Le curseur doit être facilement repérable.
  • Il est préférable de présenter un texte avec quelques lignes longues plutôt que de nombreuse lignes courtes.
  • Les lignes de texte continu doivent être d’au moins 50 caractères.
  • La justification à droite des textes ne devrait être utilisée qu’avec un espacement variable, de sorte qu’un espacement proportionnel constant entre les lettres et les mots soit respecté.
  • Dans les affichages de textes, utiliser le moins possible la césure des mots.

Commentaire(s) :

Le critère Lisibilité ne s’applique ni au feedback, ni aux messages d’erreurs. En effet, tous les aspects liés à des difficultés de lecture par les utilisateurs, ou plus généralement à la qualité des messages concernant le feedback ou les messages d’erreurs sont affectés respectivement au critère Feedback Immédiat et au critère Qualité des Messages d’Erreurs.

Lisibilité vs Feedback Immédiat

Quand la qualité du feedback n’est pas satisfaisante, même du point de vue lexical, il s’agit du critère Feedback Immédiat, et non du critère Lisibilité. Le Feedback Immédiat concerne toutes les caractéristiques des réponses consécutives aux actions des utilisateurs (présence ou absence de feedback,qualité du feedback du point de vue sémantique et lexical).

Lisibilité vs Qualité des Messages d’Erreur

Quand les messages d’erreur ne sont pas adéquats, même du point de vue lexical, il s’agit du critère Qualité des Messages d’Erreur, et non du critère Lisibilité. Le critère Qualité des Messages d’Erreur concerne toutes les caractéristiques des informations relatives aux erreurs des utilisateurs.

Lisibilité vs Incitation

Les caractéristiques lexicales qui peuvent avoir un effet sur la facilité de lecture (ex.: taille des caractères, type de police, etc.), dans le cas de l’incitation, concernent le critère Lisibilité.

Lisibilité vs Signifiance des Codes et Dénominations

Le critère Lisibilité ne concerne pas les aspects sémantiques des informations, leur pertinence ou leur signification. Ceux-ci sont davantage du ressort du critère Signifiance des Codes et Dénominations.

Lisibilité vs Compatibilité

Le critère Lisibilité ne concerne pas les aspects sémantiques des informations, leur pertinence ou leur signification. Quand ces aspects sont liés aux tâches, le critère à considérer est la Compatibilité.

2. Charge de travail

Définition :

Le critère Charge de Travail concerne l’ensemble des éléments de l’interface qui ont un rôle dans la réduction de la charge perceptive ou mnésique des utilisateurs et dans l’augmentation de l’efficacité du dialogue.

Deux sous-critères participent au critère Charge de Travail : Brièveté (qui inclut les critères Concision et Actions Minimales), et Densité Informationnelle.

Justification(s) :

Plus la charge de travail est élevée, plus grands sont les risques d’erreurs. De même, moins l’utilisateur sera distrait par des informations non pertinentes, plus il pourra effectuer sa tâche efficacement. Par ailleurs, plus les actions requises seront courtes,plus rapides seront les interactions.

2.1 Brièveté

Définition :

Le critère Brièveté concerne la charge de travail au niveau perceptif et mnésique à la fois pour les éléments individuels d’entrée ou de sortie et les séquences d’entrées(i.e., les suites d’actions nécessaires à l’atteinte d’un but, à l’accomplissement d’une tâche). Il s’agit ici de limiter autant que possible le travail de lecture, d’entrée et les étapes par lesquelles doivent passer les utilisateurs.

Deux sous-critères participent au critère Brièveté : Concision et Actions Minimales.

Justification(s) :

Les capacités de la mémoire à court terme sont limitées. Par conséquent, plus courtes sont les entrées, plus limités sont les risques d’erreurs. Par ailleurs, plus succincts sont les items, plus court est le temps de lecture.

Aussi, plus les actions nécessaires à l’atteinte d’un but sont nombreuses et compliquées, plus la charge de travail augmente et par conséquent plus les risques d’erreurs sont élevés.

2.1.1 Concision *

Définition :

Le critère Concision concerne la charge de travail au niveau perceptif et mnésique pour ce qui est des éléments individuels d’entrée ou de sortie. Par convention, la Concision ne concerne pas le feedback ni les messages d’erreurs.

Justification(s) :

Les capacités de la mémoire à court terme sont limitées. Par conséquent, plus courtes sont les entrées, plus limités sont les risques d’erreurs. Par ailleurs, plus succincts sont les items, plus court est le temps de lecture.

Exemples de recommandations :

  • Pour les données numériques, la saisie des zéros précédant les nombres ne devrait pas être nécessaire.
  • Si des codes sont supérieurs à 4 ou 5 caractères, utiliser des mnémotechniques ou abréviations.
  • Permettre aux utilisateurs des entrées de données courtes.
  • Lorsqu’une unité de mesure est associée à un champ de donnée, celle-ci doit faire partie du label du champ plutôt qu’être saisie par les utilisateurs.

Commentaire(s) :

Concision vs Incitation

Une bonne incitation, telle une consigne, ou un message indiquant aux utilisateurs ce qu’il faut faire peut être trop longue. Ce défaut dans un message d’incitation concerne le critère Concision. De la même façon on peut indiquer correctement,donc en utilisant une bonne incitation, la façon dont les données doivent être saisies mais induire un problème de Concision si, en plus des données, on demande par exemple aux utilisateurs d’indiquer des unités de mesure.

Concision vs Actions Minimales

Le critère Actions Minimales concerne les procédures ou étapes; quand il s’agit de la longueur des items à saisir, le critère concerné est plutôt la Concision.

Concision vs Densité Informationnelle

Le critère Concision concerne le caractère succinct de la présentation des items individuels alors que le critère Densité Informationnelle concerne la densité de l’ensemble des items affichés à l’écran. Ainsi un item peut être pertinent tout en n’étant pas présenté de façon suffisamment succincte. On invoquera alors le critère Concision. Si des items sont superflus il s’agit alors du critère Densité Informationnelle.

Concision vs Qualité des messages

Le critère Concision ne s’applique pas aux messages d’erreurs. Lorsque ces derniers ne sont pas suffisamment succincts, il s’agit du critère Qualité des Messages d’Erreur.

2.1.2 Actions minimales *

Définition :

Le critère Actions Minimales concerne la charge de travail quant aux actions nécessaires à l’atteinte d’un but, à l’accomplissement d’une tâche. Il s’agit ici delimiter autant que possible les étapes par lesquelles doivent passer les utilisateurs.

Justification(s) :

Plus les actions nécessaires à l’atteinte d’un but sont nombreuses et compliquées, plus la charge de travail augmente et par conséquent plus les risques d’erreurs sont élevés.

Exemples de recommandations :

  • Minimiser le nombre d’étapes dans la sélection de menus.
  • Ne pas demander aux utilisateurs d’entrer des données qui peuvent être déduites par l’ordinateur.
  • Éviter les ponctuations pour les entrées de commandes.
  • Pour la saisie de données, afficher dans les champs appropriés, les valeurs par défaut.
  • Pour des documents contenant plusieurs pages, il devrait être possible d’atteindre une page donnée sans avoir à parcourir les pages intermédiaires une à une.

Commentaire(s) :

Actions Minimales vs Concision

Le critère Actions Minimales concerne les procédures ou étapes; quand il s’agit de la longueur des items à saisir, le critère concerné est plutôt la Concision.

Actions Minimales vs Prise en Compte de l’Expérience de l’Utilisateur

Le critère Actions Minimales concerne la longueur des transactions et des procédures quel que soit le niveau d’expérience des utilisateurs.

Quand la longueur des transactions et des procédures apparaît inadaptée pour un groupe particulier d’utilisateurs (ex.: qu’il n’existe pas de raccourcis clavier pour les utilisateurs expérimentés), il s’agit alors du critère Prise en Compte de l’Expérience de l’Utilisateur.

Actions Minimales vs Flexibilité

Le critère Flexibilité concerne l’existence de procédures différentes, quelles soient ou non minimales, permettant d’accomplir une même tâche, ou encore des moyens permettant d’adapter l’interface aux besoins particuliers d’un utilisateur.

Actions Minimales vs Correction des Erreurs

Les problèmes liés au critère Actions Minimales peuvent résulter de mécanismes de correction des erreurs inadéquats. Lorsque le nombre d’actions nécessaires à la correction des erreurs peut être réduit, il s’agit d’un problème de Correction des Erreurs. Le critère Actions Minimales concerne donc les procédures autres que celles liées à la correction des erreurs.

Actions Minimales vs Compatibilité

Un manque de compatibilité (ex.: un manque d’adéquation des procédures avec les tâches) peut conduire à une augmentation des actions nécessaires à l’accomplissement d’une tâche. Dans ce cas, il faut invoquer le critère Compatibilité et non pas Actions Minimales qui en est la conséquence, pas la cause.

2.2 Densité Informationnelle *

Définition :

Le critère Densité Informationnelle concerne la charge de travail du point de vue perceptif et mnésique, pour des ensembles d’éléments et non pour des items.

Justification(s) :

Dans la plupart des tâches, la performance des utilisateurs est influencée négativement quand la charge informationnelle est trop élevée ou trop faible. La probabilité d’erreur augmente. Il faut donc supprimer les éléments sans lien avec le contenu de la tâche en cours.

Il faut aussi éviter d’imposer à l’utilisateur la mémorisation de longues et nombreuses informations ou procédures (la mémoire à court terme est limitée), ou toute activité nécessitant de sa part la mise en oeuvre d’activités cognitives complexes lorsque la tâche ne le requiert pas.

Exemples de recommandations :

  • Limiter la densité informationnelle de l’écran, en affichant seulement les informations nécessaires.
  • L’information ne doit pas nécessiter des traductions d’unités.
  • Utiliser le minimum de quantificateurs, notamment dans les langages de requêtes.
  • Éviter à l’utilisateur d’avoir à se rappeler des données d’une page écran à une autre.
  • Les données qui peuvent être calculées à partir de celles saisies par l’utilisateur doivent l’être automatiquement. On ne doit pas exiger de l’opérateur d’effectuer des calculs qui peuvent être faits automatiquement.

Commentaire(s) :

Densité Informationnelle vs Concision

Le critère Concision concerne le caractère succinct de la présentation des items individuels alors que le critère Densité Informationnelle concerne la densité de l’ensemble des items affichés à l’écran. Ainsi un item peut être pertinent tout en n’étant pas présenté de façon suffisamment succincte. On invoquera alors le critère Concision. Si des items sont superflus il s’agit alors du critère Densité Informationnelle.

3. Contrôle explicite

Définition :

Le critère Contrôle Explicite concerne à la fois la prise en compte par le système des actions explicites des utilisateurs et le contrôle qu’ont les utilisateurs sur le traitement de leurs actions.

Deux sous-critères participent au Contrôle Explicite : Actions Explicites et Contrôle Utilisateur.

Justification(s) :

Quand les entrées des utilisateurs sont explicitement définies par eux-mêmes et sous leur contrôle, les ambiguïtés et les erreurs sont limitées. De plus, le contrôle qu’ont les utilisateurs sur le dialogue est un facteur d’acceptation du système.

3.1 Actions explicite *

Définition :

Le critère Actions Explicites concerne la relation pouvant exister entre le fonctionnement de l’application et les actions des utilisateurs. Cette relation doit être explicite, c’est-à-dire que le système doit exécuter seulement les opérations demandées par l’utilisateur et pas d’autres et ce, au moment où il les demande.

Justification(s) :

Quand les opérations du système résultent des actions des utilisateurs, on observe moins d’erreurs et la compréhension du fonctionnement de l’application est facilitée.

Exemples de recommandations :

  • Le système doit requérir une action explicite de validation par l’utilisateur (ex.: Entrée, Validation, OK) suite à une entrée de données; aucun traitement (ex.:sauvegarde d’un fichier) ne devrait être la conséquence d’une autre action (ex.: une demande d’impression).
  • Lors d’une sélection d’options de menu par pointage, prévoir une action explicite de validation.
  • L’entrée de commandes doit se terminer par une indication de fin (ex.: ENTER, OK) à laquelle des possibilités d’édition doivent être préalables.

Commentaire(s) :

Actions Explicites vs Contrôle Utilisateur

Le critère Actions Explicites se distingue du critère Contrôle Utilisateur par le fait que le premier concerne les traitements explicitement requis par l’utilisateur, alors que le second concerne le contrôle que l’utilisateur doit pouvoir exercer sur les traitements en cours.

3.2 Controle utilisateur *

Définition :

Par Contrôle Utilisateur on entend ici le fait que l’utilisateur doit toujours avoir la main, pouvoir contrôler le déroulement (ex.: interrompre, reprendre) des traitements informatiques en cours. Ses actions devraient être anticipées et des options appropriées fournies pour chaque cas.

Justification(s) :

Quand l’utilisateur a le contrôle du dialogue, les réactions de ce dernier sont prévisibles. L’apprentissage s’en trouve facilité et le risque d’erreurs diminué.

Exemples de recommandations :

  • Autoriser les utilisateurs à contrôler le rythme de leurs entrées plutôt que de faire dépendre ce rythme des traitements du système ou d’événements extérieurs.
  • Le curseur ne doit pas être déplacé sans contrôle des utilisateurs (sauf s’il s’agit de procédures stables et bien connues, ex., remplissage de formulaires).
  • Ne pas passer d’une page écran à une autre sans contrôle de l’utilisateur.
  • Autoriser l’utilisateur à interrompre à tout moment une action ou un traitement en cours (ex.: annuler).
  • Fournir la possibilité de retour arrière conduisant à l’annulation des modifications en cours et au retour à la version immédiatement précédente.

Commentaire(s) :

Contrôle Utilisateur vs Actions Explicites.

Le critère Actions Explicites se distingue du critère Contrôle Utilisateur par le fait que le premier concerne les traitements explicitement requis par l’utilisateur, alors que le second concerne le contrôle que l’utilisateur doit pouvoir exercer sur les traitements en cours.

4. ADAPTABILITÉ

Définition :

L’adaptabilité d’un système concerne sa capacité à réagir selon le contexte, et selon les besoins et préférences des utilisateurs.

Deux sous-critères participent au critère Adaptabilité : Flexibilité et Prise en Compte de l’Expérience de l’Utilisateur.

Justification(s) :

Plus les façons d’effectuer une même tâche sont diverses, plus les chances que l’utilisateur puisse choisir et maîtriser l’une d’entre elles, au cours de ses apprentissages, sont importantes. Il faut donc fournir à l’utilisateur des procédures,options, et commandes différentes leur permettant d’atteindre un même objectif. Par ailleurs, une interface ne peut convenir à la fois à tous ses utilisateurs potentiels.Pour qu’elle n’ait pas d’effets négatifs sur l’utilisateur, cette interface doit, selon les contextes, s’adapter à l’utilisateur.

4. Adaptativité

Définition :

L’adaptabilité d’un système concerne sa capacité à réagir selon le contexte, et selon les besoins et préférences des utilisateurs.

Deux sous-critères participent au critère Adaptabilité : Flexibilité et Prise en Compte de l’Expérience de l’Utilisateur. et Contrôle Utilisateur.

Justification(s) :

Plus les façons d’effectuer une même tâche sont diverses, plus les chances que l’utilisateur puisse choisir et maîtriser l’une d’entre elles, au cours de ses apprentissages, sont importantes. Il faut donc fournir à l’utilisateur des procédures,options, et commandes différentes leur permettant d’atteindre un même objectif. Par ailleurs, une interface ne peut convenir à la fois à tous ses utilisateurs potentiels.Pour qu’elle n’ait pas d’effets négatifs sur l’utilisateur, cette interface doit, selon les contextes, s’adapter à l’utilisateur.

4.1 Flexibilité *

Définition :

Le critère Flexibilité concerne les moyens mis à la disposition des utilisateurs pour personnaliser l’interface afin de rendre compte de leurs stratégies ou habitudes de travail et des exigences de la tâche. Le critère Flexibilité correspond aussi au nombre de façons différentes mises à la disposition des utilisateurs pour atteindre un objectif donné. Il s’agit en d’autres termes de la capacité de l’interface à s’adapter à des actions variées des utilisateurs.

Justification(s) :

Plus les façons d’effectuer une même tâche sont diverses, plus les chances que l’utilisateur puisse choisir et maîtriser l’une d’entre elles, au cours de ses apprentissages, sont importantes.

Exemples de recommandations :

  • Quand les exigences utilisateurs sont imprécises, fournir aux utilisateurs une certaine latitude dans les possibilités de contrôle des affichages.
  • Pour l’entrée de données, lorsque des valeurs par défaut ne sont pas connues à l’avance, le système doit permettre aux utilisateurs de définir, changer ou supprimer ces valeurs.
  • Quand certains affichages sont inutiles, les utilisateurs doivent pouvoir les désactiver temporairement.
  • La séquence des entrées de données doit pouvoir être modifiée pour s’adapter à l’ordre souhaité par les utilisateurs.
  • Lorsqu’on ne peut spécifier à l’avance le format d’un document, on doit permettre aux utilisateurs d’en définir un et de le sauvegarder pour une utilisation ultérieure.
  • Les utilisateurs devrait pouvoir assigner eux-mêmes le nom des champs de données qu’ils créent.

Commentaire(s) :

Flexibilité vs Actions Minimales

Le critère Flexibilité concerne l’existence de procédures différentes, quelles soient ou non minimales, permettant d’accomplir une même tâche, ou encore des moyens permettant d’adapter l’interface aux besoins particuliers d’un utilisateur.

Flexibilité vs Prise en Compte de l’Expérience de l’Utilisateur

Une bonne flexibilité doit permettre à la population générale des utilisateurs d’adapter l’interface à ses besoins particuliers. Quand une interface concerne plusieurs types d’utilisateurs ou un type particulier d’utilisateurs et que l’interface permet d’effectuer une tâche de plusieurs façons, en fonction du degré d’expérience des utilisateurs,alors il s’agit du critère Prise en Compte de l’Expérience de l’Utilisateur.

En d’autres termes, dès que l’expérience est invoquée, en rapport avec l’interface, le critère Prise en Compte de l’Expérience de l’Utilisateur est impliqué.

Flexibilité vs Compatibilité

La flexibilité peut être un moyen d’assurer une certaine compatibilité. Cependant la flexibilité peut être satisfaite sans que la compatibilité le soit. Ainsi, dans un dialogue par formulaire, l’ordre et le groupement des informations peut ne pas correspondre aux documents papier. Dans ce cas, il s’agit d’un problème de Compatibilité, qu’il soit possible (alors il y a une certaine flexibilité) ou non (alors il n’y a pas de flexibilité) de modifier la séquence d’entrée de données.

4.2 Prise en Compte de l’Expérience de l’Utilisateur *

Définition :

Le critère Prise en Compte de l’Expérience de l’Utilisateur concerne les moyens mis en oeuvre pour respecter le niveau d’expérience de l’utilisateur.

Justification(s) :

Des utilisateurs expérimentés n’ont pas toujours les mêmes besoins informationnels que les novices. Il peut être souhaitable de fournir aux utilisateurs inexpérimentés des transactions très guidées, au pas-à-pas. Pour des utilisateurs expérimentés, des dialogues à la seule initiative de l’ordinateur peuvent les ennuyer et ralentir leurs interactions; par contre, des raccourcis peuvent leur permettre d’accéder plus rapidement aux fonctions du système. Des moyens différenciés doivent donc être prévus pour tenir compte de ces différences d’expérience.

Cependant, l’expérience des utilisateurs peut varier. Les utilisateurs peuvent devenir plus experts à force d’utilisation, ou moins experts après de longues périodes de non-utilisation. L’interface doit aussi être conçue afin de tenir compte de ces variations du niveau d’expérience.

Exemples de recommandations :

  • Autoriser les utilisateurs expérimentés à contourner une série de sélections par menu en formulant directement des commandes ou par des raccourcis clavier.
  • Prévoir des choix d’entrées pas-à-pas ou multiples selon l’expérience des utilisateurs.
  • Autoriser différents modes de dialogue correspondant aux différents groupes d’utilisateurs (ex.: permettre une incitation adaptée au niveau d’expérience des utilisateurs).
  • Permettre la saisie de plusieurs commandes avant confirmation pour les expérimentés.
  • Lorsque les techniques de guidage ralentissent les utilisateurs expérimentés, fournir des moyens à ces utilisateurs de contourner ce guidage.
  • Les utilisateurs devraient pouvoir demander un niveau de détail des messages d’erreurs qui soit fonction de leur niveau de connaissance.

Commentaire(s) :

Prise en Compte de l’Expérience de l’Utilisateur vs Actions Minimales

Le critère Actions Minimales concerne la longueur des transactions et des procédures quel que soit le niveau d’expérience des utilisateurs.

Quand la longueur des transactions et des procédures apparaît inadaptée pour un groupe particulier d’utilisateurs (ex.: qu’il n’existe pas de raccourcis clavier pour les utilisateurs expérimentés), il s’agit alors du critère Prise en Compte de l’Expérience de l’Utilisateur.

Prise en Compte de l’Expérience de l’Utilisateur vs Flexibilité

Une bonne flexibilité doit permettre à la population générale des utilisateurs d’adapter l’interface à ses besoins particuliers. Quand une interface concerne plusieurs types d’utilisateurs ou un type particulier d’utilisateurs et que l’interface permet d’effectuer une tâche de plusieurs façons, en fonction du degré d’expérience des utilisateurs,alors il s’agit du critère Prise en Compte de l’Expérience de l’Utilisateur.

En d’autres termes, dès que l’expérience est invoquée, en rapport avec l’interface, le critère Prise en Compte de l’Expérience de l’Utilisateur est impliqué.

5. Gestion des erreurs

Définition :

Le critère Gestion des Erreurs concerne tous les moyens permettant d’une part d’éviter ou de réduire les erreurs, et d’autre part de les corriger lorsqu’elles surviennent. Les erreurs sont ici considérées comme des saisies de données incorrectes, des saisies dans des formats inadéquats, des saisies de commandes avec une syntaxe incorrecte, etc.

Trois sous-critères participent à la Gestion des Erreurs : Protection Contre les Erreurs, Qualité des Messages d’Erreurs et Correction des Erreurs.

Justification(s) :

Les interruptions provoquées par les erreurs ont des conséquences négatives sur l’activité des utilisateurs. De manière générale, elles rallongent les transactions et perturbent la planification. Plus les erreurs sont limitées, moins il y a d’interruptions au cours de la réalisation d’une tâche et meilleure est la performance.

5.1 Protection contre les erreurs *

Définition :

Le critère Protection Contre les Erreurs concerne les moyens mis en place pour détecter et prévenir les erreurs d’entrées de données ou de commandes ou les actions aux conséquences néfastes.

Justification(s) :

Il est préférable de détecter les erreurs lors de la saisie plutôt que lors de la validation : ceci évite de perturber la planification.

Exemples de recommandations :

  • Quand les utilisateurs terminent une session et qu’il y a un risque de perte de données, il doit y avoir un message le signalant et demandant confirmation de fin de session.
  • Les labels de champs doivent être protégés.
  • Les aires d’affichage doivent être protégés : les utilisateurs ne doivent pas pouvoir changer les informations contenues dans ces champs.
  • Toutes les actions possibles sur une interface doivent être envisagées et plus particulièrement les appuis accidentels des touches du clavier afin que les entrées non attendues soient détectées.

Commentaire(s) :

Protection Contre les Erreurs vs Incitation

Plusieurs façons d’offrir une protection contre les erreurs sont possibles. On peut par exemple mettre en place un mécanisme automatique de vérification des entrées.Ainsi, au moment de la validation des entrées, un message d’erreur apparaît si le format d’entrée n’est pas conforme à ce qui est attendu. Il s’agit bien dans ce cas-ci du critère Protection Contre les Erreurs. Une autre façon consiste à fournir une information renseignant les utilisateurs sur le type de données attendues ou encore sur le format de ces entrées : il s’agit alors du critère Incitation. Ces deux mécanismes peuvent aussi coexister.

5.2 Qualité des messages d'erreur *

Définition :

Le critère Qualité des Messages d’Erreur concerne la pertinence, la facilité de lecture et l’exactitude de l’information donnée aux utilisateurs sur la nature des erreurs commises (syntaxe, format, etc.) et sur les actions à entreprendre pour les corriger.

Justification(s) :

La qualité des messages favorise l’apprentissage du système en indiquant aux utilisateurs les raisons ou la nature de leurs erreurs et en leur indiquant ce qu’il faut ou ce qu’ils auraient dû faire.

Exemples de recommandations :

  • Si l’utilisateur sélectionne une touche fonction non valide, aucune action ne doit en résulter, si ce n’est un message indiquant les fonctions appropriées à cette étape de la transaction.
  • Fournir des messages d’erreurs orientés tâches.
  • Utiliser des termes aussi spécifiques que possibles pour les messages d’erreur.
  • Utiliser des messages d’erreur aussi brefs que possible.
  • Adopter un vocabulaire neutre, non personnalisé, non réprobateur dans les messages d’erreur; éviter l’humour.

Commentaire(s) :

Qualité des messages d’erreur vs Incitation

Un message d’erreur, peut comporter des incitations sur la manière de corriger une erreur. Il s’agit là du critère Qualité des Messages d’Erreur et non pas du critère Incitation. L’Incitation concerne uniquement le guidage en situation normale.

Qualité des Messages d’Erreur vs Lisibilité

Quand les messages d’erreur ne sont pas adéquats, même du point de vue lexical, il s’agit du critère Qualité des Messages d’Erreur, et non du critère Lisibilité. Le critère Qualité des Messages d’Erreur concerne toutes les caractéristiques des informations relatives aux erreurs des utilisateurs.

Qualité des Messages d’Erreur vs Concision

Le critère Concision ne s’applique pas aux messages d’erreurs. Lorsque ces derniers ne sont pas suffisamment succincts, il s’agit du critère Qualité des Messages d’Erreur.

5.3. Correction des erreurs *

Définition :

Le critère Correction des Erreurs concerne les moyens mis à la disposition des utilisateurs pour leur permettre de corriger leurs erreurs.

Justification(s) :

Les erreurs sont d’autant moins perturbatrices qu’elles sont faciles à corriger.

Exemples de recommandations :

  • Fournir la possibilité de modifier les commandes lors de leur saisie.
  • Suite à une erreur de saisie d’une commande ou de données, donner aux utilisateurs la possibilité de corriger seulement la portion de données ou de commande qui est erronée.
  • Si les utilisateurs se rendent compte qu’ils ont commis une erreur d’entrée de données, leur donner la possibilité d’effectuer, au moment de leur détection d’erreur, les corrections souhaitées.

Commentaire(s) :

Correction des Erreurs vs Actions Minimales

Les problèmes liés au critère Actions Minimales peuvent résulter de mécanismes de correction des erreurs inadéquats. Lorsque le nombre d’actions nécessaires à la correction des erreurs peut être réduit, il s’agit d’un problème de Correction des Erreurs. Le critère Actions Minimales concerne donc les procédures autres que celles liées à la correction des erreurs.

6. Homogénéité/Cohérence *

Définition :

Le critère Homogénéité/Cohérence se réfère à la façon avec laquelle les choix de conception de l’interface (codes, dénominations, formats, procédures, etc.) sont conservés pour des contextes identiques, et sont différents pour des contextes différents.

Justification(s) :

Les procédures, labels, commandes, etc., sont d’autant mieux reconnus, localisés et utilisés, que leur format, localisation, ou syntaxe sont stables d’un écran à l’autre,d’une session à l’autre. Dans ces conditions le système est davantage prévisible et les apprentissages plus généralisables; les erreurs sont réduites. Le manque d’homogénéité peut augmenter considérablement le temps de recherche.

Le manque d’homogénéité est aussi une raison importante du refus d’utilisation.

Exemples de recommandations :

  • • Localisation similaire des titres des fenêtres.

  • • Formats d’écrans similaires.

  • • Procédures similaires d’accès aux options de menus.

  • • Lors du guidage, toujours utiliser les mêmes ponctuations et les mêmes constructions de phrases.

  • • Afficher à la même position les “prompts” pour la saisie des données ou des commandes.

  • • Le format des champs d’entrée de données doit toujours être le même.

Commentaire(s) :

Homogénéité/Cohérence vs Incitation

Dès qu’il s’agit de considérer ou de comparer plusieurs interactions, plusieurs objets, etc., y compris avec un objectif d’incitation, il s’agit en fait du critère Homogénéité/Cohérence. Par exemple, présenter les titres des fenêtres dans des positions identiques concerne le critère Homogénéité/Cohérence.

Homogénéité/Cohérence vs Compatibilité

Le critère Homogénéité/Cohérence s’applique au sein d’une interface donnée.

Lorsque la cohérence concerne des aspects externes à l’application (ex.: formulaires papier) ou concerne d’autres applications ou environnements, on parle alors de Compatibilité. 3 (ou CONSISTENCE)* Critère élémentaire

7. Signifiance des Codes et Dénominations *

Définition :

Le critère Signifiance des Codes et Dénominations concerne l’adéquation entre l’objet ou l’information affichée ou entrée, et son référent. Des codes et dénominations “signifiants” disposent d’une relation sémantique forte avec leur référent.

Justification(s) :

Lorsque le codage est signifiant, le rappel et la reconnaissance sont meilleurs. De plus, des codes et dénominations non significatifs pour les utilisateurs peuvent leur suggérer des opérations inappropriées et ainsi conduire à des erreurs.

Exemples de recommandations :

  • • Les titres doivent véhiculer ce qu’ils représentent, et être distincts.

  • • Rendre les règles d’abréviation explicites.

  • • Utiliser des codes et dénominations significatifs et familiers plutôt que des codes et dénominations arbitraires (ex.: M pour masculin et F pour féminin plutôt que 1 et2).

Commentaire(s) :

Signifiance des Codes et Dénominations vs Lisibilité

Le critère Lisibilité ne concerne pas les aspects sémantiques des informations, leur pertinence ou leur signification. Ceux-ci sont davantage du ressort du critère Signifiance des Codes et Dénominations.

8. Compatibilité *

Définition :

Le critère Compatibilité se réfère à l’accord pouvant exister entre les caractéristiques des utilisateurs (mémoire, perceptions, habitudes, compétences, âge, attentes, etc.) et des tâches, d’une part, et l’organisation des sorties, des entrées et du dialogue d’une application donnée, d’autre part.

De plus, la Compatibilité concerne également le degré de similitude entre divers environnements ou applications.

Justification(s) :

Le transfert d’information d’un contexte à un autre est d’autant plus rapide et efficace que le volume d’information à recoder par l’utilisateur est réduit.

L’efficacité est accrue lorsque : les procédures nécessaires à l’accomplissement de la tâche sont compatibles avec les caractéristiques psychologiques des utilisateurs; les procédures et les tâches sont organisées de manière à respecter les attentes, ou habitudes des utilisateurs; les traductions, les transpositions, les interprétations, ou références à la documentation sont minimisées.

Les performances sont meilleures lorsque l’information est présentée sous une forme directement utilisable.

Exemples de recommandations :

  • • L’organisation des informations affichées doit être conforme à l’organisation des données à entrer.

  • • Les procédures de dialogue doivent être compatibles avec l’ordre tel que se l’imagine l’utilisateur ou celui dont il a l’habitude.

  • • Le format de date en français est “jour/mois/année”. En anglais, ce format devient “mois/jour/année”.

  • • Les termes employés doivent être familiers aux utilisateurs, et relatifs à la tâche à réaliser.

  • • Les unités de mesure doivent être celles qui sont normalement utilisées.

  • • L’affichage de texte à l’écran doit être conforme aux conventions utilisées pour la présentation des textes sur papier.

Commentaire(s) :

Compatibilité vs Incitation

Lorsque les termes utilisés lors de l’incitation ne sont pas ceux couramment employés par les utilisateurs, on est en présence d’un problème de Compatibilité.

Compatibilité vs Lisibilité

Le critère Lisibilité ne concerne pas les aspects sémantiques des informations, leur pertinence ou leur signification. Quand ces aspects sont liés aux tâches, le critère à considérer est la Compatibilité.

Compatibilité vs Actions Minimales

Un manque de compatibilité (ex.: un manque d’adéquation des procédures avec les tâches) peut conduire à une augmentation des actions nécessaires à l’accomplissement d’une tâche. Dans ce cas, il faut invoquer le critère Compatibilité et non pas Actions Minimales qui en est la conséquence, pas la cause.

Compatibilité vs Flexibilité

La flexibilité peut être un moyen d’assurer une certaine compatibilité. Cependant la flexibilité peut être satisfaite sans que la compatibilité le soit. Ainsi, dans un dialogue par formulaire, l’ordre et le groupement des informations peut ne pas correspondre aux documents papier. Dans ce cas, il s’agit d’un problème de Compatibilité, qu’il soit possible (alors il y a une certaine flexibilité) ou non (alors il n’y a pas de flexibilité) de modifier la séquence d’entrée de données.

Compatibilité vs Homogénéité/Cohérence

Le critère Homogénéité/Cohérence s’applique au sein d’une interface donnée.

Lorsque la cohérence concerne des aspects externes à l’application (ex.: formulaires papier) ou concerne d’autres applications ou environnements, on parle alors de Compatibilité.

Prêt à simplifier votre processus d’évaluation d’interface?

Essayez Capian gratuitement