Clean UI

Que fait Clean UI ?

Interface minimaliste, moderne, avec thème clair et sombre, qui tient à l'écran, avec les données en premier et un aspect de produit fait par des humains, pas par l'IA. Les règles ci-dessous proviennent de demandes de réglages réelles. Chacune a déjà irrité l'utilisateur lorsqu'elle a été enfreinte : traitez-la comme une exigence, pas comme une suggestion.

Fichiers de la skill

Chemins relatifs au dossier de cette skill.

Fichier	Quand l'utiliser
references/informacao.md	Pour tout nouvel écran ou redesign, avant la mise en page. Comment choisir quoi afficher, l'ordre de priorité et la position de chaque information (inventaire, questions de l'utilisateur, niveaux, filtre, carte des positions, plan écrit).
references/padroes-aprovados.md	Blocs approuvés par l'utilisateur ("c'est bien mieux") : carte de décision, graphique de mesure de décision avec ligne de limite, carte de situation avec solde au fil du temps, liste de l'utilisateur lui-même, support saisonnier, en-tête du téléphone, ordre par priorité, ultrawide. Utilisez comme point de départ pour le contenu, pas comme un squelette fixe.
references/armadilhas.md	Erreurs techniques qui ont déjà coûté des reprises (Tailwind v4, cn sans merge, spécificité de [&>*]:, next-themes, serveur avec CSS ancien, tester des états que la base locale n'a pas). Lisez avant d'écrire le code.
references/migracao.md	Redessiner l'application entière (plusieurs écrans) : écran de référence approuvé d'abord, base faite par vous (cadre, pièces de page, tokens dans le body, thème sauvegardé), fronts parallèles avec brief commun, intégration (commandes pour le kit, supprimer l'ancien code seulement à la fin, redémarrer, tout vérifier).
references/exemplos.md	Cas réels de mauvais et de bon. Lisez lors de la création d'un nouvel écran ou lorsque vous doutez de la qualité de quelque chose.
references/dashboards.md	Pour tout écran avec des nombres, des graphiques ou des cartes. Ce qui sépare l'amateur du professionnel, les principes (NN/g, Stephen Few, IBM Carbon), 7 compositions (choisissez celle qui sert le plan d'information), règles pour les écrans larges et ultrawide, couleur et finition des graphiques.
references/paletas.md	Palettes prêtes et validées (Cobalt, Indigo, Cyan, Coral) avec gris, accent, échelle ordonnée et couleurs de séries pour les deux thèmes. Choisissez par ici, jamais de couleurs isolées.
assets/tokens.css	Projet nouveau ou sans identité : thème clair et sombre (suit le système, avec changement manuel), police, focus, graphiques et toucher déjà configurés (Tailwind v4). Vient avec la palette Cobalt comme point de départ : remplacez par le bloc complet de la palette choisie (fin de paletas.md). Inclut la variante tall, positif/négatif/alerte et la main.
references/exemples-dashboards/	Les 7 références de l'utilisateur de tableau de bord moderne. Ouvrez-les toutes avant de dessiner un tableau de bord.
references/anatomia-dashboard.md	Les références traduites en mesures : carte, titre, indicateur, chips, nombres en haut du graphique, graphiques, parties d'un tout, jauge, tableau, téléphone, et ce qu'il ne faut pas copier.
assets/dashboard.tsx	Kit de tableau de bord mesuré dans les références : DashCard, Kpi, IconCircle, DeltaChip, StatusChip, TrendDot, CountBadge, Tabs, SeriesStat, StatColumns, Dashed, KeyValue, StackedBar, LegendGrid, Gauge, classes TH/TR de tableau, TooltipCard, PillMark, props chart pour Recharts, ListaAlta (la liste dans une carte verticale, avec pages par hauteur), Divergentes (ce qui a ajouté et ce qui a retiré), Quadro100 (sur chaque 100), Colunas (colonnes flottantes ; cascade et entonnoir ont été rejetés comme difficiles), useFitRows (combien de lignes tiennent) et useFitHeight (hauteur d'un graphique selon ce qui reste de la fenêtre ; mesure à nouveau lorsque la carte du dessus grandit).
assets/painel.tsx	Aides de carte : useMapColumns (largeur de la colonne de la carte) et FillMap (carte du monde qui remplit).
assets/ui.tsx	Composants de base prêts (Card, Section, IconBox, Chip, Pill, Button, BottomActions, ListRow, ListCard, StatCard, DateBlock, FillEmpty, InfoTip, NavLoading, Spinner, ThemeToggle, FitScreen). Réutilisez ou adaptez plutôt que d'inventer. Si le projet a déjà des équivalents, utilisez ceux du projet.
scripts/lint-ui.mjs	node <skill>/scripts/lint-ui.mjs src : parcourt le code modifié (hover qui bouge, points de suspension, bordures colorées, largeur étroite, polices interdites, couleur fixe qui casse un des thèmes, "—", " · ", minuscule, "Étiquette : valeur").
scripts/check-ui.mjs	node <skill>/scripts/check-ui.mjs http://localhost:3000/route --out=screenshots : prend des captures en 320 et 390 px (mobile) et dans la zone utile du navigateur en 1366×650, 1536×730 et 1920×950 (ordinateurs portables et moniteur) et 2560×960, 2752×1100 (21:9 avec zoom 125% de Windows) et 3440×1300 (ultrawide 21:9), dans les thèmes sombre et clair, et mesure le débordement horizontal et vertical (carte dépassant du bord inférieur du premier écran ou plus haute que l'écran), listes similaires répétées, graphique étiré et ligne de liste trop large, "…", cartes voisines avec des hauteurs différentes (également à l'intérieur d'une enveloppe sans fond), carte avec un espace vide à l'intérieur ou contenu dispersé, grille incomplète, icône sans conteneur, hover qui bouge, défilement interne, contenu étroit, police, cliquable sans main, bordures de cartes presque alignées entre les lignes, bulle du "i" hors de l'écran (ouvre chacune), barre de défilement sur le téléphone, ligne de tableau trop large (toute ligne répétée), texte compressé, ligne de liste avec titre ou description qui casse sur le téléphone et page vide ou d'erreur (attend le chargement ; si les données ne sont pas venues, la vérification ne vaut pas). Chaque résultat vient avec la taille et le thème. Nécessite Playwright dans le projet ; --user/--pass pour les pages avec mot de passe.

Les scripts sont des guides : vérifiez chaque résultat et, surtout, ouvrez les captures et regardez.

1. Processus (ce qui cause le plus de reprises)

1. Faites seulement ce qui a été demandé. Ne supprimez, ne remplacez ou ne "simplifiez" jamais des éléments existants sans demande explicite. Si la proposition exige de retirer quelque chose, demandez d'abord. En cas de doute, conservez.
2. Respectez le point d'arrêt demandé. Ajustement demandé sur mobile : le web ne change pas (utilisez sm:/md: pour préserver le web, et vice-versa).
3. Montrez avant de publier, en regardant toutes les tailles. Avant de dire que c'est bon, ouvrez la capture de chaque taille de la vérification (y compris 1366, 1536 et 2752, où le tableau casse et la carte dépasse), pas seulement 390 et 1920. Travail d'agent délégué aussi : vérifiez par vous-même. Exécutez localement, prenez une capture sur le mobile (390 px, et vérifiez 320 px) et sur le web (1366×650, 1536×730 et 1920×950, la zone utile réelle du navigateur), dans les deux thèmes, regardez vraiment chaque capture et ne faites de commit/push/deploy qu'avec une approbation explicite.
4. Nouvel écran ou redesign : d'abord les informations, ensuite la mise en page. Suivez references/informacao.md (et voyez les blocs de references/padroes-aprovados.md et les erreurs de references/armadilhas.md) : inventaire de ce que le produit sait (y compris tout ce que l'ancien écran montrait), questions de l'utilisateur par ordre d'urgence, niveaux de priorité, filtre de chaque information, carte des positions et le plan écrit. La composition découle de ce plan. Choisissez vous-même la composition et la palette (celle de la marque, si le projet en a une ; sinon celle de paletas.md qui correspond au sujet). Ne montez pas plusieurs versions ou vues de l'écran pour que l'utilisateur choisisse. Construisez-en une, la meilleure, et dites en quelques lignes pourquoi chaque chose est à sa place. Ne partez jamais du squelette d'un projet précédent et ne répétez pas "4 indicateurs + grille de cartes + listes" par défaut.
5. Détail rejeté deux fois = options côte à côte. Seulement lorsque l'utilisateur a déjà rejeté le même détail (position d'une puce, police) deux fois, montrez 2 ou 3 variations de ce détail en capture. Jamais pour l'écran entier.
6. Après avoir supprimé ou recréé des fichiers, redémarrez le serveur de développement (ou sauvegardez le CSS à nouveau) avant la vérification : Tailwind peut continuer à servir l'ancien CSS, sans les nouvelles classes.
7. Revoyez avec la liste de contrôle (section 10) avant chaque capture. S'il n'y a pas de symétrie, ce n'est pas prêt.

