Communitygithub.com

reviewing-page-design

Utilisez cette compétence pour QA, revoir ou vérifier une page web — après chaque jalon de construction ou avant de finaliser une page.

Qu'est-ce que reviewing-page-design ?

Cette compétence transforme une simple revue de design en une analyse rigoureuse et mesurée. Elle impose que chaque constat soit accompagné d'une valeur numérique ou d'un sélecteur, sans adjectif sans preuve, et que ce qui n'a pu être vérifié soit clairement énoncé. Le processus se déroule en passes ordonnées : structure, rythme, responsive (selon une matrice de largeurs de fenêtre), typographie/couleur, motion, contenu, accessibilité et performance. Des extraits de code JS sont fournis pour mesurer précisément les valeurs sur la page en direct, plutôt que de se fier à des captures d'écran. Le rapport final est un tableau classé par sévérité, avec localisation, valeur mesurée et correctif. Un 'contrôleur froid' externe est recommandé pour les jalons majeurs, avec un barème de 8/10 sur plusieurs critères. La compétence s'applique à tout éditeur de code ou agent IA capable d'exécuter des scripts et de générer des rapports structurés, comme Claude Code, Cursor, ou Codex.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/igal-commits/landing-page-skills/tree/HEAD/skills/reviewing-page-design

Demander à votre IA préférée

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

Documentation

Reviewing page design (Revue de conception de page)

Aperçu

Une revue de design qui se contente de dire « ça a l'air bien » ne vaut rien. Une revue utile nomme l'élément, la valeur mesurée et ce qu'elle devrait être.

Principe fondamental : chaque constat comporte un nombre ou un sélecteur. Pas d'adjectifs sans preuve, et ce que vous n'avez pas pu vérifier est dit à haute voix.

Ordre des passes

À exécuter dans cet ordre. Les passes ultérieures sont inutiles si une passe antérieure échoue.

  1. Structure : chaque section existe-t-elle, dans l'ordre prévu, avec le contenu lié
  2. Rythme : écarts de jonction de sections, alignement de la grille, hauteurs des cartes, système de sections
  3. Responsive : la matrice de fenêtres ci-dessous, mobile et desktop
  4. Typographie et couleur : contraste, hiérarchie, orphelines, débordement, largeurs de texte par rapport à la maquette
  5. Animation : voir animating-web-pages et choreographing-scroll-stories
  6. Affirmations et contenu : voir writing-claims-that-hold
  7. Accessibilité et performance : focus, texte alternatif, LCP, décalage de mise en page

La matrice de fenêtres

Testez les largeurs que la page doit supporter, pas une largeur représentative. Un ensemble qui a tenu le coup lors d'un lancement réel : desktop à 1024, 1280, 1440, 1920 et 2560, et téléphones à 320, 360, 390 et 430.

LargeurRechercher
1440longueurs de ligne supérieures à ~75 caractères, sections qui se centrent alors qu'elles ne le devraient pas
992grilles à trois colonnes qui devraient être à deux, éléments collants sans déplacement
768le bloc tablette que personne n'a écrit, donc les valeurs desktop s'appliquent à la moitié de la largeur
390médias en plein écran qui ne contiennent plus leur sujet, texte sombre sur une bande sombre, débordement horizontal
320le plus petit téléphone : titres coupés, boutons tronqués
2560images molles sur un écran Retina, contenu perdu au milieu d'un canevas large

L'échec mobile qui mérite d'être nommé : un hero en pleine hauteur dont le média n'occupe qu'environ 55 % de la section laisse le reste afficher l'arrière-plan de la section. Si l'arrière-plan de la section est sombre et que le texte est passé en thème clair, le texte et les boutons deviennent invisibles. Vérifiez les deux états de thème à 390.

Mesurez, ne plissez pas les yeux

Lisez les valeurs de la page en direct plutôt que de juger à partir d'une capture d'écran. C'est plus rapide, cela détecte ce que l'œil manque et cela fonctionne même lorsque le rendu n'est pas disponible.

// Rythme des sections : l'écart important est la SOMME à chaque jonction
[...document.querySelectorAll('section')].map(s => {
  const c = getComputedStyle(s);
  return { cls: s.className, h: Math.round(s.getBoundingClientRect().height),
           padT: c.paddingTop, padB: c.paddingBottom };
});

// Débordement, le bug invisible le plus courant
[...document.querySelectorAll('*')]
  .filter(e => e.scrollWidth > e.clientWidth + 1)
  .map(e => e.className);

// Débordement horizontal de la page
document.documentElement.scrollWidth > document.documentElement.clientWidth;

// Uniformité des cartes dans une grille
[...document.querySelectorAll('.card')].map(c => Math.round(c.getBoundingClientRect().height));

tools/page-measure.js dans ce dépôt regroupe ces vérifications et celles ci-dessous en un seul extrait.

