s0xDk/refactoring-ui-skill

Refactoring UI

Le design visuel n'est pas du talent. C'est un petit ensemble de décisions systémiques prises une fois, plus quelques techniques pour créer une hiérarchie. Cette compétence, ce sont ces systèmes et ces techniques.

La cause numéro un des interfaces amateurs est le choix de valeurs au cas par cas — 17px ici, #3B82F6 là, lighten(5%) pour un état au survol. Concevez à partir d'une échelle, toujours.

---

Les systèmes — utilisez-les, ne les redérivez pas

Choisissez dans ces listes. N'inventez jamais une valeur qui n'y figure pas.

Espacement et taille

Base 16px, construite à partir de facteurs et de multiples :

4  8  12  16  24  32  48  64  96  128  192  256  384  512  640  768

Serrez au début, écartez à la fin. Deux valeurs adjacentes ne peuvent pas être plus proches que ~25 % — c'est ce qui rend le choix évident. Une échelle linéaire "multiples de 4" échoue : elle ne vous aide pas à choisir entre 120px et 124px.

Utilisez-la pour les marges, les paddings, la largeur, la hauteur, les tailles d'icônes, la largeur des bordures — tout ce qui est spatial. Fixez aussi un petit ensemble de valeurs d'opacité (par ex. .05 .1 .2 .4 .6 .8) pour les états désactivés, les superpositions et les teintes au survol, plutôt que d'ajuster au jugé un curseur à chaque fois. Même logique que les autres échelles : décidez une fois, réutilisez partout.

Échelle typographique

12  14  16  18  20  24  30  36  48  60  72

Pas une échelle modulaire construite à partir d'un rapport (4:5, 2:3, nombre d'or). Ceux-ci produisent des valeurs en pixels fractionnaires qui s'arrondissent de manière incohérente selon les navigateurs et sont trop peu denses pour la densité d'interface — les valeurs choisies à la main, pour leur ressenti, l'emportent à la place.

Unités : px ou rem uniquement. Jamais em. em est relatif à la taille de police courante, donc un .875em dans un parent 1.25em donne 17,5px — une valeur qui n'est pas dans votre échelle. L'échelle cesse silencieusement d'exister.

Poids de police

Deux poids suffisent :

• 400 ou 500 — corps de texte et la plupart du texte d'interface
• 600 ou 700 — tout ce qui est mis en évidence

Rien en dessous de 400 dans une interface. Pour atténuer, utilisez une couleur plus claire ou une taille plus petite — jamais un poids plus léger.

Couleur

Vous avez besoin de bien plus de couleurs qu'un générateur de palette à cinq échantillons ne vous en donne.

• Gris : 8 à 10 nuances. Presque toute une interface est grise — texte, fonds, panneaux, bordures, contrôles de formulaire. Trois ou quatre nuances, ça s'épuise toujours. Commencez par un gris très foncé, pas un vrai noir (le vrai noir a l'air peu naturel).
• Primaire : 5 à 10 nuances, une ou peut-être deux primaires.
• Accents : 5 à 10 nuances chacun — rouge destructeur, jaune d'avertissement, vert positif, plus tout ce dont le produit a besoin pour se distinguer (séries de graphiques, événements de calendrier, étiquettes). Dix couleurs × 5 à 10 nuances est normal pour une interface complexe.

Nommez-les 100 (le plus clair) → 900 (le plus foncé), base 500.

Construisez l'échelle dans cet ordre : choisissez d'abord 500 (pour une primaire/un accent, ce doit être une nuance qui fonctionne comme fond de bouton). Trouvez ensuite les extrêmes — 900 est généralement votre couleur de texte, 100 une teinte de fond ; un composant d'alerte utilise les deux, donc concevez-en un et lisez les deux valeurs dessus. Remplissez ensuite 700 et 300 comme le compromis parfait entre leurs voisins, puis 800 600 400 200 de la même manière.

Écrivez les couleurs en HSL, pas en hex. hsl(220, 95%, 34%) et hsl(220, 65%, 61%) sont visiblement liées ; #03369E et #507DD7 ne le sont pas.

Ne générez jamais de nuances à l'exécution avec lighten() / darken(). C'est comme cela qu'on se retrouve avec 35 nuances de bleu légèrement différentes.

