ralvarez-ai/landing-page-designer

Landingpage-Designer (Vorschlagsrunden)

Die Methode zum Vorschlagen von Landingpages in Runden, worauf jede Entscheidung basiert und welche Prüfungen eine Seite bestehen muss, bevor sie jemand sieht. Vorgelagert zu dieser Fähigkeit: website-concept-architect (was die Seite ist). Nachgelagert: ui-ux-architect (Portierung in die App).

0. Die Aufgabe – und was sie nicht ist

• Zeichnen, nicht umgestalten. Ausgabe sind Vorschläge unter <proposals-dir>/<date>/<product>/. Nicht den Auslieferungscode der App anfassen; nicht committen oder pushen, es sei denn, der Eigentümer sagt es.
• Eine Seite ist fertig erst, wenn sie die Verifikationsleiste (Abschnitt 8) besteht und ihre Behauptungen nachvollziehbar sind (Abschnitt 2).
• Arbeiten Sie in Runden. Jede Runde produziert neue Richtungen, behält die alten als Ideenbibliothek und endet mit einer Empfehlung und der Begründung, warum sie die anderen übertrifft.

1. Die Messlatte (was „beeindruckend“ bedeutet)

Bewerten Sie jeden Screenshot anhand dieser Liste.

1. Fünf Sekunden. Ein Fremder kann allein aus dem ersten Viewport sagen, was das Produkt tut, für wen es ist und worin es sich unterscheidet.
2. Ein Gerät. Die Seite wird für eine einzige, produktspezifische Sache in Erinnerung behalten, nicht für eine Farbe. Gute Geräte sind wörtlich: der Cursor im Logo, der als echter Cursor verwendet wird; eine echte Zahl, die sich bewegt; ein Agent-Server-Austausch, der als die beiden Aufrufe dargestellt wird, die es wirklich sind; eine Push-Benachrichtigung, die auf dem Telefon ankommt, genau in dem Moment, in dem der Text es sagt.
3. Konkret, nicht abstrakt. Jede Behauptung verweist auf etwas im Produkt oder seinem Code.
4. Echte Pixel schlagen Illustrationen. Ein beschnittener Screenshot des laufenden Produkts schlägt jede Zeichnung davon.
5. Den Kompromiss nennen. Der Text gibt an, was das Produkt tut, für wen es ist und die eine Sache, die es im Gegenzug akzeptiert (selbst gehostet: Ihre Updates und Backups; ein gemeinsamer Dienst: eine weitere Abhängigkeit; reine Zustellung: die Richtlinie bleibt in der App).
6. Verboten: Stockfotografie, lila Verläufe, Bento-Gitter aus grauen Karten mit je einem Symbol, „Vertrauen von 10.000 Teams“, erfundene Erfahrungsberichte, gefälschte Metriken.

2. Erst recherchieren: Fakten mit Quellen

Erstellen Sie vor dem Zeichnen eine Faktentabelle pro Produkt: Behauptung, Wert, Quelldatei. Lesen Sie den Code, nicht das Marketing.

• Wo suchen: README.md, AGENTS.md/CLAUDE.md, Design-Dokumente und ADRs, CHANGELOG.md, Validatoren und Fehlercodes, Tool-/Endpunkt-Registrierungen, Draht-/Proto-Zuordnungen, Worker-/Retry-Konstanten, die Brand-Mark-Komponente, die Theme-Token-Datei, die vorhandene Landing-Ansicht.
• Wissenswerte Fakten: genaue Tool-Namen und wie viele davon destruktiv sind; Fehlercodes und -meldungen; Konstanten (Wiederholungsversuche, Backoff-Basis und -Obergrenze, Polling-Intervall, Vertrauensgrenzen); Anfragefelder (zählen Sie sie in der Drahtzuordnung, nicht im Dokument); Routen; echte Schnellstartbefehle.
• Anzahlen und Namen im Code überprüfen. Dokumentationen driften ab: Ein dokumentiertes „sechs Felder“ können im Code acht sein; eine README kann auf ein Verzeichnis verweisen, das nicht mehr existiert; ein Heldenbeispiel kann eine Einheit verwenden, die der Server ablehnt.
• Markieren, nie stillschweigend korrigieren. Inkonsistenzen (veraltetes Branding in Captures, widersprüchliche Captures, Dokumentation vs. Code) kommen in NOTES.md und, falls relevant, auf die Seite.
• Illustrative Daten auf der Seite kennzeichnen (Beispieleinträge, IDs, Zeiten, Benachrichtigungstext). Der Leser muss ohne die Notizen zwischen echt und Beispiel unterscheiden können.

