Figma zu Webflow: Die Experten-Checkliste für einen sauberen, skalierbaren Build

Euer Designer hat ein wunderschönes Figma-File geliefert. Jetzt muss jemand daraus eine Webflow-Seite machen, die tatsächlich funktioniert, gut performt, mit eurem Content-Team skaliert, sich in euer CRM integriert, und sechs Monate nach dem Launch noch zusammenhält, wenn drei verschiedene Leute daran editiert haben. Genau hier entdecken die meisten B2B-SaaS-Teams, dass Figma zu Webflow keine Übergabe ist.

Es ist ein Engineering- und Architektur-Problem. Das Figma-File sagt euch, wie die Seite aussehen soll. Es sagt nichts darüber, wie das CMS strukturiert sein sollte, wie sich Components über Breakpoints hinweg verhalten sollen, wie sich das Designsystem in Webflow-Klassen übersetzt, oder wie die Seite gepflegt werden soll, nachdem die Zusammenarbeit mit der Agentur endet.

Diese Checkliste ist nicht für Entwickler geschrieben. Sie ist für die Marketing-Verantwortlichen, Brand Directors und Growth-Teams geschrieben, die solche Builds beauftragen, damit ihr wisst, welche Fragen ihr stellen solltet, wie Qualität aussieht, und was eine Seite, die mit eurem Fortschritt altert, von einer unterscheidet, die in drei Monaten Probleme macht.

Wo die meisten Figma-zu-Webflow-Builds schiefgehen

Die Lücke zwischen einem polierten Figma-File und einer produktionsreifen Webflow-Seite ist größer, als sie aussieht. Figma ist ein Design-Tool. Webflow ist eine Entwicklungsumgebung mit echten Einschränkungen: Browser-Rendering, CMS-Architektur, responsives Verhalten, Performance-Budgets, Barrierefreiheits-Standards, und Wartbarkeitsanforderungen, die in einem Design-File schlicht nicht existieren.

Die häufigsten Fehlermuster sind nicht kosmetisch. Sie sind strukturell:

Jedes dieser Probleme ist vermeidbar. Keines davon lässt sich nach dem Launch ohne erheblichen Mehraufwand beheben. Der Zeitpunkt, sie anzugehen, ist, bevor ein einziges Element auf dem Canvas platziert wird.

Der professionelle Build-Prozess, Schritt für Schritt

Ein professioneller Figma-zu-Webflow-Build folgt einer strukturierten Abfolge. Jeder Schritt baut auf dem vorherigen auf. Einen davon zu überspringen ist, wo die Probleme beginnen.

Schritt 1: Figma-File-Audit

Die erste Frage, die jeder ernsthafte Webflow-Experte stellen sollte, ist nicht "wann fangen wir an zu bauen?", sondern "ist dieses Figma-File bereit, daraus zu bauen?"

Die meisten sind es nicht, und das ist keine Kritik am Designer. Figma-Files sind darauf optimiert, visuelle Absicht zu kommunizieren, nicht für die Engineering-Übergabe. Ein File, das perfekt als Design-Referenz funktioniert, braucht Übersetzung, bevor es zu einer build-reifen Spezifikation wird.

Ein richtiges Figma-Audit deckt ab:

Component-Inventar: Jedes wiederkehrende Element, Cards, Buttons, Navigations-Zustände, Formularfelder, Testimonial-Blöcke, Preiszeilen, muss identifiziert und einer Webflow-Component oder einem Symbol zugeordnet werden. Wenn das Figma-File 12 leicht unterschiedliche Button-Varianten hat, müssen die vor Build-Start rationalisiert werden, nicht danach.

Design-System-Konsistenzcheck: Nutzen alle Typo-Stile konsistente Skalen? Sind Abstandswerte konsistent oder willkürlich? Nutzen Farben benannte Styles oder hartcodierte Hex-Werte? Webflows Klassensystem funktioniert am besten, wenn es auf einem kohärenten Designsystem aufbaut.

CMS- vs. statische-Seiten-Entscheidungen: Welche Seiten enthalten Content, der regelmäßig editiert wird? Blogbeiträge und Case Studies sind offensichtliche CMS-Kandidaten, aber Preis-Sections, Team-Seiten, Integrations-Verzeichnisse und Feature-Listen müssen oft auch CMS-gesteuert sein. Diese Entscheidung formt die gesamte Build-Architektur.

