Les 10 heuristiques de Nielsen et les lois de l'UX

Les heuristiques de Nielsen sont dix principes généraux de conception d'interface, publiés par Jakob Nielsen en 1994, qui servent de règles empiriques pour concevoir un écran et pour en repérer rapidement les défauts. Ce chapitre explique chacune d'elles avec un exemple sur Prêt'Matos, les fait correspondre aux critères de Bastien et Scapin, puis présente les quelques lois issues de la psychologie que tout développeur d'interface devrait connaître (Fitts, Hick, Jakob, la Gestalt) et le rôle des design systems.

Dix règles empiriques

Jakob Nielsen, chercheur danois en utilisabilité, a établi ces principes avec Rolf Molich en 1990, puis les a affinés en 1994 à partir de l'analyse de plus de deux cents problèmes d'utilisabilité relevés sur de vraies interfaces. Il les appelle heuristiques parce que ce sont des règles générales, des raccourcis de jugement, et non des normes précises : elles ne te disent pas quelle couleur choisir, elles te disent quoi vérifier. Les dix heuristiques n'ont pas changé depuis ; en 2020, le Nielsen Norman Group a seulement retouché la formulation des définitions et ajouté des exemples.

Les dix heuristiques sur Prêt'Matos

1. Visibilité de l'état du système. L'utilisateur doit toujours savoir où il en est : la page où il se trouve, ce que l'application fait, le résultat de son action. Sur Prêt'Matos : « Envoi de la réservation… » pendant l'appel à l'API, puis « Réservation enregistrée », un badge « En retard » sur le prêt concerné, l'onglet actif du menu mis en évidence. Contre-exemple : un bouton qui ne réagit pas pendant deux secondes, si bien que le salarié clique trois fois.

2. Correspondance avec le monde réel. Les mots, les icônes et l'ordre des informations sont ceux des utilisateurs, pas ceux de la base de données. « Réserver », « Rendre », « Matériel disponible », dans l'ordre où l'on pense une demande (quoi, quand). Contre-exemple : « Statut : 2 », « Créer un mouvement de type SORTIE ».

3. Contrôle et liberté de l'utilisateur. Les gens se trompent de bouton : il leur faut une « sortie de secours » clairement signalée. Un bouton « Annuler » dans chaque formulaire, l'annulation d'une réservation, le retour en arrière du navigateur qui fonctionne. Contre-exemple : une fenêtre modale qui ne se ferme ni par Échap ni par une croix.

4. Cohérence et standards. Les utilisateurs ne devraient pas se demander si deux mots, deux icônes ou deux actions différents veulent dire la même chose. Cohérence interne (le même bouton partout dans Prêt'Matos) et externe (les conventions du Web : le logo ramène à l'accueil, un texte souligné est un lien, la croix en haut à droite ferme). Cette heuristique recouvre l'homogénéité et une partie de la compatibilité de Bastien et Scapin.

5. Prévention des erreurs. Un bon message d'erreur, c'est bien ; pas d'erreur du tout, c'est mieux. On distingue deux sortes d'erreurs : les glissements (slips), quand on voulait faire la bonne chose et qu'on fait la mauvaise par inattention (cliquer sur le mauvais bouton), et les méprises (mistakes), quand on se fait une idée fausse du système (croire que réserver suffit à recevoir le matériel par courrier interne). Contre les glissements : des contraintes (les dates indisponibles ne sont pas cliquables), de bonnes valeurs par défaut, une confirmation avant l'irréversible. Contre les méprises : un modèle mental juste, expliqué au bon endroit (« À retirer au stock, bâtiment B, de 8 h à 17 h »).

6. Reconnaissance plutôt que rappel. La mémoire à court terme est limitée ; reconnaître une option affichée demande moins d'effort que de s'en souvenir. Sur Prêt'Matos : la liste des matériels avec photo plutôt qu'un champ où taper un code, le récapitulatif de la réservation visible au moment de confirmer, les dernières recherches proposées. Contre-exemple : un écran de retour qui demande de saisir le numéro de la réservation sans l'afficher nulle part.

