Une checklist de cohérence UI que vous pouvez réellement appliquer

La liste standard pose des questions comme « l'aspect visuel de l'interface est-il cohérent ? » ou « les libellés sont-ils utilisés de manière cohérente ? ». Ce ne sont que des reformulations de l'objectif. La personne qui mène l'audit doit convertir chaque question en un élément vérifiable, et elle le fera différemment à chaque fois — ce qui rend l'audit lui-même incohérent.

Pour être utile, une vérification nécessite trois éléments : un point précis à observer, un moyen de l'observer et une condition déterminant le succès ou l'échec. Tout ce qui suit possède ces trois éléments.

Cinq minutes, aucun jugement requis, et cela révèle une part surprenante de dérives réelles. Chacune de ces vérifications devrait finir dans la CI une fois validée ; une vérification qui n'est effectuée que lors des audits laisse la dérive s'accumuler entre deux sessions.

1. 1

   Valeurs de couleurs littérales en dehors du fichier de tokens

   La vérification au rendement le plus élevé. Tout code hexadécimal dans un composant signifie que la couche de tokens a été contournée, et que cette couleur ne peut pas être modifiée centralement.

   Copy

   grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \
     | grep -v 'tokens\|globals.css'

2. 2

   Graisses de police hors plage

   La graisse est l'endroit où la hiérarchie revient silencieusement aux valeurs par défaut du framework. Si votre système définit 400 et 600, tout ce qui est plus gras est une dérive, quel que soit le rendu visuel.

   Copy

   grep -rn --include='*.tsx' -E 'font-(bold|extrabold|black)|font-weight:\s*[78]00' src

3. 3

   Valeurs d'espacement hors échelle

   Les échappatoires via des valeurs arbitraires sont là où le rythme s'arrête. Un seul p-[13px] n'est rien ; quarante d'entre eux constituent un second système d'espacement que personne n'a validé.

   Copy

   grep -rn --include='*.tsx' -E '\b(p|m|gap|space)-\[[0-9]+px\]' src

4. 4

   Valeurs de rayon (radius)

   Le rayon dérive plus que tout le reste car chaque auteur de composant choisit ce qui semble correct isolément. Comptez les valeurs distinctes utilisées ; plus de trois ou quatre constituent un problème.

   Copy

   grep -rhoE 'rounded-[a-z0-9]+|border-radius:\s*[0-9]+px' src -r \
     --include='*.tsx' --include='*.css' | sort | uniq -c | sort -rn

5. 5

   Propriétés interdites par votre système

   Quelles que soient les règles de votre liste d'interdictions. Si elle stipule que l'élévation n'est jamais une ombre, cette vérification l'impose. Si vous n'avez pas de liste d'interdictions, c'est là le problème — rédigez-en une d'abord.

   Copy

   grep -rn --include='*.tsx' --include='*.css' -E 'box-shadow|shadow-(sm|md|lg|xl)|gradient' src

La quatrième vérification présente une nuance importante : compter les valeurs de rayon distinctes renseigne sur la cohérence, pas sur l'exactitude. Trois valeurs utilisées délibérément — 6px pour les contrôles, 12px pour les conteneurs, plein pour les avatars — forment un système. Trois valeurs qui se trouvent être 6, 8 et 10 sont une dérive qui n'a pas été remarquée.

Voici l'erreur commise par tous les processus d'audit. Examiner un écran seul permet de savoir s'il est cohérent en interne. Cela ne dit rien sur sa correspondance avec les autres écrans, car vous ne pouvez pas garder en tête les autres écrans avec assez de précision.

Ouvrez donc trois écrans terminés de la même surface côte à côte — trois écrans d'application, ou trois pages marketing, jamais un mélange. Comparer un tableau de bord à une page d'atterrissage produit des différences qui sont censées être là.

Les trois dernières lignes sont celles où la cohérence est presque toujours la plus faible, et ce n'est pas par négligence : les états vides, de chargement et d'erreur sont rédigés dans l'urgence, individuellement, par quiconque travaillait sur le fichier. Ce sont pourtant ces états qu'un utilisateur frustré voit le plus souvent.

Les six lignes ci-dessus sont les points où les écarts se concentrent. Voici la liste complète, groupée pour être traitée en une seule session. Chaque élément possède une condition de validation plutôt qu'une question.

• Chaque couleur de chaque écran correspond à un rôle nommé. Échec si un composant contient une valeur littérale.
• La couleur d'accentuation apparaît sur les mêmes types d'éléments d'un écran à l'autre. Échec si elle s'applique à un bouton sur un écran et à un titre sur un autre.
• Les couleurs de statut sont utilisées uniquement pour le statut. Échec si la couleur de succès est utilisée à des fins décoratives.
• Chaque couleur du mode clair a une contrepartie en mode sombre choisie et non dérivée. Échec si une surface est une simple inversion.

• Chaque taille à l'écran correspond à un palier de l'échelle. Échec si vous trouvez une taille qui n'en fait pas partie.
• Les graisses restent dans la plage déclarée. Échec si une graisse est supérieure, quel que soit le rendu visuel.
• Le même niveau sémantique a la même apparence partout : chaque titre de page correspond à tous les autres titres de page. Échec si deux écrans distinguent leur titre différemment.
• Les nombres dans les colonnes sont tabulaires et alignés. Échec si les chiffres ne sont pas alignés entre les lignes.

