Communitygithub.com

Protonicwave/web-ui-craft

Concevez et construisez des interfaces web qui semblent délibérées plutôt que générées. À utiliser lors de la création ou du restylage d'un site web, d'une page d'atterrissage, d'un écran d'application web, d'un tableau de bord, d'un composant, d'une page HTML ou CSS, ou d'une interface React, Vue ou Svelte, et chaque fois que l'utilisateur demande quelque chose de beau, soigné, distinctif, moderne ou qui n'a pas l'air d'être généré par IA. Impose un brief de conception écrit dérivé du sujet, applique des valeurs par défaut fondées sur des preuves pour la typographie, la couleur, l'espacement, la profondeur, le mouvement, la navigation, les états, les performances et l'accessibilité, et se termine par une passe de critique qui supprime les signes révélateurs génériques de l'IA.

Qu'est-ce que web-ui-craft ?

Cette compétence permet de concevoir et de construire des interfaces web intentionnelles, en évitant les aspects génériques et générés par IA. Elle force une réflexion approfondie via un brief de conception écrit, dérivé du sujet, du public et de la tâche principale. Elle s'applique à toute interface HTML, CSS, React, Vue ou Svelte, et fournit des valeurs par défaut fondées sur des preuves pour la typographie, la couleur, l'espacement, la profondeur, le mouvement, la navigation, les états, les performances et l'accessibilité. Le processus se termine par une passe de critique rigoureuse qui utilise des outils automatisés (vérificateur de 'slop', budgets de performance Lighthouse) et des comparaisons avec des sites de référence pour garantir que l'interface est à la fois distincte et bien construite.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Protonicwave/claude-skill-design/tree/HEAD/skills/web-ui-craft

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Artisanat d'interface web

Une interface utilisateur générique n'est pas un style. C'est ce qui remplit chaque décision que personne n'a prise : le modèle, le template ou le framework fournit sa réponse la plus courante, et le résultat pourrait appartenir à n'importe quel produit. Les plus beaux sites (Linear, Vercel, Stripe, Family, les gagnants des Awwwards) ne laissent presque rien par défaut. Ils calculent un petit système, s'engagent sur une idée, et maintiennent les détails fonctionnels à des normes mesurables.

Le travail consiste donc à prendre des décisions, à les écrire, et à tracer chacune d'elles jusqu'au sujet, à l'utilisateur ou à la physique de la perception. Suivez les cinq étapes ci-dessous dans l'ordre. Adaptez-les à la tâche : un seul bouton mérite une phrase de brief et une critique rapide, une page d'atterrissage reçoit le traitement complet.

1. Lire le sujet

Avant tout choix visuel, établissez :

  • Sujet : ce que le produit, l'organisation ou le contenu est réellement, et le monde auquel il appartient (son industrie, ses matériaux, son vocabulaire, ses artefacts).
  • Audience : qui arrive, ce qu'ils savent déjà, sur quel appareil ils sont probablement.
  • Tâche principale : la seule chose que la page ou l'écran doit accomplir. Tout le reste lui est subordonné.
  • Contraintes existantes : actifs de marque, un système de design existant, des tokens, une bibliothèque de composants ou un framework dans le dépôt. Si des tokens existent, utilisez-les et appliquez cette compétence à l'intérieur de ceux-ci. N'imposez pas une nouvelle identité à un produit établi à moins qu'on vous le demande.

Si l'utilisateur a donné peu d'informations, déduisez-les du sujet et énoncez vos hypothèses dans le brief plutôt que de poser une liste de questions.

2. Rédiger le brief de conception

Rédigez un bref compact dans votre réponse avant d'écrire du code. C'est la conception, il doit donc être suffisamment spécifique pour que quelqu'un d'autre puisse construire la même chose à partir de lui.

Direction :     une esthétique nommée et pourquoi elle convient à ce sujet (une ou deux lignes)
Signature :    l'idée unique pour laquelle cette page est retenue, la pièce maîtresse qui la porte, et
               comment cette pièce sera réalisée (actifs fournis, image générée, ou construite en code)
Palette :      neutre (teinté vers ...), un accent (rôle), couleurs sémantiques ; valeurs OKLCH
Typographie :  famille et rôle pour chacun (affichage, texte, mono si nécessaire) et ce que chacun
               partage avec le sujet ; comment la police d'affichage agit dans la composition ;
               échelle de taille ; taille du corps
Mise en page : deux ou trois options pour le premier écran, chacune un concept d'une ligne et un
               wireframe ASCII ; celle choisie et pourquoi ; grille, mesure, densité, rythme des sections