Review der Responsive-Spezifikation: Enthält das Figma-File Mobile- und Tablet-Frames für jede Section? Überall dort, wo die Spec zu Zwischen-Breakpoints schweigt, wird eine Einschätzung getroffen. Besser, diese Entscheidungen bewusst vor dem Build zu treffen, nicht reaktiv während dessen.

Custom-Interaktions-Inventar: Jede Animation, jeder Hover-Zustand, jeder Scroll-Trigger und jede Mikro-Interaktion muss für Webflow bewertet werden. Manche sind trivial. Manche brauchen Custom JavaScript. Zu wissen, was was ist, bevor ihr euch auf einen Scope festlegt, verhindert Überraschungen mitten im Build.

Schritt 2: CSS-Architektur

Wenn es beim Figma-Audit darum geht, zu verstehen, was gebaut werden muss, geht es bei der CSS-Architektur-Entscheidung darum, wie es gebaut wird und ob es von Leuten wartbar ist, die nicht im Raum waren, als es entstand.

Das ist die wichtigste einzelne technische Entscheidung in einem Webflow-Build, und die, die am häufigsten von Teams schlecht getroffen wird, die keine Webflow-Spezialisten sind.

Webflow ist mächtig, aber bewusst neutral dabei, wie ihr eure Klassen strukturiert, es erzwingt keine Namenskonvention, es verlangt nur, dass welches System ihr auch wählt, innerhalb von Webflows Konzept aus Single Classes und Combo Classes funktioniert. Ihr könnt damit alles bauen.

Ihr könnt auch eine Seite bauen, bei der Klassen zufällig benannt, inkonsistent verschachtelt, und für jeden anderen unmöglich zu editieren sind, ohne etwas kaputtzumachen. Das passiert ständig bei Seiten, die von Generalisten-Entwicklern oder nicht spezialisierten Agenturen gebaut wurden.

Die am weitesten verbreitete Konvention in professionellen Webflow-Builds ist Client-First von Finsweet: eine strukturierte Namenskonvention und ein CSS-Framework, speziell für Webflow entwickelt. Sie erzeugt konsistente, vorhersehbare Klassen-Hierarchien, die jeder geschulte Webflow-Entwickler verstehen und pflegen kann.

Client-First ist allerdings nicht der einzige valide Ansatz, wichtig ist, dass das Team, mit dem ihr arbeitet, ein dokumentiertes, konsistentes System nutzt, das innerhalb von Webflows Single-Class- und Combo-Class-Struktur funktioniert.

Was das praktisch für ein Marketing- oder Growth-Team bedeutet:

• Eine Seite, gebaut auf einem dokumentierten System wie Lumos, kann an jeden Webflow-geschulten Entwickler für laufende Wartung übergeben werden, ohne langen Onboarding-Prozess.
• Content-Editoren im Webflow Editor können Änderungen vornehmen, ohne versehentlich Layouts zu zerstören.
• Neue Seiten und Sections können hinzugefügt werden, indem etablierte Muster befolgt werden, statt bestehende zurückzuentwickeln.
• Die Codebasis bleibt 18 Monate nach dem Launch lesbar und erweiterbar.

Fragt jede Agentur oder jeden Entwickler, den ihr evaluiert, ob sie Lumos oder ein dokumentiertes Äquivalent nutzen. Wenn die Antwort vage oder abweisend ist, behandelt das als Warnsignal.

Schritt 3: CMS-Architektur

Das Webflow CMS ist der Punkt, an dem Figma-zu-Webflow-Builds am häufigsten von dem abweichen, was ein B2B-SaaS-Marketing-Team tatsächlich braucht. Ein CMS, gebaut, um zu einem Figma-Layout zu passen, ist ein CMS, gebaut für den Launch-Zustand der Seite. Es ist selten gebaut für die Realität, die Seite sechs Monate später zu betreiben.

Der richtige Ansatz ist, mit dem redaktionellen Workflow des Content-Teams zu starten und rückwärts zur Collection-Struktur zu arbeiten, nicht das Figma-File anzuschauen und Collections auf Seiten-Sections zu mappen.

Ein gut architektiertes CMS umfasst:

Jede Collection braucht mehr als Content-Felder. Jedes CMS-Template braucht ein Meta-Titel-Feld, ein Meta-Description-Feld, ein Canonical-URL-Feld, und ein OG-Bild-Feld. Das ist nicht optional. Das ist, was Webflow-CMS-Content SEO-bereit macht, statt nur sichtbar.

