Landing Page Craft

Dieses Skill erfasst, wie Favour tatsächlich Landing Pages baut, die nicht nach Vorlage aussehen – destilliert aus seinen eigenen vergangenen Gesprächen über den Bau von Allowance, didii, Revolut Founder Mode, TrashPay und der FlutterBytes-Konferenzseite, und durch sein direktes Feedback zu Testbauten, die mit diesem Skill erstellt wurden, immer wieder geschärft. Es ist kein allgemeiner Leitfaden zu „Best Practices für Landing Pages“ – es ist spezifisch für das, was er immer wieder aufgreift, korrigiert und ablehnt. Es ist auch ein lebendiges Dokument: Lies vor dem Start references/build-log.md und ergänze es nach Abschluss.

Das Ziel ist jedes Mal: etwas mit einem echten Standpunkt, nicht eine kompetente Vorlage mit ausgetauschtem Kundenamen. Und entscheidend: Ein Konzept, das auf den ersten Blick offensichtlich und absichtsvoll wirkt, nicht eines, das erst mit Erklärung Sinn ergibt.

Vor allem: Gibt es genug Material?

Wenn das Briefing kein echtes Produkt bietet, an dem ein Konzept festgemacht werden kann – kein Name, kein Gefühl dafür, für wen es ist, kein Hinweis auf den Ton, nichts, was es von der generischen Version dieser Idee unterscheidet – dann stoppe und frage nach. Ein oder zwei gezielte Fragen sind besser, als eine Platzhalter-Richtung zu erfinden und später festzustellen, dass sie nicht passt.

Zwei weitere konkrete Momente, in denen du fragen solltest, anstatt anzunehmen:

Wenn ein Abschnitt eindeutig von einem echten Foto profitieren würde (nicht einer abstrakten oder vektorbasierten Darstellung), frage vor dem Fortfahren nach einem. Falls es nicht verfügbar ist, sage das und improvisiere mit Farbverläufen und Linien, anstatt ein Stockfoto vorzutäuschen.
Wenn ein Abschnitt repräsentative Beispielinhalte benötigt (Beispielnamen, Beispielkarten, Platzhalterdaten), schlage zuerst eine Version davon vor und lade explizit zu Änderungen ein, anstatt stillschweigend deine eigene Schätzung zu finalisieren.

Wenn genug vorhanden ist – ein echter Name, ein echtes Publikum, ein echter Unterschied, auch nur ein grober – fahre fort.

Build-Stack

Standardziel ist Next.js, TypeScript, Tailwind CSS und Framer Motion. Das ist der tatsächliche Stack hinter jedem Projekt, aus dem dieses Skill gewonnen wurde. Niemals reines HTML oder Vanilla JS als Ergebnis.

Wenn die Arbeitsumgebung diesen Stack nicht live rendern kann, sage das klar, anstatt stillschweigend etwas Schwächeres zu substituieren. Baue trotzdem echte React-Komponenten, niemals Vanilla JS, und approximiere die gewünschten Animationen mit CSS-Übergängen oder der Web Animations API für die Vorschau – biete aber auch die echte Next.js/TypeScript/Framer Motion-Codebasis als herunterladbare Dateien an, und sage klar, ob eine Umgebung, die diesen Stack tatsächlich ausführen und screenshoten kann (z. B. Claude Code), der richtige Ort dafür ist, besonders sobald das echte visuelle Urteil über die Ausgabe wichtiger wird als ein schneller Blick.

Formulare senden immer an ein Google-Formular

Jedes Formular auf der Seite – Warteliste, Kontakt, Anfrage, Bewerbung zum Sprechen, Bestellung/Buchung, was auch immer – ist ein gebrandetes, individuell erstelltes Formular im eigenen Design der Seite, dessen Einsendungen über den Pre-Fill-Link dieses Formulars an ein Google-Formular im Hintergrund weitergeleitet werden. Der Besucher sieht niemals ein rohes Google-Formular; er sieht das Styling der Seite, und die Daten landen in den Antworten des Google-Formulars (und dessen verknüpftem Antworten-Tabellenblatt).

Frage früh danach, sobald klar ist, dass die Seite ein Formular benötigt – es ist eine Abhängigkeit von der Person, wie Fotos. Bitte sie, ein Google-Formular mit Feldern zu erstellen, die zu den Feldern des Seitenformulars passen, und den Pre-Fill-Link zurückzuschicken. Ordne dann jedes Feld auf der Seite der entsprechenden Google-Formular-Eintrags-ID zu, die aus diesem Pre-Fill-Link geparst wurde, und sende es bei der onSubmit-Handler-Funktion des Formulars (der Standardansatz ist ein POST an den /formResponse-Endpunkt des Formulars mit den entry.<id>-Parametern oder ein Äquivalent). Wenn die Person den Link noch nicht bereitgestellt hat, baue die gebrandete Formular-UI vollständig, lasse das Sendeziel aber klar als Platzhalter markiert und gekennzeichnet, anstatt einen Endpunkt zu erfinden.

