ralvarez-ai/landing-page-designer

Concepteur de pages d'atterrissage (rounds de propositions)

La méthode pour proposer des pages d'atterrissage en rounds, sur quoi repose chaque décision, et les vérifications qu'une page doit passer avant que quiconque ne la voie. En amont de cette compétence : website-concept-architect (ce qu'est le site). En aval : ui-ux-architect (portage dans l'application).

0. La mission, et ce qu'elle n'est pas

• Dessinez, ne refactorez pas. La sortie est des propositions sous <proposals-dir>/<date>/<product>/. Ne touchez pas au code de l'application ; ne commitez ni ne poussez sauf si le propriétaire le dit.
• Une page est terminée uniquement lorsqu'elle passe la barre de vérification (section 8) et que ses affirmations sont tracées (section 2).
• Travaillez en rounds. Chaque round produit de nouvelles directions, conserve les anciennes comme bibliothèque d'idées, et se termine par une recommandation et la raison pour laquelle elle bat les autres.

1. La barre (ce que signifie « impressionnant »)

Jugez chaque capture d'écran par rapport à cette liste.

1. Cinq secondes. Un étranger peut dire ce que fait le produit, à qui il s'adresse et en quoi il diffère, rien qu'avec la première fenêtre.
2. Un dispositif. La page est mémorisée pour une chose spécifique et propre au produit, pas une couleur. Les bons dispositifs sont littéraux : le curseur dans le logo utilisé comme un vrai curseur ; un vrai nombre qui bouge ; un échange agent-serveur montré comme les deux appels qu'il est vraiment ; une notification arrivant sur un téléphone au moment où le texte le dit.
3. Concret, pas abstrait. Chaque affirmation pointe vers quelque chose dans le produit ou son code.
4. Des pixels réels valent mieux qu'une illustration. Une capture d'écran recadrée du produit en fonctionnement bat tout dessin.
5. Dites le compromis. Le texte indique ce qu'il fait, à qui il s'adresse, et la seule chose qu'il accepte en échange (auto-hébergé : vos mises à jour et sauvegardes ; un service partagé : une dépendance de plus ; livraison uniquement : la politique reste dans l'application).
6. Interdit : photos libres de droits, dégradés violets, grilles bento de cartes grises avec une icône chacune, « Approuvé par 10 000 équipes », témoignages inventés, métriques fictives.

2. Recherche d'abord : faits avec sources

Avant de dessiner, construisez un tableau de faits par produit : affirmation, valeur, fichier source. Lisez le code, pas le marketing.