Der häufigste Fehler: eine große "Blog"-Collection zu erstellen und alles hineinzupacken. Getrennte Content-Typen mit getrennter Suchintention gehören in getrennte Collections mit getrennten URL-Strukturen und getrennten Templates.

Schritt 4: Component-Build

Das ist die Phase, die die meisten Kunden nie direkt sehen, aber sofort spüren, wenn sich etwas ändern muss.

In Webflow sind Components global wiederverwendbar. Ändert die Component einmal, und sie aktualisiert sich überall, wo sie genutzt wird. Eine Seite, gebaut ohne Symbols, oder mit inkonsistent genutzten Symbols, braucht manuelle Updates über jede Instanz einer Component hinweg, wenn sich etwas ändert. Bei dem Maßstab, in dem eine wachsende SaaS-Seite operiert, wird das zu einem echten Flaschenhals.

Jedes Element, das mehr als zweimal auf einer Seite erscheint, sollte eine Component sein:

• Navigation (Desktop- und Mobile-Zustände)
• Footer
• CTAs (Primär-, Sekundär-, Inline-Varianten)
• Card-Components (Blog-Card, Case-Study-Card, Team-Card)
• Testimonial-Blöcke
• Preis-Tiers
• Feature-Zeilen

Component-Properties gehen noch weiter, indem sie lokale Überschreibungen von Content innerhalb einer geteilten Component erlauben, oder das Wechseln zwischen Varianten, ohne die globale Struktur zu brechen. Das heißt, eine einzelne Card-Component kann mehrere Kontexte bedienen, unterschiedlicher Text, unterschiedliche Bilder, unterschiedliche Zustände, und trotzdem global aktualisieren, wenn sich das zugrundeliegende Design ändert.

Webflows Variables-System erlaubt es außerdem, globale Design-Tokens wie Farben, Typografie-Skalen, Abstandswerte zentral zu verwalten und seitenweit zu aktualisieren. Ein Build, der Variables korrekt nutzt, heißt, dass ein Markenfarben-Update 30 Sekunden dauert, nicht drei, um zu suchen und zu ersetzen.

Schritt 5: Custom Code

Webflows visueller Builder deckt den Großteil dessen ab, was eine B2B-SaaS-Marketing-Seite braucht. Aber manche Interaktionen, Integrationen und Verhaltensweisen brauchen Custom JavaScript oder CSS. Das ist kein Problem. Custom Code ist eine legitime und mächtige Fähigkeit in Webflow. Das Problem ist Custom Code, der undokumentiert, ohne klaren Geltungsbereich, und ungetestet ist.

Ein paar reale Beispiele für Custom Code:

• Erweitertes CMS-Filtering (oft über Finsweet CMS-Filter-Attribute, was eine sauberere Lösung als direktes JS ist).
• Cookie-Consent-Management und GTM-Consent-Mode-Konfiguration.
• Anpassung von Drittanbieter-Embeds (Chat-Widgets, Demo-Buchungstools, Videoplayer).
• Komplexe Animationen jenseits der nativen Fähigkeiten von Webflow Interactions.
• Bedingte Content-Sichtbarkeit basierend auf URL-Parametern oder UTM-Werten.

Der Standard, an den ihr jeden Entwicklungspartner halten solltet:

• Jeder Custom-Code-Block sollte kommentiert sein mit dem, was er tut, warum er existiert, und was er anfasst.
• Externe Skripte sollten asynchron geladen und auf Core-Web-Vitals-Einfluss getestet werden.
• Custom Code sollte auf die Seiten begrenzt sein, wo er gebraucht wird, nicht global geladen werden, wenn es nicht nötig ist.
• Jedes JS, das mit CMS-Content interagiert, sollte einen klaren Fallback haben, falls sich die CMS-Struktur ändert.
• CSS und JavaScript sollten nicht in einem Embed gemischt werden, damit das CSS direkt im Designer rendert und nicht nur auf der veröffentlichten Seite.

Custom Code, der ohne Dokumentation hinzugefügt wird, ist technische Schuld, die sofort ankommt. Sechs Monate später, wenn ein Entwickler, der ihn nicht geschrieben hat, ihn ändern muss, wird die Kosten dieser undokumentierten Arbeit sehr deutlich.

Schritt 6: Integrations- und Tracking-Setup

Eine Webflow-Seite ohne richtig konfigurierten GTM-Container, verifizierte Analytics-Events, und CRM-Integration ist kein Marketing-Asset. Sie ist nur eine Broschüre, ein Portfolio. Für B2B-SaaS-Teams, bei denen jede Formular-Absendung Pipeline-Wert hat, verdient die Tracking- und Integrationsebene denselben Fokus wie der visuelle Build.