7. Flexibilité et efficacité d'utilisation. Des accélérateurs, invisibles pour le débutant, font gagner du temps à l'habitué : raccourcis clavier pour la logistique, « Réserver à nouveau », filtres mémorisés, scan de l'étiquette. Le débutant n'en a pas besoin pour réussir sa tâche ; l'expert ne s'en passerait plus.

8. Esthétique et design minimaliste. Chaque information supplémentaire dans un écran fait concurrence aux informations utiles et diminue leur visibilité. Il ne s'agit pas de faire « plat » ou « blanc », mais de hiérarchiser : ce qui sert à la tâche en premier, le reste un clic plus loin. Contre-exemple : la page d'accueil de Prêt'Matos avec les actualités de l'entreprise, la météo et un carrousel, et le bouton « Réserver » perdu en bas.

9. Aider à reconnaître, diagnostiquer et réparer les erreurs. Les messages d'erreur sont en langage clair (pas de code), indiquent précisément le problème et proposent une solution, avec des signes visuels reconnaissables (texte, icône, emplacement). « Choisissez une date de retour au plus tard le 26/03/2027 : un prêt dure 15 jours au maximum. » Contre-exemple : « Une erreur est survenue. »

10. Aide et documentation. Le mieux est une application qui n'en a pas besoin ; mais quand une aide est nécessaire, elle doit être facile à trouver, centrée sur la tâche et concrète : une aide en ligne courte (« Comment annuler une réservation ? »), une info-bulle au bon endroit, le contact de la logistique visible au même endroit sur chaque page. La documentation d'utilisation fait partie de ce que le référentiel attend de toi ; le cours documentation technique montre comment l'écrire, et le cours de maintenance comment la tenir à jour.

Nielsen ou Bastien et Scapin ?

Les deux grilles se recouvrent largement. Celle de Nielsen est plus courte et plus connue dans le monde ; celle de Bastien et Scapin est plus détaillée et plus utilisée dans l'enseignement et les audits en France. Tu peux citer l'une ou l'autre en entretien, à condition de ne pas mélanger leurs mots.

Deux différences méritent d'être retenues. Bastien et Scapin distinguent les actions explicites (le système ne fait rien qu'on ne lui ait demandé), que Nielsen ne nomme pas. Nielsen insiste sur l'aide et la documentation, que Bastien et Scapin rangent dans l'incitation.

Les lois de l'UX utiles au développeur

Plusieurs résultats de la psychologie expérimentale expliquent pourquoi les règles précédentes fonctionnent. Tu n'as pas besoin de les démontrer ; tu dois savoir les appliquer et les nommer.

La loi de Fitts : la taille et la distance des cibles

Le psychologue Paul Fitts a montré en 1954 que le temps pour atteindre une cible avec un mouvement (la souris, le doigt) augmente avec la distance à parcourir et diminue avec la taille de la cible. Dans la formulation utilisée en IHM, le temps de pointage vaut :

T = a + b × ID        avec  ID = log2(D / L + 1)

D  : distance jusqu'au centre de la cible
L  : largeur de la cible dans la direction du mouvement
ID : indice de difficulté, en bits
a, b : constantes mesurées pour un dispositif (souris, doigt, pavé tactile)

Tu n'as pas besoin de connaître a et b pour comparer deux dispositions : il suffit de comparer les indices de difficulté. Sur le téléphone d'un commercial, le pouce part du bas de l'écran ; le bouton « Réserver » est à 400 pixels.

Le bouton large réduit l'indice de difficulté d'environ 39 % : il est plus rapide à atteindre et on le rate moins souvent. Les conséquences pratiques :

