Apprenez à utiliser des design tokens et des règles de composants pour que les écrans React générés par l'IA respectent l'espacement, la typographie et le comportement des formulaires.
L'incohérence UI apparaît généralement dans de petits détails qui semblent décalés quand on navigue. Une page a un padding généreux, une autre semble resserrée. Les titres changent de taille, les boutons changent de forme et de couleur, et un même champ peut se comporter différemment selon l'écran.
La plupart du temps, la dérive vient de quelques basiques :
C'est courant quand les écrans sont générés à partir de prompts séparés. Chaque prompt est effectivement un nouveau départ, donc le modèle devine les décisions manquantes. Même « utiliser un style moderne » laisse des centaines de petits choix : gaps de 8px vs 12px, texte corps 14px vs 16px, quand afficher les erreurs, à quoi ressemble un bouton primaire.
Vous pouvez nettoyer manuellement deux ou trois pages, mais ça ne scale pas. Vous finissez à courir après des ajustements CSS ponctuels, copier des styles entre fichiers, et retoucher des formulaires. Les règles sont dans votre tête, pas dans le projet.
Imaginez générer un écran de connexion aujourd'hui et un écran de profil demain. Si l'un affiche les erreurs seulement au submit et l'autre au blur, les utilisateurs le remarquent. Si la hauteur du bouton primaire change entre les écrans, l'application donne l'impression d'être assemblée à la main.
La cohérence devient la norme quand chaque écran suit le même système partagé : des design tokens (espacement, typographie, couleur) plus un petit ensemble de règles de composants et de formulaires.
Les design tokens sont de simples valeurs nommées que vous réutilisez dans l'UI. Au lieu de demander un « padding confortable » sur chaque écran, vous utilisez un token comme space-4. Au lieu de « légèrement arrondi », vous utilisez radius-md. Le nom reste stable même si vous changez plus tard ce qu'il représente.
Les tokens sont l'ensemble des décisions que vous voulez voir partagées par tous les écrans. Ils éliminent le goût et les suppositions, ce qui cause exactement la dérive quand vous générez ou construisez de nouvelles pages.
Les tokens typiques couvrent l'espacement, la typographie, les couleurs, la forme et un petit nombre de niveaux d'élévation. Le gain est pratique : un en-tête utilise toujours la même taille, une carte utilise toujours le même padding, et un bouton primaire garde la même couleur et le même rayon.
Tokenisez les choses qui affectent le ressenti global du produit : l'échelle d'espacement, les tailles et hauteurs de ligne de police, les couleurs de base (texte, fond, primaire, danger, bordure) et un petit ensemble de rayons.
Gardez flexibles les choix guidés par le contenu, comme la longueur du texte, quelle icône utiliser, ou si une section a besoin de deux ou trois cartes.
Quand vous générez des écrans (y compris avec des outils comme Koder.ai), fournir un petit ensemble de tokens en amont réduit la part de devinettes et rend la sortie nettement plus cohérente.
Un jeu de tokens est juste un petit menu de valeurs autorisées. Plus il est petit, mieux c'est, car il laisse moins de place aux choix aléatoires, mais il doit couvrir les basiques qui rendent les écrans incohérents.
Commencez par l'espacement. Choisissez une seule échelle et utilisez-la partout pour le padding, les gaps et la mise en page. Un ensemble comme 4, 8, 12, 16, 24, 32 couvre la plupart des UI. Si un design demande 10px ou 18px, arrondissez au token le plus proche au lieu d'introduire de nouveaux nombres.
Puis définissez des valeurs typographiques par défaut pour que les titres et le texte corps cessent de dériver. Vous n'avez pas besoin d'un énorme système typographique. Vous avez besoin d'étapes claires et répétables.
Un ensemble compact et utilisable sans devenir verbeux :
L'accessibilité appartient aussi au système. Définissez un style d'outline au focus (couleur, épaisseur, offset) pour que les utilisateurs clavier aient des états de focus cohérents. Fixez une cible tactile minimale (par exemple 44x44) pour le mobile. Limitez les couleurs de texte à un petit ensemble fiable pour garder un contraste prévisible.
Si les boutons semblent parfois écrasés, c'est souvent parce qu'un écran a utilisé padding 10 et un autre 12. Avec des tokens, vous pouvez dire : « Buttons utilisent paddingY=8, paddingX=16, radius=12, token d'outline au focus, min height 44. » Une fois ces nombres fixés, le générateur arrête d'improviser.
Les tokens fixent les nombres. Les règles de composants fixent les habitudes.
Choisissez un petit ensemble de composants centraux et traitez-les comme les seuls blocs de construction pour les écrans. Gardez-les sobres et réutilisables : Button, Input, Select, Checkbox, Card. Vous pouvez ajouter TextArea et Modal, mais ils doivent suivre le même système (labels, espacement, états).
Ensuite, limitez les variantes et définissez quand elles sont autorisées. Par exemple : Button a primary, secondary et danger. Primary est pour l'action principale de l'écran (souvent une seule). Secondary est pour annuler ou les actions à faible priorité. Danger est seulement pour les actions destructrices comme supprimer. Si une variante ne se justifie pas, par défaut utilisez la secondary.
Les règles d'espacement empêchent la dérive subtile. Définissez des valeurs par défaut à l'intérieur des composants : padding du Button, hauteur de l'Input, gap label-champ, gap standard entre champs empilés. Ajoutez quelques règles de layout aussi : les Cards ont un padding interne fixe et un espacement header/body cohérent ; les Modals utilisent les mêmes pas de largeur et l'alignement du footer.
Enfin, rendez les états non négociables car c'est là que les UIs commencent souvent à paraître aléatoires :
Quand vous générez un écran riche en formulaires comme « Create project », ces règles empêchent des tailles de boutons mélangées, des positions d'étiquette changeantes, ou une « carte spéciale » unique à une page.
Même avec des visuels stables, beaucoup de plaintes « ça sonne bizarre » viennent du comportement des formulaires. Si chaque écran gère labels, erreurs et focus différemment, les utilisateurs le ressentent comme de l'incohérence.
Choisissez un seul pattern de formulaire et utilisez-le partout : label, marqueur optionnel/obligatoire, helper text, puis texte d'erreur. Gardez aussi la formulation cohérente (par exemple, labels en casse phrase, helper text court, et messages d'erreur qui commencent par un verbe).
Les règles qui évitent la plupart des dérives :
Verrouillez les dimensions et la mise en page pour que les écrans ne « respirent » pas différemment. Définissez une hauteur d'input unique, une hauteur de bouton unique et une largeur de champ par défaut. Sur desktop, alignez les champs sur une grille cohérente et empilez les labels au-dessus des inputs. Sur mobile, rendez les champs en pleine largeur et évitez les formulaires sur deux colonnes sauf si c'est vraiment nécessaire.
Un exemple simple : un écran « Create project » pourrait avoir Name, Region et Description. Même si Region est un select, traitez-le comme n'importe quel autre champ : même hauteur, même position d'étiquette, même ligne d'erreur. Si l'utilisateur soumet sans Name, le focus se déplace sur Name, l'erreur apparaît en dessous, et la mise en page reste stable.
Si vous générez des écrans dans Koder.ai, mettez ces règles de formulaire dans votre prompt une seule fois et réutilisez-les à travers les fonctionnalités pour que chaque nouveau formulaire se comporte de la même manière sans retouches répétées.
Traitez votre prompt comme un petit contrat UI. Gardez-le court, précis et réutilisable pour que chaque nouvel écran s'aligne sur le même espacement, typographie, composants et comportements.
Un pattern pratique est de coller une petite spécification UI en haut de votre requête, puis décrire l'écran en langage simple.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
Après la spécification, ajoutez quelques checks d'acceptation qui attrapent la dérive tôt :
Si vous utilisez un générateur basé sur chat, gardez cette spec stable entre les requêtes. La changer à chaque fois va à l'encontre de l'objectif.
Écrivez le contrat UI avant de générer quoi que ce soit : un petit jeu de tokens (espacement, typo, couleurs, rayons, ombres) plus un inventaire court de composants (Button, Input, Select, Card, Modal, Table, Toast). Si un token ou un composant manque, le modèle en inventera un et votre UI dérivera.
Créez ensuite un écran de référence qui exerce les règles. Une page riche en formulaires est un bon test car elle inclut en-têtes, helper text, erreurs de validation, boutons primaire et secondaire, et un toast de succès. Traitez cet écran comme la baseline.
Ensuite, construisez de nouveaux écrans en composant ce que vous avez déjà défini. Ne demandez pas un « nouveau style ». Demandez la même Card, la même échelle d'espacement, les mêmes pas typographiques et le même pattern de champs.
Un workflow simple :
Si un écran « Search users » finit avec un espacement plus serré que la référence, ne corrigez pas avec des marges manuelles. Mettez à jour les tokens d'espacement ou la règle de padding de Card une fois, puis régénérez.
Si vous travaillez dans Koder.ai, snapshots et rollback peuvent aider : verrouillez une baseline, expérimentez sereinement et revenez rapidement en arrière si un changement commence à introduire de la dérive.
La façon la plus rapide de perdre la cohérence est de traiter tokens et règles comme des suggestions. De petites exceptions se multiplient sur de nouveaux écrans.
Un piège fréquent est de changer l'échelle d'espacement en cours de projet. Les premiers écrans utilisent 8, 16, 24. Un nouvel écran introduit 10 et 18 « parce que ça rend mieux ». La dérive est alors autorisée, et les anciens écrans ne sont jamais mis à jour.
Une autre source de dérive est de laisser le générateur inventer de nouveaux styles de composants. Si vous ne dites pas « seules ces variantes de boutons existent », il peut créer un nouveau radius ou un padding d'input différent sur un écran.
Les états sont un autre oubli fréquent. Loading, empty et error states changent souvent l'espacement et le comportement. Si vous les ajoutez à la fin, vous obtenez généralement des patterns bâclés qui ne correspondent pas au reste.
Surveillez aussi le mauvais type de spécificité : « rendre moderne avec des ombres douces » est vague, tandis que des règles de comportement comme « les erreurs s'affichent sous le champ », « les boutons désactivés gardent les styles de focus », et « Enter soumet seulement sur le dernier champ » sont concrètes et répétables.
Si vous voulez un bloc de garde-fous léger à coller dans des prompts, gardez-le court :
Avant de merger un écran généré, faites un scan de deux minutes.
Commencez par l'espacement. Cherchez des valeurs aléatoires comme 13px ou des marges ponctuelles ajoutées « juste pour que ça rentre ». Si vous utilisez des tokens, chaque gap doit provenir de l'ensemble approuvé, y compris les gutters, le padding des cartes et l'espacement entre champs.
Puis vérifiez la typographie par rapport à votre échelle. Les titres doivent décroître de manière prévisible. Le texte corps ne doit pas changer de taille entre des sections similaires. La hauteur de ligne compte aussi, surtout sur des écrans denses comme les pages de paramètres.
Scannez ensuite les boutons. Variantes et tailles doivent suivre vos règles : primary pour l'action principale, secondary pour les actions moins importantes, danger uniquement lorsqu'il s'agit vraiment de supprimer. Hauteur du bouton, placement d'icône et style du libellé doivent correspondre.
Pour les formulaires, la cohérence tient surtout à la structure. Les labels restent au même endroit, les indicateurs requis suivent une règle, helper text et erreurs ne se concurrencent pas, et les erreurs apparaissent au même endroit.
Une checklist courte :
Enfin, faites un rapide test mobile. Réduisez la largeur et confirmez que le layout s'adapte sans inventer de nouvelles tailles de police ou d'espacement.
Imaginez un simple onboarding : trois écrans (Profile, Preferences, Confirm), plus une page Settings plus tard. Vous voulez que chaque écran semble venir du même designer, même s'ils ont été générés séparément.
Avant de générer quoi que ce soit, fournissez un petit jeu de tokens et quelques règles de composants :
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Générez ensuite « Profile » et « Preferences » séparément. Comme les deux écrans doivent utiliser Page, Card, Field et Button row tels que définis, ils arrivent avec les mêmes marges, l'espacement des labels et le positionnement des boutons. L'étape Confirm tient toujours, même si elle contient plus de texte en lecture seule.
Le comportement des formulaires est l'endroit où la dérive s'infiltre souvent, donc définissez-le une fois et réutilisez : submit désactivé tant que c'est invalide, erreurs inline seulement après blur ou submit, Enter soumet seulement à la dernière étape, et le bouton Back ne supprime jamais les valeurs déjà saisies.
Quand vous avez besoin d'un nouvel élément UI, ne laissez pas le modèle improviser. Ajoutez une seule règle, puis régénérez en pensant la réutilisation :
Transformez tokens et règles en une spécification réutilisable que vous utilisez réellement. Si elle est trop longue pour être collée, elle ne sera pas suivie.
Une spec pratique inclut généralement : votre table de tokens (espacement, typo, rayons, couleurs), un petit ensemble de règles de composants (boutons, inputs, cartes, titres), des règles de comportement des formulaires (timing de validation, erreurs, disabled/loading), des defaults de layout (padding page, max width, espacement de section), et une courte liste « ne jamais faire » (marges aléatoires, tailles de police ad hoc).
Faites ensuite une habitude : mettez à jour la spec d'abord, pas les pixels individuels.
Si vous utilisez Koder.ai (koder.ai), le planning mode est un bon endroit pour redire et confirmer la spec avant de générer l'UI. Quand vous voulez tester des alternatives, snapshots et rollback vous aident à explorer sans perdre une baseline stable.
Parce que chaque requête pour un écran est une nouvelle instance. Si vous ne fournissez pas un système partagé, le générateur comble les détails manquants en devinant : espacement, tailles de police, padding des boutons, ombres et comportement des formulaires. De petites différences s'accumulent donc entre les pages.
Les design tokens sont des valeurs nommées et réutilisables pour des éléments comme l'espacement, les tailles de police, les couleurs et les rayons de bordure.
Au lieu de demander un “padding confortable”, vous utilisez quelque chose comme space-md. Le nom reste stable et chaque écran réutilise les mêmes décisions pour éviter la dérive de l'interface.
Commencez petit et couvrez uniquement ce qui provoque une dérive visible :
Placez un petit bloc de spécification UI en haut de chaque requête et traitez-le comme un contrat :
Décrivez ensuite l'écran. L'important est de garder cette spécification identique entre les écrans.
Les tokens définissent les nombres ; les règles de composants définissent les habitudes. Règles utiles :
Règle par défaut : si une variante n'est pas justifiable, revenir à la variante standard.
Choisissez un seul schéma et appliquez-le partout :
Cela évite la situation courante où un écran valide au blur et un autre seulement au submit, ce que les utilisateurs remarquent.
Définissez quelques règles d'état non négociables :
Si vous ne spécifiez pas les états, chaque écran a tendance à inventer ses propres patterns.
Ne laissez pas le générateur improviser le style. Ajoutez le composant en tant qu’extension documentée d’un pattern existant :
Si vous ne pouvez pas le décrire avec des tokens, c'est probablement trop personnalisé et cela provoquera de la dérive.
Créez un écran de référence qui met le système à l’épreuve (une page riche en formulaires est idéale), puis réutilisez la même spécification pour chaque nouvel écran.
Dans Koder.ai, utilisez planning mode pour redéclarer et confirmer la spécification avant de générer, et servez-vous des snapshots et rollback pour conserver une baseline stable pendant les expérimentations.
Faites un scan rapide avant d'accepter l'écran généré :
Si quelque chose cloche, mettez à jour la spécification/tokens et régénérez — ne corrigez pas avec des marges ad hoc.
Si vous avez besoin d’une nouvelle valeur, arrondissez-la au token le plus proche au lieu d’inventer 10px ou 18px.