Integrations-Checkliste:

• GTM-Container installiert und veröffentlicht sich korrekt.
• GA4 konfiguriert mit Kern-Events (Formular-Absendung, CTA-Klick, Scroll-Tiefe, Demo-Anfrage).
• HubSpot- oder CRM-Tracking-Code aktiv, und Formular-Absendungen leiten in die richtige Pipeline.
• Conversion-Events im GTM-Preview-Modus vor Launch verifiziert.
• Cookie-Consent-Tool installiert und mit GTM-Consent-Mode integriert.
• Webflow-Formulare mit CRM verbunden, über native Integration oder Zapier.
• UTM-Parameter-Weitergabe auf allen Lead-Capture-Formularen verifiziert.

Ein häufig übersehener Punkt: UTM-Parameter-Weitergabe. Wenn eure bezahlten Kampagnen Traffic mit UTM-Parametern senden und eure Formulare diese Werte nicht erfassen und an euer CRM weitergeben, könnt ihr Umsatz nicht auf Kampagnen zurückführen. Das ist eigentlich eine 20-Minuten-Konfiguration, die viele Builds ohne ausliefern.

Schritt 7: Pre-Launch-QA

Der Build ist fertig. Bevor sich ein einziger DNS-Eintrag ändert, muss Folgendes systematisch verifiziert werden.

Technisches QA:

• Screaming-Frog-Crawl der Staging-Seite, keine 404er, keine fehlenden Meta-Titel, keine doppelten H1s.
• PageSpeed Insights auf Mobile und Desktop, LCP unter 2,5 Sekunden, CLS unter 0,1.
• Alle Webflow-SEO-Einstellungen bestätigt: Sitemap aktiviert, robots.txt geprüft, noindex auf allen Live-Seiten aus.
• Canonical-Tags korrekt gesetzt auf allen CMS-Template-Seiten.
• Alle Formulare durchgängig mit einer echten Absendung getestet.
• Alle externen Links öffnen in neuen Tabs.
• Alle Bilder haben beschreibenden Alt-Text.

Content- und Design-QA:

• Alle Seiten überprüft auf Desktop (1440px), Tablet (768px), und Mobile (375px).
• CMS-Template-Seiten getestet mit Grenzfall-Content (sehr lange Titel, fehlende optionale Felder).
• Alle Animationen und Interaktionen getestet in Chrome, Safari und Firefox.

Der Mobile-Test ist nicht optional. Mehr als die Hälfte des organischen B2B-SaaS-Traffics kommt über Mobile. Ein Layout, das in Webflows Designer-Vorschau bei 375px korrekt aussieht, ist nicht dasselbe wie ein Layout, getestet auf einem echten Gerät. Beide Checks sind erforderlich.

Was dieser Build tatsächlich erfordert

Wenn man diese Checkliste noch einmal durchgeht, ist das Muster klar: Ein professioneller Figma-zu-Webflow-Build ist keine Aufgabe, die man einem Generalisten-Entwickler, einem Freelancer, der von einem Template aus arbeitet, oder einer Agentur übergeben kann, die auf zehn verschiedenen Plattformen baut.

Es braucht jemanden, der Webflows CMS-Architektur tief genug versteht, um Collections um den redaktionellen Workflow herum zu designen. Es braucht einen Entwickler, der standardmäßig in Webflow baut. Es braucht ein Team, das von Tag eins an über Wartbarkeit nach dem Launch nachdenkt, nicht als nachträglichen Gedanken.

Für B2B-SaaS- und wachsende Unternehmen sind die Kosten eines schlecht gemachten Builds nicht nur der Mehraufwand. Es sind die sechs Monate verlorenen Marketing-Tempos, während das Team auf Fixes wartet, die SEO-Performance, verloren an eine langsame oder schlecht strukturierte Seite, und die Pipeline, verloren an kaputte Formulare und Tracking-Lücken.

Genau das ist die Art von Arbeit, auf die sich Designbase spezialisiert. Wir arbeiten ausschließlich in Webflow mit B2B-Unternehmen im DACH-Raum, und jeder Build folgt der Architektur und den Qualitätsstandards, die in dieser Checkliste beschrieben sind. Wenn ihr ein Figma-zu-Webflow-Projekt plant und sicherstellen wollt, dass es von Tag eins an richtig gemacht wird, meldet euch.