Gib der Person immer die Schritte, um den Pre-Fill-Link eines Google-Formulars abzurufen, da die meisten Leute nicht wissen, wo er sich befindet:

Öffne das Google-Formular im Bearbeitungsmodus.
Klicke auf das Drei-Punkte-Menü ⋮ oben rechts.
Wähle „Pre-Fill-Link abrufen“ (oder „Get pre-filled link“).
Fülle jedes Feld mit einem erkennbaren Platzhalterwert (z. B. den Namen des Feldes selbst), dann klicke unten auf „Link abrufen“ (oder „Get link“).
Klicke im Popup auf „Link kopieren“ (oder „Copy link“) und sende ihn.

Dieser Link enthält die entry.<id> jedes Feldes und ist genau das, was benötigt wird, um die Felder des gebrandeten Formulars dem Google-Formular zuzuordnen.

Typografie und Farbe – mit der Person ausgewählt, nicht allein entschieden

Bevor du dich für eines von beiden entscheidest, mache eine kurze visuelle Rücksprache, anstatt stillschweigend zu entscheiden:

Typografie: Überprüfe references/typeface-library.md auf Kandidaten, die nicht kürzlich übermäßig verwendet wurden, schlage dann drei markante, nicht offensichtliche Display-Schriftkandidaten vor und rendere den Produktnamen tatsächlich in jedem, auf die Art und Weise, die die Umgebung unterstützt (ein Bild, eine schnelle Vorschau, eine Live-Komponente) – liste niemals nur Schriftnamen als Text auf. Lass die Person aus echten Buchstabenformen wählen, nicht aus einer Vermutung, wie ein Name klingt. Eine wirklich neue Schriftart außerhalb der Bibliothek ist ebenfalls eine willkommene Option – wenn sie ausgewählt wird, füge sie anschließend zu references/typeface-library.md hinzu. Überspringe diesen Vorschlags-und-Bestätigungsschritt niemals – selbst wenn eine starke Empfehlung offensichtlich ist oder eine Bibliotheksschrift bereits verwendet wird, präsentiere die Kandidaten und bestätige sie, anstatt stillschweigend zu entscheiden.
Farbe und Designsprache (Theme): Schlage eine Palette vor (4–6 benannte Werte) mit der Begründung für jede Wahl, die auf dem Thema basiert, und entscheide bewusst über helles vs. dunkles Design, anstatt standardmäßig auf Dunkel zu setzen (siehe die Designregel in references/taste-rules.md – viele Marken wirken hell besser). Bestätige beides, bevor es endgültig ist.
Stilrichtung: Wähle neben Typografie und Farbe eine dominante Stilfamilie für die gesamte Seite aus den benannten Familien in references/section-bank.md (Aurora/Pastell-Glow, Neo-Glow Dark Tech, Clean-Tech Organic, Editorial/Brutalistisch, Minimalistisch High-Key, Luxury/Premium Showcase, Corporate B2B/Fintech) – gewählt aus einem kurzen, spezifischen Grund, nicht aus Gewohnheit. Dies ist die Spur, in der später die Abschnittsbibliothek durchsucht wird; Ausleihen außerhalb sind ein bewusster Akzent, kein Standard.

Beide Testbauten haben dies bisher übersprungen und beides allein entschieden – es ist zweimal gut gelandet, aber das ist Glück, nicht der Prozess, der wie beabsichtigt funktioniert.

Seitenart zuerst

Kläre vor allem anderen, um welche der sieben Formen es sich handelt – die Geschmacksregeln und das Framework unten gelten für alle, aber die Abschnittsinventur und, für die Business-, Europa- und Mini-Business-Typen, auch der visuelle Ansatz unterscheiden sich:

Produkt-Landingpage (Allowance, didii, TrashPay) – wartelisten- oder download-fokussiert, Preise, Anwendungsfälle, Feature-Grid.
Portfolio / Case-Study-Seite (Revolut Founder Mode) – der eigene Konzept-Pitch eines Designers: ein Bio-Block, reale Statistiken zur Relevanz, „Kontakt aufnehmen“ statt einer Warteliste.
Event / Konferenzseite (FlutterBytes) – Sprecher-Vorstellung, frühere Ausgaben, Team-Credits, Sponsoren, Agenda.
Business-Seite (ein Modelabel, eine Bäckerei, ein Salon, ein Studio – ein etabliertes, reales Unternehmen, kein Startup) – verkauft ein echtes Produkt oder eine Dienstleistung, die bereits existiert, daher bildlastig und atmosphärisch zuerst, nicht Feature-Grid-zuerst. Ziel: Etwa 75 % der Abschnitte basieren auf echter Fotografie (Speisekarte/Lookbook/Galerie/Räumlichkeiten), wobei die Signature-Bewegungs- und Animationsregeln auf die Bilder aufgesetzt werden, anstatt sie zu ersetzen.
Hybrid – eine bewusste Mischung aus zwei oder drei der oben genannten (ein Produkt, das auch ein Event bewirbt, ein Unternehmen mit einem Portfolio früherer Arbeiten). Wähle den dominanten Typ für die Gesamtstruktur und den Abstand, leihe dann die spezifischen Abschnitte aus, die der sekundäre Typ benötigt.
Europäische Website – eine saubere, zurückhaltende, hochwertige Website im Stil hochwertiger europäischer Studio-/Framer-Vorlagen. Gleiche Grundlagen wie die anderen, aber der Hero ist bewusst einfach: ein oder mehrere passende echte Fotos (von Unsplash, Pexels oder Pixabay heruntergeladen) als Hintergrund des Hero in einem ~98 % breiten, abgerundeten rechteckigen Rahmen, ohne darauf geschichtete, geschäftige Signatur-Visuals. Keine Warteliste. Schlicht, aber nicht langweilig.
Mini-Business-Landingpage – eine kompakte, hochwertige One-Pager, genau vier Abschnitte (Hero, Angebot, Nachweis, Kontakt), entwickelt, um etablierte, oft traditionelle Unternehmen zu pitchen, die noch keine Webpräsenz haben – Maschinenhändler, Massenexporteure, Hersteller, Industriezulieferer, Großhändler. Diese muss überzeugend genug sein, um ein Unternehmen ohne Website an eine zu glauben, also setzt sie stark auf hochwertige echte Fotografie, echte Vertrauenssignale (Statistiken, Kundenlogos, Zertifizierungen) und einen selbstbewussten, abwechslungsreichen Hero – siehe references/site-types.md für die fünf Hero-Varianten, zwischen denen rotiert wird, und den obligatorischen Abschnitt „Kontaktieren Sie uns“.

Lies references/site-types.md für die Abschnittsinventur und strukturelle Hinweise zu jedem Typ. Wenn es wirklich keiner von diesen ist, behandle es als am nächsten an einer Produkt-Landingpage und passe an.

Der Prozess

Orientiere dich. Markenname, was sie tut, für wen sie ist, alle genannten Referenzseiten oder Stimmungen. Wenn klar ist, dass die Seite ein Formular benötigt (Warteliste, Kontakt, Anfrage, Bestellung), sprich die Google-Formular-Abhängigkeit jetzt an – bitte die Person, das Google-Formular zu erstellen und den Pre-Fill-Link zu senden, damit es am Ende keine Hektik gibt.
Finde das eine Kernkonzept, bevor du einen Abschnitt anfasst. Keine Feature-Liste – die eine Sache, die der Benutzer tatsächlich von diesem Produkt bekommt oder fühlt, ausgedrückt als ein einfacher Satz, plus zwei oder drei unterstützende Ideen. Jeder Signature-Move jedes Abschnitts wird später dagegen geprüft. Frage die Person auch direkt, ob sie bereits Konzepte, visuelle Ideen oder Ideen hat, die sie gerne einbringen oder illustrieren würde – besonders für den Hero –, damit ihre eigene Vision das Konzept speist, anstatt von einem erfundenen überschrieben zu werden.
Wähle Typografie und Farbe mit der Person (oben), basierend auf dem Thema, nicht allein entschieden.
Entscheide den Seitentyp (oben) und überfliege seine Abschnittsinventur. Überprüfe references/build-log.md, was aktuelle Projekte verwendet haben, damit dieses nicht zufällig an das letzte erinnert.
Führe jeden Abschnitt durch die folgende Intake-Checkliste, Seite an Seite, und bewerte dann ehrlich, bevor du Layout oder Code schreibst.