Ombres — cinq élévations

0 1px 3px  hsla(0,0%,0%,.2)   /* à peine surélevé — boutons */
0 4px 6px  hsla(0,0%,0%,.2)   /* menus déroulants */
0 5px 15px hsla(0,0%,0%,.2)
0 10px 24px hsla(0,0%,0%,.2)
0 15px 35px hsla(0,0%,0%,.2)  /* fenêtres modales */

Choisissez en vous demandant où se situe-t-il sur l'axe z ?, pas quelle ombre est jolie ?. Plus proche de l'utilisateur = plus d'attention. Réduire l'ombre d'un bouton au :active donne l'impression qu'il est enfoncé ; agrandir l'ombre d'un élément de liste lorsqu'il est saisi pour le glisser-déposer fait l'inverse — cela se lit comme "maintenant au-dessus de ses frères" et sert aussi d'affordance de glissement.

Ces cinq ombres sont la valeur par défaut et conviennent partout. references/techniques.md donne une version en deux parties affinée de la même échelle — parallèle, mais pas de valeurs identiques (son étape supérieure est plus lourde). Utilisez-la lorsque les ombres sont importantes dans la conception ; utilisez celles-ci lorsqu'elles ne le sont pas. Ne mélangez pas les deux dans un même projet.

Hauteur de ligne et longueur de ligne

La hauteur de ligne est inversement proportionnelle à la taille de la police, et proportionnelle à la largeur de la ligne :

• petit texte / colonnes larges → 1.5 à 2
• grands titres → 1 est suffisant

Longueur de ligne : 45 à 75 caractères, c'est-à-dire max-width: 20em–35em. Cela s'applique au paragraphe même lorsque le conteneur autour est plus large — des largeurs mélangées dans une zone de contenu semblent plus soignées, pas moins.