3. Branding und Familie

• Jedes Produkt behält seine eigene Marke und Akzentfarbe. Kopieren Sie den echten Mark-Pfad aus seiner Komponente und die echten Token (Hintergründe, Text, dezent, Akzent, Akzent-Text, semantische Farben) aus der Token-Datei, beide Designs.
• Schriftarten: nur die des Produkts, kopiert als woff2 in fonts/. Untersuchen Sie sie, bevor Sie eine Schriftstimme wählen:

  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])"
  

  Eine variable Schriftart, die über ihren gesamten Gewichtsbereich deklariert ist, kann für ein Produkt hauchdünne Ziffern und für ein anderes kinetisches Schwergewicht liefern, ohne neue Schriftarten.
• Ein Organisations-Brand-Kit ist Familie, nicht Vorlage. Verwenden Sie es für kleine gemeinsame Details (eine Kicker-Marke, eine Fußzeile in currentColor), niemals als Identität des Produkts.
• Familienebene: eine gemeinsame Datei mit Abstands-, Schrift- und Bewegungs-Token, Kopfzeile, Buttons, Kicker, Abschnittsschiene, Filmsteuerung, Kopierbutton, Fußzeile und dem Bewegungs-Kit. Produkte überschreiben Farbe, Schriftstimme und Komposition. Mehrere Seiten sollten als Geschwister mit unterschiedlichen Persönlichkeiten lesbar sein.

4. Art Direction pro Produkt

Entscheiden Sie vor dem Layout eine Persönlichkeit; lassen Sie sie Schriftart, Raster, Farbgewicht und Tempo bestimmen. Beispiele, die funktioniert haben:

Persönlichkeit	Schriftstimme	Komposition und Tempo
Ruhig, redaktionell (Finanzen)	Eine riesige Heldenfigur in einer leichten Schriftstärke mit tabellarischen Ziffern; Mono für Hauptbuchzeilen	Großzügiger Weißraum, asymmetrisches Raster, ein Nachtbalken, ein randloser echter Screenshot
Laut, kinetisch (Fitness)	Schwarze Schriftstärke, enger negativer Laufweite, überdimensionale Ziffern	Randloser Akzentbalken mit einem Ticker, harte Linien, laute und leise Abschnitte im Wechsel
Technisch, exakt (Identität)	Mono-Auszeichnungen, große Mono-Ziffern	Haarfeines Raster, nummerierte Abbildungen mit Bildunterschriften, kommentierte Diagramme
Knapp, rhythmisch (Benachrichtigungen)	Riesige Mono-Statuswörter	Eine Zeitlinie als wiederkehrendes Motiv, negativer Raum, ein angehefteter Abschnitt

• Vermeiden Sie das Standard-Skelett (Augenbraue, h1, Einleitung, zwei Buttons, Vertrauensliste, Leuchten), es sei denn, Sie ändern es mit Absicht. Eine Runde, in der jedes Produkt ein Skelett teilt, ist gescheitert.
• Tempo einer langen Seite wie ein Film: ein leiser Abschnitt, ein lauter, ein randloser Moment, ein dunkler Balken, ein Hintergrundwechsel. Gleichmäßige Abstände lesen sich wie zusammengestückelt.
• Entwerfen Sie 390 px mit Absicht: eigene Zuschnitte von Captures für Telefone, Diagramme, die umfließen (Stapel, Seitenbus), anstatt zu schrumpfen, Film-Inhalt oberhalb der Falte.
• Kontaktbogen-Prüfung: Rendern Sie alle ersten Viewports der Produkte nebeneinander (beide Designs, 1440 und 390). Achten Sie auf Gleichheit und Familienbrüche.