• Où chercher : README.md, AGENTS.md/CLAUDE.md, docs de conception et ADR, CHANGELOG.md, validateurs et codes d'erreur, enregistrements d'outils/points d'accès, mappages wire/proto, constantes de worker/retry, le composant de marque, le fichier de jetons de thème, la vue d'atterrissage existante.
• Faits qui valent la peine d'être trouvés : noms exacts des outils et combien sont destructeurs ; codes d'erreur et messages ; constantes (tentatives de retry, base et plafond du backoff, intervalle de sondage, limites de confiance) ; champs de requête (comptez-les dans le mappage wire, pas dans la doc) ; routes ; commandes de démarrage rapide réelles.
• Vérifiez les comptes et les noms dans le code. Les docs dérivent : un « six champs » documenté peut être huit dans le code ; un README peut pointer vers un répertoire qui n'existe plus ; un exemple de héros peut utiliser une unité que le serveur rejette.
• Signalez, ne corrigez jamais en silence. Les incohérences (marque obsolète dans les captures, captures qui ne concordent pas, doc vs code) vont dans NOTES.md et, si pertinent, sur la page.
• Étiquetez les données illustratives sur la page (exemples d'entrées, identifiants, heures, texte de notification). Le lecteur doit distinguer le réel de l'exemple sans les notes.

3. Marque et famille

• Chaque produit conserve sa propre marque et son accent. Copiez le chemin réel de la marque depuis son composant et les jetons réels (arrière-plans, texte, atténué, accent, texte d'accent, couleurs sémantiques) depuis le fichier de jetons, les deux thèmes.
• Polices : uniquement celles du produit, copiées en woff2 dans fonts/. Inspectez-les avant de choisir une voix typographique :

  python -c "from fontTools.ttLib import TTFont; t=TTFont('inter-latin.woff2'); print([(a.axisTag,a.minValue,a.maxValue) for a in t['fvar'].axes])"
  

  Une police variable déclarée sur toute sa plage de poids peut fournir des chiffres filiformes pour un produit et un poids lourd cinétique pour un autre, sans nouvelles polices.
• Un kit de marque d'organisation est une famille, pas un modèle. Utilisez-le pour les petits détails partagés (une marque de renvoi, un crédit de pied de page en currentColor), jamais comme l'identité du produit.
• Couche famille : un fichier partagé avec des jetons d'espacement, de type et de mouvement, en-tête, boutons, renvoi, rail de section, contrôle de film, bouton de copie, pied de page et le kit de mouvement. Les produits remplacent la couleur, la voix typographique et la composition. Plusieurs pages doivent se lire comme des frères et sœurs avec des personnalités distinctes.

4. Direction artistique par produit

Décidez d'une personnalité avant la mise en page ; laissez-la guider le type, la grille, le poids des couleurs et le rythme. Exemples qui ont fonctionné :

Personnalité	Voix typographique	Composition et rythme
Calme, éditorial (finance)	Un énorme chiffre héros dans un poids léger avec des chiffres tabulaires ; mono pour les lignes de grand livre	Espaces blancs généreux, grille asymétrique, une bande nocturne, une capture réelle en pleine page
Fort, cinétique (fitness)	Poids noir, crénage négatif serré, chiffres surdimensionnés	Bande d'accent en pleine page avec un ticker, règles strictes, sections fortes et calmes en alternance
Technique, précis (identité)	Appels mono, grands chiffres mono	Grille de fond filaire, figures numérotées avec légendes, diagrammes annotés
Ters, rythmique (notifications)	Mots d'état mono géants	Une règle de temps comme motif récurrent, espace négatif, une section épinglée

• Évitez le squelette par défaut (sourcil, h1, accroche, deux boutons, liste de confiance, lueur) sauf si vous le modifiez intentionnellement. Un round où chaque produit partage un seul squelette a échoué.
• Rythmez une page longue comme un film : une section calme, une forte, un moment en pleine page, une bande sombre, un changement d'arrière-plan. Un espacement uniforme se lit comme cousu.
• Concevez à 390 px intentionnellement : propres recadrages de captures pour téléphones, diagrammes qui se recomposent (empilage, bus latéral) au lieu de rétrécir, contenu du film au-dessus de la ligne de flottaison.
• Vérification par planche contact : affichez les premières fenêtres de tous les produits côte à côte (les deux thèmes, 1440 et 390). Recherchez l'uniformité et les ruptures de famille.

5. Le film héros

Une séquence chorégraphiée par produit qui raconte le produit en 4 à 8 secondes et s'installe sur un état final statique.

• L'état final est le HTML brut. JS désactivé et mouvement réduit l'affichent immédiatement ; le film ne fait qu'animer vers lui (un reset() pour l'état de départ, des étapes [ms, fn(instant)], un end() de nettoyage).
• Joue une fois à la vue, ne boucle jamais ; se met en pause lorsque l'onglet est caché ; a un contrôle visible Pause/Replay (WCAG 2.2.2). La frappe dans un film est pilotée par la timeline du film, donc Pause la fige aussi.
• Racontez la vérité en séquence. Utilisez un comportement réel comme intrigue : requête → rejetée avec la vraie erreur → renvoyée → sauvegardée ; trois copies → une ; en file d'attente → sondage → envoyée. Ne simulez pas un point fort que les données ne soutiennent pas.
• Les mouvements d'éléments partagés (un total volant dans le personnage héros, des tables volant dans une seule base de données) font une scène au lieu d'une liste de révélations.
• Texte accessible : la couche visible tapée est aria-hidden ; la phrase complète se trouve dans une étendue .sr une fois.

6. Règles de mouvement

• Porte : contenu visible par défaut ; un script d'en-tête ajoute html.anim uniquement lorsque prefers-reduced-motion le permet ; chaque règle de masquage ou d'animation se trouve sous .anim.
• Opacité uniquement dans les révélations uniques (IntersectionObserver, se termine à 1). Les effets liés au défilement (animation-timeline: view()/scroll(), grattage collant) animent transform, clip-path ou stroke uniquement : un état de texte à moitié transparent échoue au contraste dans axe.
• Autorisé : animations CSS pilotées par le défilement avec repli statique, Transitions de vue pour le changement de thème (effacement circulaire depuis le bouton), ressorts linear() CSS, animation de poids variable, comptages qui écrivent le texte final lorsque le mouvement est désactivé.
• Le contenu à déplacement automatique (tickers, lecture automatique) nécessite une commande de pause et se met en pause au survol/focus.
• Mesurez le décalage de mise en page ; réservez de l'espace pour les compteurs et le texte tapé.

7. Captures

• À partir du produit en fonctionnement uniquement, jamais d'une maquette. Initialisez les données de démonstration de manière déterministe pour que les nombres concordent entre les captures (ou dites sur la page qu'ils ne le font pas).
• Recadrez avec intention (un panneau par point), les deux thèmes, 2x, plus des recadrages séparés pour téléphone.
• Recadrez la marque obsolète et signalez-la. Dites dans les légendes lorsque le langage de l'interface utilisateur diffère de celui de la page.
• Implémentez comme une paire <img> clair/sombre avec height:auto, un alt significatif, et des marqueurs positionnés dans l'espace de coordonnées de la capture (mesurez-les ; les marqueurs dérivent).
• Si la construction est bloquée (packages privés, jeton manquant), dites-le, étiquetez les données dessinées comme illustratives, et listez exactement le déblocage.