(em est correct ici — la mesure doit s'adapter au texte qu'elle entoure. La règle "jamais em" est limitée à l'échelle typographique, où em se cumule par imbrication. Ne "corrigez" pas cela.)

Rayon de bordure

Choisissez-en un et restez cohérent. Petit rayon = neutre. Grand rayon = ludique. Aucun = sérieux/formaliste. Mélanger des coins carrés et arrondis dans une même interface a toujours l'air moins bien.

---

La procédure

1. Commencez par une fonctionnalité, pas par une mise en page. Ne concevez pas "l'application" — vous ne pouvez pas décider entre une navigation en haut et une barre latérale avant de savoir ce que contient le produit. Concevez une fonctionnalité réelle (le formulaire de recherche, le composeur de message), et laissez l'enveloppe émerger.

2. Les détails viennent plus tard. Ignorez les polices, les ombres et les icônes au début. Travaillez d'abord en niveaux de gris — cela force la hiérarchie à venir de l'espacement, du contraste et de la taille plutôt que de la couleur. Ajoutez la couleur une fois que la mise en page fonctionne.

3. N'investissez pas trop dans la basse fidélité. Les croquis, les wireframes et les maquettes sont jetables — personne ne peut utiliser une image statique d'une application. Ils existent pour explorer des idées ; abandonnez-les une fois la décision prise et construisez la vraie chose.

4. Concevez la plus petite version utile, puis construisez-la. Travaillez en cycles courts conception→code. N'impliquez pas de fonctionnalités que vous n'êtes pas prêt à construire — une zone de commentaires avec une zone de pièces jointes que vous ne pouvez pas livrer bloque toute la fonctionnalité. Les "nice-to-have" sont conçus plus tard.

5. Choisissez par élimination. Lorsque vous choisissez une valeur dans une échelle : devinez celle que vous pensez être correcte, puis comparez-la avec le voisin de chaque côté. Deux seront évidemment fausses. Si une option extérieure gagne, refaites la comparaison avec celle-ci comme nouveau milieu.

6. Commencez avec trop d'espace blanc et retirez-en. Ajouter de l'espace jusqu'à ce que quelque chose cesse de paraître moche vous donne le minimum. Commencer généreusement et réduire vous donne la bonne quantité. Les interfaces denses (tableaux de bord) sont légitimes — mais comme une décision délibérée, pas une valeur par défaut.

7. Réduisez le canevas. Un petit composant conçu sur un plan de travail de 1400px a tendance à s'étaler, car l'espace est là pour être rempli. Commencez à ~400px et concevez d'abord la mise en page mobile, où les contraintes sont réelles — puis amenez-la sur un grand écran et détendez uniquement ce qui semblait vraiment à l'étroit. Vous changerez moins que vous ne le pensez.

---

Hiérarchie — la technique qui fait le plus de travail

Tout ce qui est à l'écran se trouve dans une pyramide : primaire, secondaire, tertiaire. Quand tout se fait concurrence, l'interface se lit comme du bruit. C'est ce qui donne l'impression qu'un design est "conçu" — pas le style.

La taille n'est pas tout. S'appuyer uniquement sur la taille de la police donne un contenu primaire trop grand et un contenu secondaire trop petit. Utilisez plutôt le poids et la couleur pour porter l'emphase, et gardez des tailles raisonnables.

Trois couleurs de texte, maximum :

• foncé — contenu primaire
• gris — contenu secondaire
• gris plus clair — contenu tertiaire (notes de bas de page, copyright)

Ces trois couleurs portent du texte de taille réelle du corps, donc elles nécessitent toutes un ratio de 4,5:1. "Gris plus clair" signifie la nuance la plus claire qui le respecte encore — environ le milieu d'une rampe de 9 niveaux, pas l'extrémité pâle. Les nuances pâles sont uniquement pour les états désactivés et les grands textes.

Mettez en valeur en atténuant. Lorsque l'élément important ne se démarque pas et qu'il n'y a plus rien à lui ajouter, adoucissez ce qui est en concurrence avec lui à la place. Estompez les éléments de navigation inactifs ; réduisez la couleur de fond de la barre latérale pour que le contenu principal soit en avant.

Actions : stylisez par hiérarchie, pas par sémantique.

• Primaire → plein, contraste élevé. Généralement un seul par page.
• Secondaire → contour, ou fond à faible contraste.
• Tertiaire → stylisé comme un lien.

Destructeur ≠ gros bouton rouge. Si "Supprimer" n'est pas l'action principale sur la page, donnez-lui un traitement tertiaire — puis faites-en un gros bouton primaire rouge à l'intérieur de la boîte de dialogue de confirmation, où il est vraiment l'action principale.

Les étiquettes sont un dernier recours. étiquette : valeur donne à chaque donnée un poids égal. La plupart des données s'identifient par leur format ($19.99, une adresse e-mail) ou par le contexte. Lorsqu'une étiquette est vraiment nécessaire, intégrez-la dans la valeur ("12 en stock", pas "En stock : 12"), ou ajoutez-la comme un contenu visiblement secondaire. Exception : sur les pages de type fiche technique où les utilisateurs recherchent l'étiquette, mettez plutôt l'étiquette en valeur.

Équilibrez le poids et le contraste. Les icônes pleines sont visuellement lourdes et vont dominer le texte à côté — adoucissez leur couleur pour compenser. Cela fonctionne aussi en sens inverse : lorsqu'une bordure de 1px est trop subtile dans une couleur douce mais trop dure une fois assombrie, gardez la couleur douce et passez à 2px. Ajoutez du poids pour corriger un faible contraste ; réduisez le contraste pour corriger un excès de poids.

Hiérarchie visuelle ≠ hiérarchie du document. Le balisage sémantique et le poids visuel sont des décisions distinctes. Les titres de section sont généralement des étiquettes, pas des titres — un h1 à 16px est bien, et parfois le titre doit être complètement caché visuellement parce que le contenu parle de lui-même.

---

Règles strictes

S'écarter de ces règles produit un échec spécifique et reconnaissable.

1. Jamais de texte gris sur un fond coloré. Le gris sur blanc fonctionne car il réduit le contraste ; le gris sur couleur a juste l'air sale. Le blanc à opacité réduite a l'air délavé et désactivé, et laisse apparaître les motifs à travers les glyphes. Choisissez à la main une couleur avec la teinte du fond, en ajustant la saturation et la luminosité.
2. Jamais em pour l'échelle typographique. px ou rem.
3. Ne générez jamais de nuances à l'exécution. Définissez-les à l'avance.
4. N'utilisez jamais une largeur en pourcentage pour quelque chose qui ne devrait pas évoluer. Les barres latérales ont des largeurs fixes ; la zone principale s'adapte. Les éléments ont une max-width et ne rétrécissent que lorsque l'écran est réellement plus petit — une carte de connexion ne devrait pas être plus large sur les écrans moyens que sur les grands.
5. Ne mettez jamais les choses à l'échelle proportionnellement entre les points de rupture. Les grands éléments doivent rétrécir plus vite que les petits. Un titre de 2,5em sur un corps mobile de 14px donne 35px — bien trop grand ; il veut être entre 20 et 24px là. De même, le padding d'un bouton doit devenir proportionnellement plus serré à mesure que le bouton rétrécit, et non pas évoluer avec sa taille de police.
6. Toujours plus d'espace autour d'un groupe qu'à l'intérieur. C'est la solution pour "quelle étiquette appartient à quel champ", les listes à puces serrées, et les titres qui semblent attachés au mauvais paragraphe. Un espacement ambigu est un bug fonctionnel, pas seulement un défaut esthétique.
7. N'utilisez jamais la couleur comme seul signal. Ajoutez une icône, une forme ou un indice textuel. Pour les graphiques, distinguez les séries par contraste (nuances claires→foncées d'une même couleur) plutôt que par teinte — les utilisateurs daltoniens lisent la luminosité de manière fiable, la teinte beaucoup moins.
8. Contrastes minimaux : 4,5:1 pour le texte normal. La tolérance de 3:1 s'applique uniquement au texte grand, que WCAG définit comme 24px en régulier ou 18,66px en gras — pas 18px. Supposez 4,5:1 sauf si le texte est vraiment aussi grand. Quand le blanc sur couleur échoue, inversez-le : texte coloré foncé sur une teinte colorée claire (voir references/systems.md). Séparément, 3:1 s'applique aussi au non-texte (WCAG 1.4.11) : si une bordure est la seule chose qui identifie un contrôle — un contour d'entrée, un bord de case à cocher — elle nécessite 3:1 par rapport à son fond. Un filet qui divise simplement le contenu, non. Ce sont deux tokens différents, pas un seul.
9. Ne mettez jamais une icône à une échelle très éloignée de sa taille prévue. Une icône de 16–24px à 48px a l'air épaisse et manque de détails. Mettez-la dans un cercle coloré à la place.