5. Der Heldenfilm

Eine choreografierte Sequenz pro Produkt, die das Produkt in 4 bis 8 Sekunden zeigt und in einem statischen Endzustand verharrt.

• Der Endzustand ist das reine HTML. Bei deaktiviertem JS und reduzierter Bewegung wird es sofort angezeigt; der Film animiert nur darauf zu (ein reset() für den Startzustand, Schritte [ms, fn(instant)], end()-Bereinigung).
• Wird einmal beim Ansehen abgespielt, niemals wiederholt; pausiert, wenn der Tab versteckt ist; hat eine sichtbare Pause/Wiederholen-Steuerung (WCAG 2.2.2). Die Eingabe in einem Film wird durch die Filmzeitachse gesteuert, sodass Pause auch diese einfriert.
• Erzählen Sie die Wahrheit in der Reihenfolge. Verwenden Sie echtes Verhalten als Handlung: Anfrage → abgelehnt mit dem echten Fehler → erneut gesendet → gespeichert; drei Kopien → eine; in der Warteschlange → Polling → gesendet. Fälschen Sie keine Hervorhebung, die die Daten nicht unterstützen.
• Bewegungen mit gemeinsamem Element (eine Summe, die in die Heldenfigur fliegt, Tabellen, die in eine Datenbank fliegen) ergeben eine Szene anstelle einer Liste von Enthüllungen.
• Barrierefreier Text: Die sichtbare getippte Ebene ist aria-hidden; der vollständige Satz befindet sich einmal in einem .sr-Span.

6. Bewegungsregeln

• Tor: Inhalt standardmäßig sichtbar; ein Kopf-Skript fügt html.anim nur hinzu, wenn prefers-reduced-motion es erlaubt; jede Ausblend- oder Animationsregel steht unter .anim.
• Nur Deckkraft bei einmaligen Enthüllungen (IntersectionObserver, endet bei 1). Bewegungsgebundene Effekte (animation-timeline: view()/scroll(), Klebe-Scrubbing) animieren nur Transform, Clip-Pfad oder Strich: Ein halbtransparenter Textzustand besteht den Kontrasttest in axe nicht.
• Erlaubt: CSS-scrollgesteuerte Animationen mit statischem Fallback, View Transitions für den Themenwechsel (kreisförmiger Wipe vom Umschalter), CSS linear()-Federn, Variable-Weight-Animation, Count-ups, die den endgültigen Text schreiben, wenn Bewegung deaktiviert ist.
• Automatisch bewegte Inhalte (Ticker, Autoplay) benötigen eine Pause-Steuerung und pausieren bei Hover/Fokus.
• Layout-Verschiebung messen; Platz für Zähler und getippten Text reservieren.

7. Captures

• Nur vom laufenden Produkt, niemals ein Mockup davon. Seed-Testdaten deterministisch, sodass Zahlen über Captures hinweg übereinstimmen (oder auf der Seite sagen, dass sie es nicht tun).
• Mit Absicht zuschneiden (ein Panel pro Punkt), beide Designs, 2x, plus separate Telefon-Zuschnitte.
• Veraltetes Branding wegschneiden und markieren. In Bildunterschriften angeben, wenn die UI-Sprache von der der Seite abweicht.
• Als Hell/Dunkel <img>-Paar mit height:auto, einem aussagekräftigen alt und Markierungen, die im Koordinatenraum des Captures positioniert sind, implementieren (messen; Markierungen driften).
• Wenn der Build blockiert ist (private Pakete, fehlende Token), dies sagen, gezeichnete Daten als illustrativ kennzeichnen und die genaue Entsperrung auflisten.