• les actions fréquentes ou importantes ont de grandes cibles ; sur mobile, au moins 44 à 48 pixels de côté (chapitre 7) ;
• on les place près de l'endroit où se trouve déjà le pointeur ou le pouce : le bouton « Réserver » sous le formulaire, pas en haut de la page ;
• les bords et les coins de l'écran sont des cibles « infinies » à la souris, car le pointeur s'y arrête : c'est pourquoi les menus des systèmes d'exploitation y sont placés ;
• à l'inverse, une action dangereuse (« Supprimer ») gagne à être éloignée de l'action fréquente, pour ne pas être touchée par erreur.

La loi de Hick : le nombre de choix

Les psychologues William Hick (1952) et Ray Hyman (1953) ont montré que le temps pour choisir parmi des options connues augmente avec leur nombre, selon un logarithme : T = b × log2(n + 1). Doubler le nombre d'options n'en double pas le temps de décision, mais chaque option en plus ajoute de l'hésitation.

La conséquence n'est pas « moins de 7 éléments dans un menu », mais : ne montre que les choix utiles à l'étape en cours. Le formulaire de réservation propose les types de matériel (portable, vidéoprojecteur, casque) avant les 60 matériels du parc ; les options avancées du planning de la logistique sont repliées. La loi vaut pour des options que l'utilisateur connaît et compare ; face à une longue liste inconnue, il la parcourt de haut en bas, et c'est alors l'ordre (alphabétique, par fréquence) et la recherche qui comptent.

La loi de Jakob : les habitudes viennent d'ailleurs

Nielsen l'a formulée ainsi : les utilisateurs passent l'essentiel de leur temps sur d'autres sites et applications que le tien. Ils arrivent donc avec des attentes : le panier en haut à droite, le logo qui ramène à l'accueil, la loupe pour chercher, le geste de balayage pour supprimer dans une liste sur mobile. Innover sur ces conventions a un coût d'apprentissage ; fais-le seulement si le gain est net. C'est l'heuristique 4 (cohérence et standards) et le critère de compatibilité.

Les lois de la Gestalt : percevoir des groupes

La psychologie de la forme (Gestalt) décrit comment l'œil regroupe spontanément les éléments. Deux lois servent tous les jours :

• la proximité : des éléments proches sont perçus comme un groupe. Le libellé doit être plus près de son champ que du champ précédent, sinon on ne sait plus à quel champ il appartient ;
• la similarité : des éléments qui se ressemblent (couleur, forme, taille) sont perçus comme de même nature. Si les badges « Disponible » et le bouton « Réserver » ont la même couleur et la même forme, on clique sur le badge.

Elles fondent le critère de groupement et distinction entre items de Bastien et Scapin. L'espace blanc n'est pas du vide : c'est l'outil le plus simple pour grouper et séparer.

Les seuils de temps de réponse

Nielsen reprend trois ordres de grandeur, établis dès les années 1960, pour le temps de réaction d'un système :

Ce tableau traduit l'heuristique 1 en règles de code : un appel à l'API qui peut durer plus d'une seconde mérite un état de chargement, et un export de plusieurs dizaines de secondes, une progression.

Les design systems : des règles déjà écrites

Un design system est un ensemble de règles, de composants et de ressources qui donne à toutes les interfaces d'une organisation une apparence et un comportement cohérents : couleurs, typographie, espacements, boutons, champs, messages, avec leurs états et leurs règles d'usage. Les grands éditeurs publient le leur, et ce sont autant de recueils d'heuristiques appliquées :

Suivre le design system de la plateforme, c'est appliquer d'un coup la cohérence externe (loi de Jakob) : une application Android qui respecte Material Design fonctionne comme les autres applications du téléphone. Pour une application interne comme Prêt'Matos, l'équipe crée un petit design system maison : une palette, deux tailles de texte, un composant Bouton à trois variantes, un composant Champ avec son message d'erreur. Le chapitre 5 montre comment.

Exercices