2. Typographie

• Interdites (aspect IA) : Inter, Roboto, Arial, Helvetica, system-ui comme police de marque, Geist, Poppins, Montserrat, Space Grotesk, Open Sans, Lato.
• Bonnes et peu utilisées par l'IA : Plus Jakarta Sans (préférée et déjà approuvée), Manrope, Onest, Figtree, Hanken Grotesk, Schibsted Grotesk, Instrument Sans, Albert Sans, Familjen Grotesk. Pour les titres en vedette, Bricolage Grotesque. Une seule famille par application.
• Nombres avec font-variant-numeric: tabular-nums (tabular-nums). Pas de police mono avec zéro barré ou pointillé.
• Hiérarchie par poids et taille modérés. Petite étiquette en haut (12 px, couleur atténuée) et valeur en dessous (16 px, semi-gras). Valeurs côte à côte avec la même taille de police. Pas de texte géant coloré.
• Tout texte visible commence par une majuscule, y compris les abréviations seules ("Lun", "Mar"). Au milieu d'une phrase, écrivez normal : "Vs mardi précédent", pas "Vs Mar précédent". Titres en casse de phrase, jamais en MAJUSCULES.

3. Couleur et thème

• Toujours deux thèmes, clair et sombre. Toute application naît avec les deux : suit le thème du système (prefers-color-scheme) et a un bouton pour changer (ThemeToggle dans assets/ui.tsx), avec le choix sauvegardé. Les e-mails et les aperçus répondent également à prefers-color-scheme. Aucun écran ne peut exister dans un seul thème.
• Couleurs toujours par token (var(--card), bg-card, text-muted-foreground). Pas de #000, #fff, bg-black, text-white ou hex isolé dans un composant, graphique ou SVG : cela casse l'autre thème.
• Sombre : fond très sombre (proche du noir), carte un cran au-dessus, bordure discrète, texte presque blanc. Clair : fond gris très clair, carte blanche, bordure légère, texte presque noir. Les deux avec le même soin et vérifiés en capture.
• La palette n'est pas fixe, mais elle n'est pas non plus isolée. Il n'existe pas de "noir + orange" standard : utilisez une palette entière de references/paletas.md (gris, accent, échelle et séries qui vont ensemble et ont déjà été validées pour le contraste et le daltonisme), choisie par le sujet et montrée rendue. Pas de couleurs isolées (le bleu d'un endroit, le jaune d'un autre, le rouge d'un autre). Un projet avec une marque suit la sienne (par exemple, MegaLab a choisi l'orange) ; une nouvelle couleur seulement avec un contraste d'au moins 3:1 par rapport à la carte dans les deux thèmes et distinguable pour les daltoniens (si l'agent a le guide dataviz, utilisez son validateur).
• Base neutre, couleur avec un but. Les gris constituent ~90% de l'écran. Une couleur d'accent par application (version par thème). Les données ordonnées (magnitude, niveau, plage) utilisent l'échelle d'une seule couleur (--seq-1..4), jamais d'arc-en-ciel de gris, bleu, jaune et rouge. Les séries sans ordre utilisent --cat-1..3 dans un ordre fixe. Le rouge/jaune d'alerte uniquement pour les vrais statuts, avec icône et étiquette. Le vert n'est jamais une couleur de marque, mais peut apparaître dans les données : puce de variation "s'est amélioré", bon statut et la série catégorique 3 des palettes validées. Pas de violet aléatoire, pas de marron.
• Le nombre n'est jamais peint. Les valeurs et les étiquettes restent dans la couleur du texte ; la couleur de la donnée va dans une petite marque à côté (point, barre fine, sceau neutre avec petite barre colorée).
• Variation pour le meilleur et pour le pire (comme dans les références de l'utilisateur) : puce verte douce et puce rouge douce, toujours avec une flèche pour ceux qui ne distinguent pas les couleurs (DeltaChip). Égal : puce grise.
• Les états similaires (par exemple : J'ai raté, Difficile, Bon, Facile) ont besoin de couleurs clairement différentes les unes des autres.
• Pas de bordures ou d'anneaux colorés pour mettre en évidence les cartes. Mise en évidence uniquement avec un fond doux de la couleur (bg-primary/10).
• Texte toujours lisible dans les deux thèmes, y compris les légendes et les infobulles des graphiques après clic.

4. Mise en page et symétrie

• Pleine largeur sur le web. Pas de contenu étroit centré (max-w-* + mx-auto sur la page). Utilisez une grille pour occuper l'écran.
• L'écran large gagne des colonnes, pas d'étirement. À partir de 1920 px et en ultrawide 21:9 (2560 et 3440 px), augmentez le nombre de colonnes avec 3xl: (1920 px) et 4xl: (2560 px), définis dans tokens.css ; jamais min-[1920px]: (dans Tailwind v4, il perd face à lg:), ouvrez les panneaux qui étaient auparavant cachés (détail à côté, tableau à côté du graphique) et limitez la proportion : graphique temporel jusqu'à ~4:1, barres et cartes jusqu'à ~2,5:1, ligne de liste jusqu'à ~720 px. Voir references/dashboards.md section 4.
• Mobile d'abord. Espacement latéral confortable (16 px), rien de serré, carrousel avec espace horizontal, premier élément avec espace en haut.
• Tient dans la hauteur de l'écran. Le contenu s'adapte à la fenêtre dans les deux directions, pas seulement à la largeur. Aucune carte, graphique, image ou carte de taille fixe ne dépasse du bord inférieur du premier écran ni n'est plus haut que la fenêtre (seules les listes continuent en dessous, en faisant défiler la page) : les cartes, graphiques et grandes images ont la hauteur limitée par la fenêtre (max-h-[calc(100dvh-<en-tête>)], h-[min(…,60dvh)], SVG avec preserveAspectRatio="xMidYMid meet" à l'intérieur d'un conteneur de hauteur définie). Ne dimensionnez jamais un visuel large uniquement par la largeur (w-full h-auto, aspect-[2/1]) : sur un moniteur large ou un ordinateur portable, il déborde vers le bas. Le premier écran (en-tête, indicateurs et le bloc principal) tient entièrement en 390×844, 1366×650, 1536×730 et 1920×950 (zone utile du navigateur, barres déjà déduites ; l'écran entier ne sert pas de mesure). Utilisez FitScreen de assets/ui.tsx.
• Écran toujours rempli. Le dernier bloc s'étire jusqu'au bout (flex-1). Pas de moitié d'écran vide : utilisez du contenu réel ou un état vide visuel (icône dans un conteneur + 1 ligne).
• La symétrie est obligatoire :
  • cartes côte à côte avec la même hauteur (items-stretch, h-full), et le contenu interne (graphique, tableau) grandit ensemble et occupe toute la hauteur ;
  • même nombre de lignes de texte à gauche et à droite ;
  • carte étirée par la grille n'a pas d'espace vide à l'intérieur : lignes de liste avec hauteur fixe et le bloc (titre + lignes) centré verticalement, jamais justify-around/justify-between dispersant les lignes ; colonnes comparables (A x B) avec la même hauteur de ligne, pour que les lignes s'alignent (voir references/armadilhas.md, "Carte qui s'étire") ;
  • lignes de la grille complètes (pas 3 + 1 restant) ;
  • dans la même colonne, éléments et puces avec la même largeur ;
  • colonnes de tableau et de grille avec la même hauteur minimale et alignées par le haut (vertical-align: top), ou lignes correspondantes avec la même hauteur (h-8 etc.).

5. Données et contenu

• Données d'abord, toujours. Chaque écran commence par l'inventaire de ce que le produit sait, puis les questions que l'utilisateur se pose, puis la meilleure façon d'y répondre visuellement. Ne commencez jamais par des graphiques génériques (courbes, barres, secteurs) sans savoir quelle question ils répondent.
• Une carte par sujet. Si des sujets différents partagent le même espace, le résultat cesse d'être un tableau de bord et devient un fourre-tout. Chaque carte répond à une seule question. Le titre de la carte est une phrase nominale courte, sans verbe et sans "Graphique de" ou "Analyse de".
• Toute donnée numérique a une unité ou un contexte. "1 234" n'est pas une information ; "1 234 commandes ce mois-ci" oui.
• Rien de redondant. Pas d'étiquette "Total" sous un nombre qui est déjà le total. Pas de légende si une seule série et la couleur est évidente. Pas de titre répété dans la carte et dans le graphique.
• Le texte est concis, informatif. Pas de remplissage, pas de paragraphe explicatif qui répète ce que le chiffre montre déjà. Utilisez des listes, des puces, des mots-clés.
• Les dates sont relatives quand c'est récent ("Aujourd'hui", "Hier", "Cette semaine"), absolues quand c'est lointain ("15 jan 2024").
• Les états vides sont informatifs. "Aucune commande ce mois-ci" avec une icône pertinente, pas un spinner ou une page blanche.
• Les listes et les tableaux ne sont jamais juste des listes et des tableaux. Chaque ligne montre la donnée la plus importante en premier (colonne de nombre, indicateur de statut), et ce qui est secondaire vient après avec un style atténué.
• Ordre par priorité, jamais alphabétique ou par date par défaut. Ce qui est urgent, ce qui a changé, ce qui est important vient en premier.

6. Composants (graphiques, tableaux, listes, cartes)

• Graphiques :
  • Un seul type de graphique par carte. Pas de courbe + barre dans la même zone sans un motif clair (les deux mesurent la même chose sous des angles différents).
  • Pas de secteurs (pie, donut) avec plus de 5 parts. Au-dessus, utilisez des barres horizontales ordonnées.
  • Courbes : lignes fines (1,5-2 px), pas de points si plus de 12 points de données, légende en haut à droite (petites boîtes, pas de texte coloré). L'axe X commence à zéro ou à la première date, jamais coupé. L'axe Y commence à zéro pour les données absolues, mais peut être ajusté pour les tendances (toujours avec une indication visuelle comme "//" sur l'axe).
  • Barres : espacement entre les barres = 0,3 x largeur de la barre. Barres verticales pour les catégories avec peu d'éléments (<12), horizontales pour les longues listes. Couleur de la barre = accent principal, sauf si une catégorie se distingue (utilisez une couleur de série).
  • Tableau : lignes alternées (zèbre) douces, en-tête avec fond plus foncé (pas de couleur d'accent). Au-dessus de 20 lignes, pagination ou défilement virtuel. La première colonne est un lien ou un identifiant important. Les nombres sont alignés à droite. Utilisez tabular-nums.
  • Carte : titre et indicateur principal en haut, contenu ci-dessous. Les cartes avec chiffres clés (KPI) ont un grand nombre (24 px, semi-gras), une petite étiquette (12 px, atténuée) et une variation (DeltaChip). Les cartes de liste ont des lignes avec hauteur fixe.
  • Indicateur (KPI) : nombre en haut, variation en dessous, étiquette en dessous de la variation. Le nombre ne change pas de couleur, seulement la variation.
• Composants de assets/ui.tsx : utilisez Card, Section, IconBox, Chip, Pill, Button, BottomActions, ListRow, ListCard, StatCard, DateBlock, FillEmpty, InfoTip, NavLoading, Spinner, ThemeToggle, FitScreen chaque fois que possible, en les adaptant si nécessaire. Ne réinventez pas.
• Composants de assets/dashboard.tsx : pour les tableaux de bord, utilisez DashCard, Kpi, IconCircle, DeltaChip, StatusChip, TrendDot, CountBadge, Tabs, SeriesStat, StatColumns, Dashed, KeyValue, StackedBar, LegendGrid, Gauge, TH/TR, TooltipCard, PillMark, ListaAlta, Divergentes, Quadro100, Colunas, useFitRows, useFitHeight. Chacun a une fonction spécifique décrite dans la table du début.
• Composants de assets/painel.tsx : pour les cartes, utilisez useMapColumns et FillMap.

7. Modifier une interface existante

• Ne supprimez jamais une information qu'une carte, une liste ou un tableau montrait déjà, sauf demande explicite. Des informations considérées comme sans importance par le développeur peuvent être cruciales pour l'utilisateur.
• Modifiez par ajout ou substitution mesurée. Ajoutez des colonnes, des filtres, des détails. Ne réduisez pas.
• Les changements d'interface sont accompagnés d'une justification courte : "J'ai déplacé le filtre ici parce que..." dans la réponse de l'agent, pas dans l'interface elle-même.
• Demandez de l'aide pour les modifications majeures de données. L'interface change parce que les données changent ? Demandez si l'API a changé, si une nouvelle source est disponible. Ne le devinez pas.

8. E-mails

• Mêmes règles que l'interface, mais avec un pied de page et un pré-en-tête. E-mail transactionnel (facture, reçu) avec les données importantes en haut ; e-mail marketing (newsletter) avec un sujet clair et un appel à l'action visible.
• Thème clair et sombre pour les e-mails aussi. Utilisez prefers-color-scheme avec des styles en ligne (le CSS en ligne est nécessaire pour les clients de messagerie).
• Largeur maximale de 600 px, centré. Pas de colonnes étroites. Un seul bloc de texte principal.
• Liens avec text-decoration: underline et une couleur de survol. Texte du lien = l'URL ou le nom de la destination.
• Images avec alt text et dimensions définies pour éviter le décalage de mise en page.
• Testez dans au moins 3 clients : Gmail (web), Apple Mail, Outlook.

9. Interface de chat

• Bulle de l'utilisateur : alignée à droite, fond de la couleur d'accent, texte blanc. Bulle de l'assistant : alignée à gauche, fond de la couleur de la carte, texte de la couleur du texte.
• Prénom ou icône à côté de la bulle de l'assistant. Initiales dans un cercle.
• Heure relative sous chaque bulle ("il y a 2 min", "15:32").
• Indicateur de saisie : trois points avec animation, de la couleur de la carte.
• Pas de barre de défilement automatique vers le bas si l'utilisateur a fait défiler vers le haut pour voir l'historique.
• Messages longs avec retour à la ligne et word-break: break-word.
• Entrée de message en bas, fixe, avec bouton d'envoi de la couleur d'accent. Pas de champ de texte avec hauteur infinie.

10. Liste de contrôle avant la capture

1. Les informations sont-elles ordonnées par priorité pour l'utilisateur ?
2. Chaque carte répond-elle à une seule question ?
3. Le titre est-il une phrase nominale courte ?
4. Pas d'unité manquante ?
5. Pas de redondance dans les titres, légendes, textes ?
6. Le texte est-il concis sans remplissage ?
7. Les cartes accompagnées ont-elles la même hauteur ?
8. Les lignes de tableau sont-elles alignées par le haut et avec la même hauteur ?
9. La grille est-elle complète (pas de trous) ?
10. Aucune carte ne dépasse du premier écran en hauteur ?
11. Le thème sombre est-il vérifié ?
12. Le thème clair est-il vérifié ?
13. La police est-elle l'une des approuvées (pas d'Inter, Roboto, etc.) ?
14. Toutes les couleurs sont-elles par token (pas de hex/texte en dur) ?
15. Les graphiques utilisent-ils tabular-nums ?
16. Les barres verticales sont-elles pour <12 éléments, horizontales pour >=12 ?
17. Les secteurs (pie/donut) ont-ils <=5 parts ?
18. Les courbes ont-elles des lignes fines sans points si >12 points ?
19. Les KPI ont-ils un grand nombre, une étiquette et une variation ?
20. Les listes ont-elles des lignes de hauteur fixe ?
21. Le texte commence-t-il par une majuscule (titres en casse de phrase) ?
22. Les liens sont-ils soulignés dans les e-mails ?
23. L'e-mail a-t-il un pré-en-tête et un pied de page ?
24. La largeur de l'e-mail est-elle de 600 px au maximum ?
25. L'interface de chat a-t-elle des bulles correctement alignées avec les couleurs ?
26. L'interface de chat a-t-elle l'heure et l'indicateur de saisie ?
27. Les thèmes fonctionnent-ils en mode sombre et clair (avec prefers-color-scheme) ?
28. La première colonne de tableau est-elle un lien ou un identifiant important ?
29. Les colonnes comparables ont-elles la même hauteur de ligne ?
30. Le dernier bloc s'étire-t-il jusqu'au bout de l'écran ?

---

Règle d'or : Si le design ressemble à ce que produirait un agent IA générique avec une invite rapide, ce n'est pas assez bien. Chaque élément doit exister pour une raison mesurable : répondre à une question de l'utilisateur, guider son regard vers la donnée importante, ou économiser de l'espace. Sinon, supprimez-le.