Intake, pro Abschnitt:
- Was ist dieser Abschnitt und wie viel visuelles Gewicht verdient er? Ein Hero verdient mehr als ein Vertrauensbaustein.
- Worum geht es im Produkt allgemein und worum geht es in diesem Abschnitt speziell, basierend auf seinem tatsächlichen Titel, Untertitel und Inhalt – nicht einem generischen Label für seine Kategorie?
- Welches Konzept folgt aus diesem Inhalt? Überprüfe references/concept-gallery.md auf bereits erfundene Konzepte – verwende eines, das nicht abkühlt, passe eines an oder erfinde etwas Neues und füge es anschließend dort hinzu.
- Was bietet die Abschnittsdesign-Bank? Nimm zwei oder drei Kandidatenreihen aus references/section-bank.md (abgestimmt nach Abschnittskategorie, dann nach der Stilrichtung des Projekts), wiege sie gegen eine selbst erfundene Option ab und passe den Gewinner gemäß den „Anpassen, nicht transplantieren“-Regeln der Bank an – die Palette, Schriftarten und Pixel-Spezifikationen der Reihe werden auf dieses Projekt umgemappt, und der Abschnitt muss den Zwei-Sekunden-Test für diese spezifische Marke bestehen.
- Welche Animation oder Hover-Interaktion bringt es zum Leben? Die Animationsspalte der Bank ist ein hier zu verwendendes Vokabular (Strich-Offset-Zeichnungen, Kilometerzähler-Hochzählungen, Flex-Grow-Erweiterungen, gestaffelte Einträge, Masken-Enthüllungen) – dennoch niemals zweimal dieselbe primitive Animation auf einer Seite.
- Wie lang sind Titel und Untertitel? Kurze können eine zentrierte/umgebende Behandlung tragen (siehe die Layout-Archetypen in references/taste-rules.md); längere können das nicht.
- Welches Layout und welchen Signature-Move hat der unmittelbar vorhergehende Abschnitt verwendet, und was hat das letzte Projekt verwendet? Wiederhole keines von beiden.
Bewerte ehrlich und verwende überprüfbare Checks anstelle bequemer Zahlen:
- Landet das Konzept auf einem der drei generischen KI-Design-Standards (warmes Creme + Serife + Terrakotta, fast Schwarz + ein Säure-Akzent, oder Breitblatt/Feinlinien-Zeitungsstil) ohne einen kurzspezifischen Grund? Das ist ein Fehlschlag – gehe zurück zum Intake.
- Würde diese exakte Wahl auftauchen, wenn derselbe Prompt für ein völlig anderes Produkt ausgeführt würde? Wenn ja, ist es noch nicht spezifisch genug.
- Würde ein Fremder in etwa zwei Sekunden verstehen, wofür es steht, ohne Bildunterschrift? Ein Konzept, das erst mit Erklärung funktioniert, ist fehlgeschlagen, egal wie clever die Argumentation war.
Bewertung ist eine Disziplin, die immer läuft, nichts, was man zeigt – die Person sieht das resultierende Konzept und ein klares Urteil, keine Punktetafel. Sei ehrlich über die echte Einschränkung: Ohne eine Möglichkeit, ein Rendering tatsächlich zu sehen, ist die Selbsteinschätzung eher eine sorgfältige Code-Überprüfung als ein echtes visuelles Urteil, also sei skeptisch statt großzügig. Wenn die Umgebung den Build tatsächlich ausführen und screenshoten kann, nutze das – ein echter Blick schlägt die Vorhersage.
Baue den vollständigen ersten Entwurf, unter Verwendung der bewerteten Konzepte plus der stehenden Regeln in references/taste-rules.md.
Gehe Abschnitt für Abschnitt vor und überprüfe die Qualität jedes einzelnen anhand der gebauten Seite. Frage für jeden Abschnitt:
- Verbindet sich dieser Abschnitt sichtbar mit dem Kernkonzept aus Schritt 2, oder illustriert er nur isoliert sein eigenes Feature?
- Ist die Nicht-Text-Seite eines zweispaltigen Abschnitts tatsächlich lebendig – eine animierte Mini-Oberfläche, ein Bildschirmausschnitt oder ein eigenständiges Konzept – oder ist es ein totes flaches Bild? Nicht „Sind das zwei Spalten?“, sondern „Ist hier etwas statisch, das nicht sein sollte?“
- Ist das eine schlichte umrandete Karte, wo ein ausblendender Trenner oder etwas Durchdachteres besser wäre? Bleibt die gesamte Seite innerhalb von ein oder zwei kartenverwendenden Abschnitten insgesamt? Wenn es eine Karte ist, hat sie eine echte Individualisierungsnote (glänzender Farbverlaufsfüller, glasartiger Rand, animiertes Icon) und eine echte Hover-Interaktion?
- Stammen alle Icons aus der gewählten benutzerdefinierten Icon-Bibliothek (Lucide/Phosphor/Heroicons/Tabler), ohne Emojis als …

Landing-Page-Craft

Was ist Landing-Page-Craft?

In Ihrer bevorzugten KI fragen

Dokumentation