8. Exigences strictes et barre de vérification

Chaque page :

• HTML autonome, CSS et SVG en ligne, pas de CDN, uniquement les polices du produit ; sous 200 Ko (hors captures).
• Clair et sombre via data-theme avec un bouton (préférence stockée, valeur par défaut du système).
• Repères, un h1, ordre des titres sans lacunes, lien d'évitement, focus-visible, cibles de 44 px, repli forced-colors.

Vérifications (toutes doivent réussir avant de montrer à quiconque) :

1. verify.js : axe-core (wcag2a/2aa/21aa/22aa + meilleures pratiques) à 390x844 et 1440x800 × clair/sombre × mouvement/réduit = 8 exécutions, zéro violation. En mode mouvement, faites défiler toute la page d'abord pour que les révélations se déclenchent. Aussi : pas de défilement horizontal ; images bloquées toujours lisibles ; JS désactivé toujours lisible.
2. Vérification du parseur HTML pour le texte avalé : un <token> brut ou <no-reply@…> dans le texte devient une balise et axe ne vous le dira pas. Échappez avec <.
3. Test de fumée par page : cliquez sur chaque contrôle à 1440 et 390, échouez sur pageerror, exécutez axe à nouveau dans les états finaux interactifs (boîtes de dialogue ouvertes, après application).
4. Captures d'écran : film stabilisé et mouvement réduit, les deux thèmes, les deux largeurs. Regardez-les et itérez au moins deux fois en tant que directeur artistique sévère.
5. Dites ce qui n'est pas couvert : lecteur d'écran, Safari/Firefox, vrais appareils, test utilisateur de l'affirmation des cinq secondes.

9. Pièges (chacun a coûté du temps une fois)

