Dix principes écrits en 1994, toujours valables, et toujours aussi peu appliqués. Le problème n’est pas qu’ils soient faux, c’est qu’ils sont écrits pour des ergonomes. Voici les mêmes, formulés comme un utilisateur les dirait, avec le symptôme qui trahit chacun d’eux sur un écran réel.
Il y a presque toujours, dans un produit, une page dont tout le monde sait qu’elle ne va pas. Le formulaire que les gens commencent et n’envoient jamais. L’écran derrière la moitié des appels au support. La fiche produit qui reçoit du trafic et ne convertit rien.
Tout le monde le sent. Personne n’arrive à le formuler autrement que par « c’est pas clair ». Et une réunion qui part de « c’est pas clair » se termine en discussion de goûts, où celui qui parle le plus fort gagne.
C’est exactement le problème que résout une évaluation heuristique. Pas de rendre l’écran beau, ni de deviner ce que veulent les utilisateurs. De donner un nom à ce qui cloche, pour qu’on puisse en discuter et le corriger.
Une évaluation heuristique, c’est la relecture d’une interface par quelqu’un qui connaît le métier, à l’aide d’une grille de critères publiée. On passe l’écran au crible, et chaque problème identifié est rattaché à un critère nommé.
Trois choses qu’il faut dire tout de suite.
Un expert prédit les problèmes, il ne les observe pas. Il se trompe parfois, et il ne verra jamais certaines choses qu’un vrai utilisateur révèle en trente secondes. En revanche, ça coûte une journée là où un test en coûte cinq, et ça permet d’arriver au test avec les problèmes évidents déjà corrigés. C’est une préparation, pas un substitut.
La tentation est forte de sortir un score sur cent. C’est une mauvaise idée : un score se discute, un constat se corrige. Ce qui sert, c’est « le bouton ne change pas d’état après le clic », pas « utilisabilité : 62 sur 100 ».
C’est tout l’intérêt de la grille. Deux ergonomes qui appliquent les mêmes critères sur le même écran trouvent largement les mêmes choses. Sans grille, ils donnent deux avis.
Jakob Nielsen les a publiés en 1994. Ils portent des noms qui parlent aux gens du métier et à personne d’autre. Alors voici la version qu’un utilisateur dirait lui-même, et ce qui la trahit sur un écran.
Visibilité de l’état du système.
Le symptôme : l’utilisateur clique, rien ne bouge, il reclique. Vous retrouvez trois fois la même demande côté serveur. Ou bien une page de résultats qui n’annonce ni combien de résultats elle a trouvés, ni quels filtres sont actifs, ni où on se trouve dans la liste. Le système connaît les trois réponses et n’en affiche aucune.
La correction : un état visible sur chaque action qui prend du temps, et un message qui nomme ce qui vient de se passer.
Correspondance entre le système et le monde réel.
Le symptôme : les libellés viennent de la base de données. L’utilisateur cherche « nouvelle demande » et trouve « créer une occurrence ». Il hésite, il clique ailleurs, il appelle.
La correction : reprendre les mots que les gens emploient quand ils décrivent leur travail. Ça se récolte en trois entretiens, pas en réunion d’équipe.
Contrôle et liberté.
Le symptôme : un parcours en cinq étapes sans lien de retour et sans brouillon sauvegardé. Le seul recours est le bouton précédent du navigateur, qui efface tout. Ou une fenêtre qui met en avant l’action que vous préférez, et relègue l’autre dans un petit lien en haut à droite.
La correction : un retour possible à chaque étape, un enregistrement automatique, et une annulation tant que rien n’est confirmé.
Cohérence et normes.
Le symptôme : « Envoyer », « Valider » et « Confirmer » déclenchent la même opération sur trois pages du même site. Ou un sélecteur de date qui affiche le mois en anglais et les jours en français. La rupture est rarement décidée, elle arrive par accumulation : un composant tiers ici, une chaîne oubliée dans la traduction là.
La correction : un mot par action, décidé une fois, écrit dans une liste que tout le monde utilise. Ce n’est pas du design, c’est de la gouvernance de contenu.
Prévention des erreurs.
Le symptôme : un champ date en saisie libre, aucun format indiqué, et un message rouge après validation. Ou un calendrier qui laisse choisir une date déjà passée sur un écran qui sert à planifier.
La correction : rendre l’erreur impossible plutôt que de la signaler. Désactiver une plage de dates prend quelques lignes. Traiter les réclamations de ceux qui se sont trompés, c’est un ticket par semaine pendant des années.
Reconnaître plutôt que se rappeler.
Le symptôme : une information saisie à l’étape 2 et redemandée à l’étape 4. Aucun récapitulatif, aucune reprise de ce qui a déjà été fourni. Toute la charge mentale est sur l’utilisateur.
La correction : rappeler à l’écran ce qui est déjà connu, et pré-remplir tout ce que le système sait déjà. Il en sait toujours plus qu’il ne le montre.
Flexibilité et efficience.
Le symptôme : sept clics pour une opération que certains répètent quarante fois par jour. Ou l’inverse, un raccourci qui existe vraiment mais que rien n’annonce, et que seuls ceux à qui on l’a montré utiliseront.
La correction : garder le chemin long par défaut, ajouter un chemin court, et le rendre découvrable. Un accélérateur invisible ne sert personne.
Design esthétique et minimaliste.
Le symptôme : quatre appels à l’action de même poids visuel, deux bandeaux, un carrousel. Ou une carte de résultat qui porte dix-huit éléments et six couleurs, où le prix, seul critère que l’utilisateur vient comparer, ne ressort pas plus que le reste.
La correction : une action principale par écran, tout le reste descendu d’un cran. Enlever coûte moins cher qu’ajouter.
Reconnaissance, diagnostic et réparation des erreurs.
Le symptôme : « Une erreur est survenue ». Un code, aucune indication du champ concerné, aucune action proposée. L’utilisateur appelle le support ou il part. Les deux coûtent, et une seule se voit dans les statistiques.
La correction : nommer le problème dans les mots de l’utilisateur, désigner l’endroit exact, proposer l’action suivante. Trois phrases écrites par quelqu’un qui a compris le contexte.
Aide et documentation.
Le symptôme : un lien « Aide » en pied de page, une FAQ classée selon l’organigramme de l’entreprise, et rien au moment précis où l’utilisateur bloque.
La correction : l’aide au point de friction, écrite en tâches et pas en fonctionnalités. « Comment corriger une commande déjà envoyée », pas « Module de gestion des commandes ».
Prenez un écran, un seul, et une heure devant vous.
Parcourez les dix principes dans l’ordre, et pour chacun, posez la question en « je ». Est-ce que je sais ce qui se passe. Est-ce que je comprends les mots. Est-ce que je peux revenir. Vous verrez que certains principes ne s’appliquent pas à cet écran, c’est normal, passez.
Pour chaque problème trouvé, écrivez trois lignes : ce que vous observez, le critère concerné, ce que vous feriez. Décrivez, ne jugez pas. « Le bouton reste identique pendant les deux secondes de traitement » est utilisable par un développeur. « L’interface manque de feedback » ne l’est pas.
Deux pièges courants. Le premier est de tout noter, y compris ce qui relève du goût, ce qui noie les vrais problèmes. Le second est de corriger en même temps qu’on relève, ce qui fait perdre le fil et produit une liste incomplète.
La grille de Nielsen dit si un écran fonctionne. Elle ne dit pas s’il convainc, ni ce qu’il produit chez la personne qui l’utilise.
C’est pour ça qu’on la croise avec les critères de Bastien et Scapin, publiés par l’INRIA en 1993, qui découpent l’utilisabilité plus finement et permettent de rattacher un constat à un critère précis plutôt qu’à un principe général. Les deux grilles se recouvrent en partie, et c’est tant mieux : un problème que les deux signalent est un problème qu’on corrige en premier.
Et sur certains produits on ajoute une lecture de l’expérience elle-même, la valeur perçue, la confiance, le sentiment qui reste. Un site qui vend de l’expertise se juge autant là-dessus que sur son nombre de clics.
Envoyez-nous son adresse, ou une capture si elle n’est pas publique. Un expert UX de Jems Benelux vous renvoie trois constats rattachés à un critère nommé, et la chose à corriger en premier. Sous 48 heures, gratuitement, sans engagement.
Sources : Nielsen, J., « 10 Usability Heuristics for User Interface Design », 1994. Bastien, J.M.C. et Scapin, D.L., « Ergonomic criteria for the evaluation of human-computer interfaces », INRIA, 1993.