Autres vérifications mesurées qui ont fait leurs preuves :

  • Système de sections : chaque titre de section de contenu a la même taille de police calculée ; chaque bord gauche est égal au bord du logo de navigation.
  • Plancher de taille de texte : aucun texte en dessous de 10 px.
  • Un seul h1. Les niveaux de titre descendent sans sauter.
  • Images : chaque image se décode ; le rapport de pixels effectif est inférieur ou égal à 1,0 à chaque position de défilement et à chaque rapport de pixels de l'appareil.
  • Contraste par scène : chaque nœud de texte dans une scène épinglée a un contraste d'au moins 3:1 (grand) ou 4,5:1 (corps) par rapport à son premier arrière-plan solide, dans l'état final de la scène.
  • Hero : échantillonnez les images pendant huit secondes. Échec sur une image en double, une vignette en dehors du rectangle du hero, un chevauchement, une vignette sous le texte, ou tout changement après la stabilisation de l'intro.
  • Sensation de défilement : entrée de roue réelle, voir choreographing-scroll-stories.
  • La console est propre. Les scripts démarrent, l'intro s'exécute, aucune erreur en attente.

Quand vous ne pouvez pas faire de capture d'écran

Les volets de navigateur sans tête et masqués mettent en pause le rendu, donc les captures d'écran reviennent vides alors que le DOM est parfaitement sain. Ce n'est pas une raison pour sauter la revue et ce n'est pas une raison pour demander à l'utilisateur de vérifier à votre place.

Vérifiez numériquement à la place : styles calculés, boîtes englobantes, scrollWidth, statut de récupération des ressources et type de contenu. Indiquez clairement dans votre rapport quels constats ont été mesurés et lesquels ont été observés.

Contenu et affirmations

Une revue de conception inclut ce que la page dit.

  • Chaque statistique est attribuée, et l'attribution est autorisée pour une utilisation marketing
  • Les logos des clients figurent sur la liste autorisée, pas seulement « les logos que nous avons »
  • Le texte alternatif décrit l'image, n'est pas le nom du fichier, et n'est pas vide sur les images significatives
  • Aucun texte de remplacement dans une liste CMS ; aucune carte vide derrière une animation
  • Aucun mot interdit ; aucun tiret cadratin si le style maison l'interdit

Plancher d'accessibilité

  • Anneau de mise au point visible sur chaque élément interactif (:focus-visible, pas outline: none)
  • Contraste du texte du corps d'au moins 4,5:1, texte large 3:1
  • Cibles interactives d'au moins 44x44 au toucher
  • Mouvement réduit respecté : la page est complète et statique
  • Sans script : tout est visible

Plancher de performance

  • L'image LCP est en chargement prioritaire (eager), le reste en différé (lazy)
  • L'image hero fait environ 2x sa largeur CSS, pas 4x
  • Aucun décalage de mise en page dû à des images sans dimensions ou sans wrapper aspect-ratio
  • La vidéo est un fichier 1x ou léger sur les téléphones, avec une affiche (poster)

Combien exécuter

Un jalon reçoit la suite complète. Une petite correction reçoit la seule vérification qui couvre le changement, une publication sur l'environnement de staging et un rapport. Exécuter la suite complète après chaque ajustement transforme une correction d'une ligne en une heure. Quand quelqu'un dit « QA complète », exécutez tout.

Après correction, publiez sur l'environnement de staging et effectuez la QA sur le staging, pas seulement sur la build locale. Ce qui est livré est ce qui doit être vérifié.

Vérifiez l'exécution, pas le journal

Avant de rapporter des chiffres, confirmez que l'exécution qui les a produits est terminée : le fichier d'état est d'aujourd'hui, le journal se termine proprement, la fenêtre est celle que vous vouliez. Un bloc de journal obsolète d'une exécution antérieure ressemble exactement à un bloc récent.

Le contrôleur froid

Votre propre QA partage vos angles morts. Pour un jalon, confiez à un nouveau relecteur qui n'a jamais vu le travail uniquement les artefacts : captures d'écran pleine page aux largeurs de la matrice, la fiche 390, la capture d'animation et le registre des affirmations. Barre : 8 sur 10 pour chacun des critères hiérarchie, rythme, animation, imagerie et texte. Trois tours au maximum, un nouveau relecteur à chaque tour. Un pilote de ce processus sur une vidéo terminée a obtenu un score global de 7 et a trouvé un accroche statique et un nom de marque tardif que tous nos propres contrôles automatisés avaient validés.

Format de rapport

Un tableau. Sévérité, emplacement, valeur mesurée, correctif. Classé du plus sévère au premier.

SévOùMesuréCorrectif
Élevée.hero à 390média à 500 px dans une section de 812 px ; zone de texte est #0c0c0cdéfinir l'arrière-plan de la section par thème
Moyennejonction proof / info120 + 120 = 240 px de blanc videresserrer à 80, ou placer le CTA à cet endroit

Terminez par ce que vous avez vérifié et n'avez pas pu critiquer, et une liste de ce que vous n'avez pas pu vérifier (par exemple : « je ne peux pas entendre l'audio », « le brouillon ne peut pas être prévisualisé sur le domaine de production »). Une revue sans ligne de propreté donne l'impression d'être inachevée plutôt que rigoureuse.

Drapeaux rouges

  • « Ça a l'air bien sur mobile » sans largeur nommée
  • Signaler une correction comme effectuée sans remesurer
  • Sauter une passe parce que la précédente était propre
  • Demander à l'utilisateur de vérifier quelque chose que vous pourriez mesurer
  • Rapporter des chiffres d'une exécution que vous n'avez pas confirmée terminée
  • Exécuter la suite complète pour une modification d'une ligne

Individual skills in this repo

This repo contains 5 individual skills — each has its own dedicated page.

Skills associés