Profondeur :   comment les surfaces se séparent (paliers de tons, filets, ombres), d'où vient la
               lumière et sur quoi elle tombe
Mouvement :    le niveau (produit ou marque), le moment signature et son élément principal,
               ce qui bouge d'autre et pendant combien de temps, et ce qui ne bouge délibérément pas
Imagerie :     photographie, illustration, 3D, UI produit ou typographique uniquement ; direction
               artistique en une ligne
Copie :        le titre et l'action principale, rédigés pour ce public ; le nom de l'action,
               conservé du bouton à la confirmation
Budget :       script compressé pour la page entière et la part que la couche spectacle peut
               prendre (365 Kio par défaut ; 75 Kio pour une page sans spectacle)

Règles pour le brief :

  • Dérivez, ne décorez pas. Chaque ligne répond à « pourquoi ceci, pour ce sujet ? ». Une palette tirée des matériaux du produit, une police de caractères de son langage vernaculaire, un héros qui s'ouvre sur la chose la plus caractéristique de son monde.
  • Une signature, tout le reste est calme. Stripe a sa vague dégradée, Apple ses photos de produit défilées au scroll, Family ses plateaux volants. Dépensez l'audace une fois. La retenue qui l'entoure est ce qui la fait lire.
  • La retenue est une direction valide. Un système calme, monochrome, mené par la typographie avec un seul accent est aussi délibéré qu'un héros WebGL, et c'est généralement le bon choix pour les outils et la documentation.
  • Calme n'est pas nu. La retenue limite le nombre d'idées qu'une page a, pas la richesse de chacune. La signature doit récompenser un long regard : une illustration dessinée pour ce sujet, des données réelles présentées avec soin, de la texture, une typographie à une échelle d'affichage réelle. Les sujets liés à l'alimentation, la culture, la consommation et la marque ont généralement besoin d'images ou d'illustrations pour apporter de la chaleur, donc une page typographique uniquement pour l'un d'eux a besoin d'une raison énoncée.
  • La pièce maîtresse est l'endroit où va l'effort. Les sites acclamés enfreignent de nombreuses règles et ont toujours l'air coûteux parce qu'une pièce est réalisée à un très haut niveau : un écran de produit avec des données crédibles, un objet éclairé, une illustration personnalisée. Choisissez-la et construisez-la avec references/artefacts.md. Une boîte arrondie avec des barres grises à l'intérieur n'est pas une photo de produit.
  • La typographie fait partie de la composition, pas un support pour elle. À une taille d'affichage, le réglage est la conception : l'échelle par rapport au plus petit texte de la page, le poids, la largeur, la casse, où les lignes se coupent, ce contre quoi le titre se trouve. Le titre de 64 px de Linear sur un texte d'interface de 12 px est une grande partie de son effet.
  • Comparez les mises en page avant d'en choisir une. Esquissez deux ou trois premiers écrans vraiment différents (pas une seule mise en page avec l'image déplacée) et choisissez en fonction de la tâche principale du sujet. La première mise en page qui vient à l'esprit est généralement le modèle.
  • Affirmation, preuve, action. La plupart des pages ont besoin d'une déclaration claire, d'un élément de preuve réel (vue produit, chiffre en direct, client, démo) et d'une action principale. La structure suit le contenu, pas un modèle.
  • Un nom par action. Le bouton qui dit « Publier » produit une confirmation qui dit « Publié », pas « Enregistré ». Le vocabulaire de l'interface est la façon dont les gens s'y retrouvent.

Lisez references/exemplars.md lors du choix d'une direction ou d'une signature, references/visual-system.md lors du réglage de la palette, de la typographie, de la mise en page et de la profondeur, et la section sur le mouvement de references/interaction.md lors de la rédaction de la ligne Mouvement.

3. Mettre le brief au défi

Avant de construire, attaquez-le :

  • Test de substitution. Le nom d'un concurrent pourrait-il remplacer celui-ci sans que personne ne s'en aperçoive ? Si oui, le brief n'a pas encore pris ses décisions.
  • Test par choix. Pour chaque ligne, demandez-vous si elle pourrait appartenir à n'importe quel produit. Si c'est le cas, elle doit être une valeur par défaut délibérée et bien réglée à partir de la feuille de construction ci-dessous, ou elle doit changer.
  • Test de convergence. Esquissez en quelques lignes le brief que vous écririez pour un sujet voisin : un autre outil dans la même catégorie, un autre créateur dans le même métier. Chaque ligne qui est identique est une valeur par défaut, pas une décision. Changez-la, et dites dans le brief ce qui a changé et pourquoi. Une ligne ne peut rester que lorsqu'elle découle d'un fait que les deux sujets partagent (les deux produits sont du matériel, les deux publics lisent du code) ; nommez le fait.
  • Vérification des signes révélateurs. Comparez avec references/slop-tells.md, y compris les groupes d'aspect général. Ne remplacez pas une valeur par défaut par la suivante la plus courante (Inter pour Space Grotesk, violet pour sarcelle). Remplacez-la par un choix qui a une raison.