8. Harte Anforderungen und Verifikationsleiste

Jede Seite:

• Eigenständiges HTML, Inline-CSS und SVG, kein CDN, nur die Schriftarten des Produkts; unter 200 KB ohne Captures.
• Hell und Dunkel über data-theme mit einem Umschalter (gespeicherte Einstellung, Systemstandard).
• Landmarken, ein h1, Überschriftenreihenfolge ohne Lücken, Skip-Link, focus-visible, 44 px Ziele, forced-colors Fallback.

Prüfungen (alle müssen bestehen, bevor sie jemandem gezeigt werden):

1. verify.js: axe-core (wcag2a/2aa/21aa/22aa + best-practice) bei 390x844 und 1440x800 × Hell/Dunkel × Bewegung/reduziert = 8 Läufe, null Verstöße. Im Bewegungsmodus zuerst die gesamte Seite scrollen, damit Enthüllungen feuern. Auch: kein horizontaler Scrollbalken; Bilder blockiert noch lesbar; JS aus noch lesbar.
2. HTML-Parser-Prüfung auf verschluckten Text: Ein rohes <token> oder <no-reply@…> im Text wird zu einem Tag, und axe wird es Ihnen nicht sagen. Escapen mit <.
3. Rauchtest pro Seite: Jedes Steuerelement bei 1440 und 390 anklicken, bei pageerror fehlschlagen, axe erneut in interaktiven Endzuständen ausführen (Dialoge offen, nach Anwenden).
4. Screenshots: Beruhigter Film und reduzierte Bewegung, beide Designs, beide Breiten. Ansehen und mindestens zweimal als strenger Art Director iterieren.
5. Sagen, was nicht abgedeckt ist: Screenreader, Safari/Firefox, echte Geräte, Benutzertests der Fünf-Sekunden-Behauptung.

9. Fallen (jede hat einmal Zeit gekostet)

• CSS-Spezifität: Eine Theme-Umschaltregel für Bilder muss Komponentenregeln überschreiben (img.sl, nicht .crop img).
• Messen eines versteckten Elements ergibt 0 (Linse, Zoom): erst anzeigen, dann messen.
• Mit Deckkraft abgedunkelte inaktive Schritte bestehen Kontrast nicht: stattdessen mit Rahmen/Hintergrund betonen.
• role="list" benötigt listitem-Kinder; Abschnittstitel dürfen nicht von h1 auf h3 springen.
• Glühen/Mesh-Hintergründe benötigen randlose Darstellung, eine Maske und body{overflow-x:clip}.
• Ein unbrechbares <code> in einer Rasterzelle verursacht horizontalen Scrollbalken bei 390; ein scrollbares pre besteht scrollable-region-focusable nicht (geben Sie ihm tabindex="0", role="region" und eine eindeutige Bezeichnung, oder verwenden Sie pre-wrap).
• Generische Klassennamen kollidieren zwischen gemeinsamem und produktspezifischem CSS (.tl, .copy): Familienklassen namensräumlich abgrenzen.
• cqw bezieht sich auf einen Vorfahren-Container, niemals auf das Element selbst.
• Ein aria-label, das vom sichtbaren Text abweicht, bricht label-in-name; fügen Sie zusätzlichen Kontext in einen .sr-Span ein.
• Ein Python-Template-String ohne f-Präfix lässt {label} in den barrierefreien Namen einfließen: durchsuchen Sie die Ausgabe.
• loading="lazy"-Bilder fehlen in ganzseitigen Screenshots; kein Fehler.
• Seiten, die durch Extraktion zusammengesetzt werden, aktualisieren sich nicht, wenn sich eine Quelle ändert, bis der Assembler erneut ausgeführt wird.