• Chaque valeur d'espacement est un palier de l'échelle. Échec si une valeur arbitraire est utilisée.
• Les valeurs de rayon (radius) distinctes sont peu nombreuses et chacune a un objectif précis. Échec si vous ne pouvez pas justifier la coexistence de 8px et 6px.
• L'élévation est indiquée de la même manière partout. Échec si les ombres et les bordures sont toutes deux utilisées pour la même fonction.
• Le rythme des sections est cohérent : l'écart entre un titre et son contenu est le même sur chaque écran. Échec si une variation existe sans justification.

• Une seule implémentation par composant. Échec si deux fichiers définissent une card.
• Les actions primaires sont identiques et occupent la même position relative. Échec si un écran les place à gauche et un autre à droite.
• Les actions destructives sont visuellement distinctes et le sont de manière cohérente. Échec si l'action de suppression ressemble à une action d'enregistrement quelque part.
• Les éléments interactifs possèdent un état de focus visible, et cet état est identique partout. Échec en cas de focus ring manquant ou divergent.
• Les états désactivés sont visuellement distincts du contenu estompé. Échec si un utilisateur ne peut pas distinguer un contrôle indisponible d'un texte mis en retrait.

• Les états vides utilisent un traitement unique sur l'ensemble du produit. Échec en cas d' illustration ici et de phrase là.
• Le chargement utilise un mécanisme unique. Échec en cas de skeleton, de spinner et de flash blanc sur trois écrans différents.
• Les erreurs apparaissent au même endroit avec le même traitement. Échec en cas de message inline ici et de toast là.
• Le texte d'erreur explique ce qui a échoué et ce qu'il faut faire. Échec pour tout message qui se contente de s'excuser.
• Le contenu long est tronqué de la même manière partout. Échec si un élément revient à la ligne et un autre utilise des points de suspension sans règle établie.

• Un même concept porte un nom unique partout. Échec si l'interface utilise « projet » à un endroit et « espace de travail » à un autre pour la même entité.
• Les boutons nomment l'action qu'ils effectuent, et la confirmation la reprend. Échec en cas de « Envoyer » suivi de « Vos modifications ont été enregistrées ».
• La capitalisation suit une règle unique pour les labels, les titres et les boutons. Échec en cas de mélange entre Title Case et Sentence Case.
• Les dates, les heures et les nombres utilisent un format unique. Échec en cas de deux formats de date dans un même produit.

Le premier élément de ce groupe cause plus de confusion réelle chez l'utilisateur que n'importe quelle incohérence visuelle dans cet article. Deux noms pour un même concept signifient que l'utilisateur doit maintenir deux modèles mentaux et ne peut pas savoir s'il s'agit de la même chose.

Une fois par trimestre, auditez le système plutôt que l'interface. La question n'est pas de savoir si les utilisateurs ont suivi les règles, mais si les règles étaient applicables.

La première ligne est celle qu'il faut vérifier le plus rigoureusement, car une règle nuancée ressemble à une règle exhaustive. Si vos directives contiennent des réserves, les surfaces que ces réserves décrivent nécessitent des documents distincts — la gouvernance couvre la version structurelle de ceci.

Deux facteurs, de directions opposées, qui modifient tous deux la manière de mener cette checklist.

La vérification mécanique devient plus importante, car le volume de code augmente alors que la capacité de revue stagne. Un agent produisant quarante écrans entre deux revues reproduira n'importe quelle dérive quarante fois avant que quiconque ne jette un œil. Les tests automatisés sont la seule chose capable de suivre cette cadence.

La passe comparative devient alors plus importante, et pour une raison plus subtile. Un agent est extrêmement cohérent *au sein* d'un fichier mais n'a aucune mémoire d'une session à l'autre ; son résultat est donc un ensemble d'écrans cohérents en interne, mais qui diffèrent les uns des autres. C'est précisément ce mode de défaillance qu'une revue fichier par fichier ne peut détecter.

La cause racine se trouve généralement en amont. Nous avons analysé 299 fichiers DESIGN.md rédigés pour guider les agents en matière de design : 86 % spécifient les couleurs par codes hexadécimaux bruts sans rôle sémantique, 76 % n'énoncent aucune interdiction, 69 % ne définissent aucun mode sombre, 57 % ne nomment aucun motif et 44 % ne contiennent aucune valeur de taille concrète. 54 % s'appuient sur au moins un adjectif vague — « clean » dans 39 % des cas, « moderne » dans 36 %.

Un tel fichier laisse les décisions de densité, de hiérarchie, d'élévation et d'états vides en suspens, forçant le modèle à les réinventer pour chaque écran. Les problèmes de cohérence constatés malgré ces directives sont réels, et les corriger écran par écran ne sera pas durable. Comment rédiger des directives efficaces.

Si vous disposez de vingt minutes plutôt que d'une journée :

1. Utilisez grep pour rechercher les valeurs hexadécimales en dehors du fichier de tokens. Chaque occurrence est une anomalie.
2. Utilisez grep pour rechercher les graisses de police supérieures à votre plage définie. Chaque occurrence est une anomalie.
3. Comptez les valeurs de rayon (radius) distinctes. S'il y en a plus de quatre, cherchez pourquoi.
4. Ouvrez trois écrans d'une même surface. Comparez la densité, la hiérarchie et l'élévation.
5. Examinez spécifiquement les états vides, de chargement et d'erreur. C'est là que les écarts seront les plus marqués.
6. Vérifiez si vos directives incluent une liste d'interdictions. Si ce n'est pas le cas, c'est là que se trouve la solution pour éviter que le problème ne se reproduise.

Les étapes une à trois sont automatisables aujourd'hui et ne devraient plus jamais être effectuées manuellement. Les étapes quatre et cinq nécessitent une intervention humaine et valent bien une demi-heure régulière. L'étape six est celle qui déterminera si vous devrez recommencer tout cela au prochain trimestre.