---

Références

assets/tokens.css — un ensemble de départ complet, vérifié pour le contraste, de tout ce qui précède en tant que propriétés personnalisées CSS : espacement, typographie, poids, épaisseur de bordure, une échelle d'opacité fixe, une rampe de gris froid à 9 nuances, une primaire à 9 nuances, trois trios d'accents, cinq élévations, une couche de rôles sémantiques (--surface, --text-primary, --action…) et un bloc de mode sombre qui ne remplace que ces rôles. Copiez-le et réajustez les teintes plutôt que de redériver les échelles à partir de ce texte. Référencez les rôles dans les composants, pas les rampes brutes — c'est ce qui fait fonctionner le mode sombre. Chaque paire texte/surface est vérifiée ≥4,5:1 dans les deux modes et chaque bordure fonctionnelle ≥3:1 ; les nuances délibérément sous le seuil (désactivé, séparateurs décoratifs, l'étape réservée aux grands textes) sont exemptées par critère et commentées en ligne.

Chargez ces fichiers lorsque le travail les nécessite :

• references/systems.md — construction d'une palette de zéro : choix de la couleur de base, maintien de la saturation aux extrémités claire et foncée, rotation de teinte, gris chauds/froids, et les deux solutions de secours pour atteindre les ratios de contraste sans couleur moche.
• references/diagnose.md — table symptôme → correction. Chargez-le d'abord lorsque la tâche consiste à améliorer une interface existante plutôt qu'à en construire une nouvelle.
• references/techniques.md — simulation de profondeur et de lumière, ombres en deux parties, alignement de ligne de base, espacement des lettres, sortie des formes de composants par défaut et gestion des images téléchargées par l'utilisateur.