10. Prozess

1. Lesen Sie das Briefing/Übergabe, den Produktcode und die Dokumentation; erstellen Sie die Faktentabelle und Markierungen (Abschnitt 2).
2. Bestandsaufnahme Branding: Mark-Pfad, Token, Schriftarten (Achsen), vorhandene Captures und deren Probleme.
3. Runde der Richtungen: 3 kleine, unterschiedliche Richtungen pro Produkt, jede um ein Gerät herum aufgebaut. Als Ideenbibliothek aufbewahren.
4. Rückmeldung des Eigentümers → kombinieren Sie die besten Ideen zu einer langen Seite (Abschnittsschiene, FAQ, echter Schnellstart mit Kopierbutton, ein gewichteter „Was Sie akzeptieren“-Block).
5. Die Messlatte höher legen: zuerst eine gemeinsame Familienebene, dann eine kunstvoll gestaltete Seite pro Produkt mit einem Heldenfilm. Unabhängige Produkte können parallel erstellt werden (ein Agent pro Produkt, Familienebene schreibgeschützt, Vorschläge gemeldet und einmal angewendet, dann alle Seiten neu erstellt und erneut verifiziert).
6. Gemeinsam überprüfen: Kontaktbögen, Konsistenzkorrekturen in der Familienebene, vollständige Neuverifikation.
7. Liefern: pro Produkt eine NOTES.md (Konzept, echt vs. Beispiel, Markierungen, Verifikationstabelle); eine HANDOFF.md für die nächste Sitzung (Ziel, Entscheidungen, Markierungen, Schwächen, nächste Ideen); nur zum Ansehen bestimmte eigenständige Vorschauen mit eingebetteten Schriftarten und Captures; eine kurze Zusammenfassung mit einer Empfehlung pro Produkt und warum sie gewinnt.

11. Dateien und Werkzeuge

<proposals-dir>/<date>/
  HANDOFF.md                  Briefing für die nächste Sitzung
  <product>/direction-N.html  Seiten; NOTES.md; fonts/; shots/
  _tools/verify.js            axe x8, Überlauf, Bilder blockiert, JS aus
  _tools/family.py            Gemeinsame Shell, Token, Bewegungskit (Film, Count, Schrift, onView)
  _tools/build_<product>.py   Ein Generator pro Produkt
  _tools/settled.js           Screenshot nachdem der Film zur Ruhe kommt
  _tools/standalone.py        Nur zum Ansehen bestimmte Kopie mit eingebetteten Schriftarten und Captures
  _tools/smoke_<product>.js   Interaktions-Rauchtests

Generatoren enthalten fest codierte Pfade aus der Sitzung, die sie erstellt hat; korrigieren Sie sys.path und Ausgabepfade vor der Ausführung. verify.js erwartet [email protected] installiert in einem Geschwister-verify/node_modules.

12. Checkliste vor dem Zeigen einer Seite

• Erster Viewport besteht den Fünf-Sekunden-Test; das eine Gerät ist dort sichtbar.
• Jede Zahl und jeder Name auf eine Datei zurückverfolgt; Beispieldaten auf der Seite gekennzeichnet; Markierungen in NOTES.md.
• Kompromiss klar genannt und mit visuellem Gewicht versehen.
• Heldenfilm beruhigt sich; Endzustand ist das Standard-HTML; Pause/Wiederholen funktioniert; reduzierte Bewegung und JS aus lesen sich gut.
• Scrollgebundene Effekte verwenden nur Transform/Clip/Stroke; Enthüllungen sind einmalig.
• 390 px entworfen (eigene Zuschnitte, umgeflossene Diagramme), nicht nur gestapelt.
• verify.js ALLE SAUBER (8 Läufe), Parser-Prüfung sauber, Rauchtest sauber, unter 200 KB.
• Screenshots angesehen, beide Designs, beide Breiten, und aufgrund der Ansicht etwas geändert.