• Spécificité CSS : une règle de changement de thème pour les images doit surpasser les règles des composants (img.sl, pas .crop img).
• Mesurer un élément caché donne 0 (lentille, zoom) : affichez, puis mesurez.
• Les étapes inactives atténuées par opacité échouent au contraste : mettez l'accent sur la bordure/l'arrière-plan à la place.
• role="list" nécessite des enfants listitem ; les titres de section ne doivent pas passer de h1 à h3.
• Les arrière-plans avec lueur/mesh nécessitent une pleine page, un masque, et body{overflow-x:clip}.
• Un <code> insécable dans une cellule de grille provoque un défilement horizontal à 390 ; un pre défilable échoue scrollable-region-focusable (donnez-lui tabindex="0", role="region" et une étiquette unique, ou utilisez pre-wrap).
• Les noms de classe génériques entrent en collision entre CSS partagé et produit (.tl, .copy) : espacez les classes de famille.
• cqw se résout par rapport à un conteneur ancêtre, jamais l'élément lui-même.
• Un aria-label qui diffère du texte visible brise label-in-name ; mettez le contexte supplémentaire dans une étendue .sr.
• Une chaîne de modèle Python manquant son préfixe f fuit {label} dans le nom accessible : grep la sortie.
• Les images loading="lazy" sont absentes des captures d'écran en pleine page ; ce n'est pas un défaut.
• Les pages assemblées par extraction ne se mettent pas à jour lorsqu'une source change tant que l'assembleur n'est pas réexécuté.

10. Processus

1. Lisez le brief/le transfert, le code du produit et les docs ; construisez le tableau de faits et les drapeaux (section 2).
2. Inventoriez la marque : chemin de marque, jetons, polices (axes), captures existantes et leurs problèmes.
3. Round de directions : 3 petites directions différentes par produit, chacune construite autour d'un dispositif. Conservez-les comme bibliothèque d'idées.
4. Retour du propriétaire → combinez les meilleures idées en une page longue (rail de section, FAQ, démarrage rapide réel avec bouton de copie, un bloc « ce que vous acceptez » pondéré).
5. Augmentez le plafond : une couche familiale partagée d'abord, puis une page dirigée artistiquement par produit avec un film héros. Les produits indépendants peuvent être construits en parallèle (un agent par produit, couche familiale en lecture seule, suggestions signalées et appliquées une fois, puis toutes les pages reconstruites et revérifiées).
6. Revue collective : planches contact, corrections de cohérence dans la couche familiale, revérification complète.
7. Livrez : par produit un NOTES.md (concept, réel vs échantillon, drapeaux, tableau de vérification) ; un HANDOFF.md pour la session suivante (objectif, décisions, drapeaux, faiblesses, prochaines idées) ; des prévisualisations autonomes uniquement visuelles avec polices et captures intégrées ; un court résumé avec une recommandation par produit et pourquoi elle gagne.

11. Fichiers et outils

<proposals-dir>/<date>/
  HANDOFF.md                  brief pour la session suivante
  <product>/direction-N.html  pages ; NOTES.md ; fonts/ ; shots/
  _tools/verify.js            axe x8, débordement, images bloquées, JS désactivé
  _tools/family.py            coque partagée, jetons, kit de mouvement (film, comptage, type, onView)
  _tools/build_<product>.py   un générateur par produit
  _tools/settled.js           capture d'écran après stabilisation du film
  _tools/standalone.py        copie uniquement visuelle avec polices et captures intégrées
  _tools/smoke_<product>.js   tests de fumée d'interaction

Les générateurs portent des chemins codés en dur de la session qui les a créés ; corrigez sys.path et les chemins de sortie avant de les exécuter. verify.js attend [email protected] installé dans un dossier frère verify/node_modules.

12. Liste de contrôle avant de montrer une page

• La première fenêtre réussit le test des cinq secondes ; le dispositif unique y est visible.
• Chaque nombre et nom tracé vers un fichier ; données d'échantillon étiquetées sur la page ; drapeaux dans NOTES.md.
• Le compromis énoncé clairement et avec un poids visuel.
• Le film héros se stabilise ; l'état final est le HTML par défaut ; Pause/Replay fonctionne ; le mouvement réduit et JS désactivé se lisent bien.
• Les effets liés au défilement utilisent uniquement transform/clip/stroke ; les révélations sont uniques.
• 390 px conçu (propres recadrages, diagrammes recomposés), pas seulement empilé.
• verify.js TOUT PROPRE (8 exécutions), vérification du parseur propre, test de fumée propre, sous 200 Ko.
• J'ai regardé les captures d'écran, les deux thèmes, les deux largeurs, et j'ai changé quelque chose à cause de ce que j'ai vu.