Révisez le brief, puis construisez.

4. Construire

  • Les tokens d'abord. Écrivez la palette, l'échelle typographique, l'espacement, les rayons, les ombres et le mouvement en tant que propriétés personnalisées CSS (ou le système de tokens du projet) avant tout composant. Les composants utilisent uniquement les noms de tokens, jamais de valeurs brutes comme bg-indigo-500 ou #6366f1.
  • La structure ensuite. HTML sémantique, vrais liens pour la navigation, titres dans l'ordre, puis le style.
  • Appliquez la feuille de construction ci-dessous et les détails dans references/visual-system.md et references/interaction.md.
  • Concevez chaque état. Survol, actif, focus-visible, désactivé, chargement, vide, erreur, succès, contenu long et contenu court. L'interface générée est la plus faible ici, et les correctifs sont les moins coûteux ici.
  • Gardez le spectacle peu coûteux et optionnel. Les effets lourds (WebGL, vidéo, flou important) vivent dans une couche isolée dans le budget du brief, commencent après le premier affichage, ont un repli statique, et se trouvent derrière prefers-reduced-motion: no-preference.

5. Critiquer et couper

Traitez la première construction comme un brouillon.

  1. Exécutez le vérificateur statique, en utilisant le répertoire de la compétence lui-même pour le chemin du script. Il nécessite Python 3.12 ou version ultérieure et aucun paquet. Pointez-le sur l'ensemble du code source front-end, pas seulement sur les fichiers que vous avez modifiés : les règles de focus et de mouvement réduit recherchent un style global n'importe où dans l'analyse, donc une analyse partielle signale de faux défauts.

    python <dossier-compétence>/scripts/check_slop.py <dossier-source-front-end>
    

    Corrigez chaque défaut (le code de sortie 1 signifie qu'il en reste au moins un). Pour chaque signe révélateur, modifiez-le ou dites dans votre rapport pourquoi il reste. Le vérificateur lit uniquement le texte source, donc un résultat propre est nécessaire, mais pas suffisant.

  2. Rendez la page et regardez-la à 1440 px et 375 px de large, dans les deux schémas de couleurs si elle en a deux. Utilisez un outil de navigateur si la session en a un. Sinon, la plupart des machines ont Chrome ou Edge sans tête ; écrivez les captures d'écran et le profil du navigateur dans un dossier temporaire, puis lisez les images :

    chrome --headless=new --hide-scrollbars --user-data-dir=<temp>/profile --window-size=1440,2600 --virtual-time-budget=4000 --screenshot=<temp>/desktop.png <fichier ou URL http>
    

    La capture d'écran est une seule fenêtre de la taille donnée, pas la page entière, alors faites en sorte que la fenêtre soit suffisamment haute pour contenir le contenu que vous devez voir. Chrome sans tête ne fera pas une fenêtre plus étroite qu'environ 500 px, donc une capture d'écran de 390 px est silencieusement recadrée à partir d'une mise en page plus large. Un élément qui se joue tout seul est capturé à un point aléatoire de sa boucle : ajoutez --force-prefers-reduced-motion pour l'image finale, et prenez une capture d'écran supplémentaire sans elle pour voir une image au milieu de la boucle. Pour la vérification sur téléphone, faites une capture d'écran d'une petite page wrapper qui contient le site dans une <iframe> de 375 px de large. Les éléments révélés au défilement peuvent ne pas apparaître dans les captures d'écran sans tête ; vérifiez dans le code source que leur état de départ caché est appliqué par script (voir references/interaction.md). Avec un véritable outil de navigateur, parcourez également chaque flux avec la touche de tabulation.

  3. Mesurez la page plutôt que de l'estimer. Servez-la via HTTP (pour un dossier statique, python -m http.server dans ce dossier), exécutez Lighthouse dans son profil mobile par défaut, puis lisez le rapport avec le lecteur de budget :

    npx [email protected] <URL http> --output=json --output-path=<temp>/report.json --quiet --chrome-flags="--headless=new --user-data-dir=<temp>/lh-profile"
    python <dossier-compétence>/scripts/check_budgets.py <temp>/report.json --script-kib <le budget du brief>
    

    Il vérifie le LCP (2,5 s), le CLS (0,1), le temps de blocage total (200 ms, le substitut de laboratoire pour l'INP), le poids du script par rapport au brief, et liste chaque animation non composée par élément. Corrigez chaque violation (code de sortie 1). Le code de sortie 2 signifie qu'une valeur est non mesurée ou que le rapport est inutilisable : réexécutez, et si cela échoue encore, signalez la valeur comme non mesurée, jamais comme réussie. http.server ne compresse pas, donc le poids du script est élevé, ce qui est prudent. Définissez CHROME_PATH si Lighthouse ne trouve pas Chrome. Si Node ou le réseau n'est pas disponible, dites-le dans le rapport. Lighthouse ne mesure pas le taux de trames du moment signature : enregistrez une trace de performance avec un outil de navigateur si la session en a un, et sinon dites qu'il n'est pas mesuré.

  4. Demandez-vous si le premier écran donne à l'œil quelque chose qui vaut la peine d'être regardé, et exécutez la liste de contrôle de fidélité dans references/artefacts.md sur la pièce maîtresse. Une page qui est correcte mais oubliable a une signature timide : renforcez la signature plutôt que d'ajouter plus d'éléments.

  5. Comparez la page à une référence. Choisissez un site acclamé dans la direction choisie, un qu'un designer dans le domaine du sujet admirerait (references/exemplars.md en nomme quelques-uns), faites une capture d'écran de son premier écran à 1440 px avec la commande de l'élément 2, et regardez les deux images côte à côte. Comparez la fidélité de la pièce maîtresse, l'écart entre la plus grande typographie et le plus petit détail, la quantité de détails crédibles, et la lumière. Nommez le plus grand écart et comblez-le, ou dites dans le rapport pourquoi il reste. La référence définit la barre pour l'artisanat, pas l'apparence : ne prenez rien de sa surface. Si le site est inaccessible, dites-le dans le rapport.

  6. Parcourez la liste de contrôle dans references/interaction.md (états, focus, cibles, formulaires, performances).

  7. Réexécutez la vérification des signes révélateurs dans references/slop-tells.md sur la page construite, pas sur le brief. Elle couvre les signes structurels que le vérificateur ne peut pas voir, tels que le héros à badge centré, les trois cartes identiques et les groupes d'aspect général.

  8. Supprimez tout ce qui ne sert pas le sujet ou l'utilisateur : séparateurs décoratifs, étiquettes au-dessus d'un contenu explicite, badges, lueurs, icônes qui répètent leur texte, une deuxième couleur d'accent. Supprimer est généralement la plus grande amélioration disponible.

  9. Rapportez le brief, ce que la critique a changé, le plus grand écart par rapport à la référence, les valeurs mesurées par rapport à leurs budgets, et tout ce que vous n'avez pas pu vérifier (par exemple le contraste rendu sans navigateur).

Feuille de construction

Valeurs de départ bien sourcées. Elles protègent les bonnes décisions ; elles ne remplacent pas les décisions d'identité dans le brief.

DimensionValeur par défaut
Texte du corps16 à 20 px, hauteur de ligne d'environ 1,5, mesure de 45 à 90 caractères (visez environ 65)
TitresHauteur de ligne 1,0 à 1,2, crénage d'environ -0,02em à partir de 24 px, text-wrap: balance
Paragraphestext-wrap: pretty ; gras et italique jamais ensemble
Échelle typographiqueFluide via clamp(), rapport d'environ 1,2 sur les petits écrans à 1,25 sur les grands
Tout en majusculesRare, sous une ligne, espacement des lettres de 0,05em à 0,12em
CouleurOKLCH ; une échelle neutre teintée, un accent, trois ou quatre couleurs sémantiques, chacune avec des étapes basées sur le rôle
ContrasteWCAG 4,5:1 corps, 3:1 grands textes et éléments d'interface ; visez APCA Lc 75 ou plus sur le texte du corps
Mode sombreUne palette séparée : base gris foncé (environ oklch(0.18 0.01 h)), surfaces plus claires pour l'élévation, accent désaturé
DégradésInterpolez in oklch ; teintes adjacentes ; grain fin optionnel ; au plus un dégradé délibéré
EspacementBase 4 px : 4, 8, 12, 16, 24, 32, 48, 64, 96, 128 ; l'écart entre les groupes est au moins le double de l'écart à l'intérieur
ProfondeurPaliers de tons et bordures de filet d'abord ; ombres superposées, une source de lumière, teintées avec la teinte de surface
RayonsDeux ou trois valeurs ; rayon imbriqué = rayon extérieur moins le remplissage
IcônesUne famille, une grille, une épaisseur de trait...

Skills associés