Design-Engineering-Fallstudie
Flex Academy: eine einzige Quelle der Wahrheit
Ein Konzept aus einer Probeaufgabe für The Flex / Base360: eine Landingpage, die zwei Programme an zwei verschiedene Zielgruppen verkauft, gebaut als verbundenes System aus Figma-Variablen, Komponenten im Code, Storybook-Dokumentation und einem Live-Prototyp.
Über das Projekt
Einführung
Flex Academy ist ein neues Produkt von The Flex, seit 2019 Betreiber möblierter Apartments, und Base360, der daraus entstandenen KI-Plattform für Unternehmen der Kurzzeitvermietung (STR). Die Academy zeigt, wie man ein STR-Geschäft mit demselben Playbook, denselben Systemen und derselben Software startet und skaliert. Das Briefing verlangte eine Landingpage für zwei Programme, Launch und Scale, rein als Designaufgabe. Ich habe die Seite zusätzlich in ein kleines Designsystem im Code verwandelt, um zu zeigen, wie ich von Anfang bis Ende arbeite.
Meine Rolle
Product Designer, verantwortlich für den Prozess.
Strategie, UX, UI, Designsystem, Regeln für die KI-Tools und Review jeder Änderung.
Zeitraum & Art
3 Tage aktive Arbeit (5.–7. Okt. 2026). Eine Design-Probeaufgabe und ein Konzept, kein Produktions- oder Kundenprojekt. Entwicklung war nicht Teil des Briefings; Code und Storybook habe ich zusätzlich gemacht.
Tools
Figma (Variables, Variants) · Storybook 10 · Next.js 16 · React 19 · TypeScript · Tailwind CSS v4 · Claude Code · Figma MCP · GitHub · Vercel
Die Herausforderung
Problemstellung
Eine Seite musste zwei Angebote an zwei sehr unterschiedliche Menschen verkaufen: an „9-to-5-Aussteiger“, die noch nicht angefangen haben, und an frühe Betreiber, die schon einige Einheiten führen, aber in manueller Arbeit und dünnen Margen feststecken. Die Zielgruppe ist beschäftigt und „Guru“-Kursen gegenüber offen skeptisch. Wie kann eine Seite schnell Vertrauen gewinnen und jede Person auf das passende Angebot reagieren lassen?
Aufschlüsselung des Problems
Zwei Zielgruppen, eine Seite
Einsteiger und Betreiber haben unterschiedliche Probleme, unterschiedliches Vertrauen und unterschiedliche Handlungsbereitschaft. Eine Seite, die alle gleich anspricht, überzeugt niemanden.
Eingebaute Skepsis
Der Bildungsmarkt ist voller „Guru“-Kurse, deshalb muss Vertrauen vor jedem Pitch entstehen.
Lücke zwischen Design und Code
Eine Probeaufgabe endet meist mit statischen Screens. Ich wollte, dass Designentscheidungen ohne Abweichungen im Code leben: Ein Token einmal ändern, und Figma, Storybook und die Website aktualisieren sich gemeinsam.
Klare Erfolgskriterien
Nach 5 Sekunden weiß man, worum es geht, nach 30 Sekunden vertraut man der Seite, und man kann von überall auf der Seite handeln.
Wichtige Screens
Hero mit zwei Einstiegen: Launch in Grün, Scale in Blau.
Vertrauensblock direkt nach dem Hero, vor jedem Angebot.
Zwei CTA-Flows: Webinar-Anmeldung und Buchung eines Strategiegesprächs.
Die zwei Zielgruppen
Launch ist für „9-to-5-Aussteiger“ mit null oder einer Einheit: ein Kurs im eigenen Tempo, Live-Gruppensessions und Vorlagen, Einstieg über ein kostenloses Webinar.
Scale ist für frühe Betreiber mit einigen Einheiten: 12 Wochen wöchentliche Gruppensessions, ein monatliches 1:1 mit einem Gründer, Community, SOPs und Zugang zu Base360, Einstieg über ein kostenloses Strategiegespräch.
Launch · Webinar
Geringe Hürde. Name, E-Mail, Land → Bestätigung und Eintrag in den Kalender.
Scale · Strategiegespräch
Hohe Kaufabsicht. Einheiten heute, Ziel, Stadt, Budgetrahmen → Termin wählen → Bestätigung.
Noch nicht bereit · Checkliste
Sekundäre Conversion: eine STR-Skalierungscheckliste gegen eine E-Mail-Adresse.
Prozess
1. Briefing-Analyse
Zwei Personas, eine Pain-Map und Erfolgskriterien.
2. Wireframes in Figma
Desktop 1440, Mobile 390, beide CTA-Flows und Designnotizen.
3. Marken-Audit
Echte Computed Styles aus theflex.global und base360.ai extrahiert und in Figma-Variablen überführt: Primitives → semantische Aliase. 157 Ebenen an Variablen gebunden.
4. Aufbau Block für Block
Code im Prototyp → Prüfung im Browser → Korrekturen → Storybook mit allen Zuständen und Doku → Spiegelung in Figma als Component Set.
Wichtige Designentscheidungen
Zwei Türen, ein Hero. Launch steht vorne, weil es der größere Markt ist, aber Scale bekommt das gleiche visuelle Gewicht, sodass Betreiber nicht an Inhalten vorbeiscrollen müssen, die nicht für sie sind. Vertrauen vor dem Pitch: Der Vertrauensblock steht direkt nach dem Hero, vor jedem Angebot, mit den Gründern, den öffentlichen Zahlen des Unternehmens (seit 2019, 400+ Wohnungen, £10M+ Umsatz, 7 Städte) und Presselogos.
Farbe mit Bedeutung: Launch nutzt das Grün von The Flex, die Geschichte, wie die Gründer angefangen haben; Scale nutzt das Blau von Base360, weil Scale Zugang zu Base360 beinhaltet. Getrennte Flows für unterschiedliche Absichten: Das Webinar ist ein kurzes Formular mit drei Feldern, das Strategiegespräch qualifiziert den Lead zuerst und lässt dann einen Termin wählen.
Vertrauen gewinnen
Dem Einwand direkt begegnen
Ein Abschnitt „Not another guru course“ vergleicht das Programm mit YouTube, günstigen Kursen und Masterminds, statt so zu tun, als gäbe es keine Zweifel. Ein separater Gründerblock wurde gestrichen, weil er den Vertrauensblock wiederholte: lieber eine kürzere Seite als eine Wiederholung.
Keine erfundenen Testimonials. Für eine skeptische Zielgruppe zerstören erfundene Zitate das Vertrauen, deshalb bleibt Social Proof als klar markierte Platzhalter.
Responsives Design
Design-Engineering-Pipeline
Statt statischer Screens habe ich die Seite als System mit einer einzigen Quelle der Wahrheit gebaut: Figma-Variablen → tokens.json → tokens.css → Tailwind v4 @theme → Komponenten → Storybook → Live-Website.
Tokens von Live-Websites
Echte Computed Styles von theflex.global und base360.ai, nicht nach Augenmaß, umgewandelt in Figma-Variablen: Marken-Primitives plus semantische Aliase wie offer/launch und offer/scale. Dieselben 70 Tokens leben im Code, ohne hart codierte Farben, Abstände oder Radien in den Komponenten.
18 Komponenten, 88 Stories
Jede Komponente ist in Storybook mit allen Zuständen, Props, Barrierefreiheitsnotizen und einem Token Usage Report dokumentiert: Eigenschaft · Token · Wert · Quelle.
Ehrliche „AI-defined“-Markierungen
Alles, was nicht in Figma definiert war, ist in der Doku offen als „AI-defined“ markiert, damit Reviewer sehen, welche Entscheidungen aus dem Design kamen und welche nicht.
Figma spiegelt den Code
Komponenten in Figma als Variantensets (Breakpoint, State, Tone, Step) neu gebaut und an dieselben Variablen gebunden. Die Screens sind daraus zusammengesetzt.
Modal + echte URL
CTA-Flows öffnen sich als Modal, während die URL zu /webinar oder /strategy-call wechselt. Öffnet man diesen Link direkt, aus einer Anzeige oder einer E-Mail, lädt dasselbe Formular als ganze Seite.
Barrierefreiheit
01
Scale nutzt ein tieferes Blau (#3B4FE0, etwa 5,6:1 zu Weiß) statt des Button-Blaus von Base360 (#5070FE, etwa 3,9:1), das AA für normalen Text nicht erfüllt.
02
CTA-Flows nutzen ein natives <dialog>: Focus Trap, Schließen mit Escape, Fokus-Rückgabe und Scroll-Sperre. Eingabefelder sind 48px hoch.
03
Scroll-Animationen sind reines CSS, ohne Animationsbibliotheken, und respektieren prefers-reduced-motion.
Wie ich mit KI gearbeitet habe
Ich habe Richtung, Regeln und Umfang festgelegt: was gebaut wird, wie die Tokens strukturiert sind, Benennung, Entscheidungen zur Barrierefreiheit und Review-Kriterien.
Regeln, Review und Prüfungen
Claude Code schrieb den Großteil der Umsetzung nach diesen Regeln, festgelegt in Projektanweisungen, einem eigenen Skill und Handoff-Dokumenten. Zwei Branches, prototype und design-system, teilen identische Komponentendateien. Ich habe jede Änderung geprüft, Typecheck, Lint und den Storybook-Build ausgeführt, jeden Block in einem echten Browser bei 1440, 820 und 390 px geprüft und jeden Push freigegeben.
Was ich als Nächstes tun würde
Echte Dienste
Echte Terminplanung, CRM und E-Mail statt der aktuellen Platzhalter anbinden.
Echte Geschichten von Teilnehmenden
Platzhalter-Testimonials durch echte Geschichten von Teilnehmenden ersetzen.
Testen und verifizieren
Einen Hero mit Fokus auf Betreiber per A/B-Test prüfen und automatisierte visuelle Regressionstests für Storybook ergänzen.
Ergebnis
Eine Figma-Datei mit Designsystem, CTA-Flows und Designnotizen; ein Storybook mit 18 Komponenten und 88 Stories, jede mit Token Usage Report; und ein Live-Prototyp auf Vercel, gebaut aus genau diesen Komponenten. Design, Code und Doku, die nicht auseinanderlaufen können: Ein Token einmal ändern, und er aktualisiert sich überall.
In Zahlen (Arbeitsumfang, kein Geschäftsergebnis)
• 18 Komponenten und 88 Stories
• 70 Tokens synchron in Figma, Storybook und auf der Website
• 2 Branches und 2 Vercel-Projekte
• 47 Commits in prototype, 36 in design-system
• 3 Tage aktive Arbeit (5.–7. Okt. 2026)
Was ich gelernt habe
Selbst eine Landingpage als kleines Designsystem zu behandeln, zahlt sich schnell aus: Einmal in Tokens getroffene Entscheidungen erscheinen konsistent in Figma, im Code und in der Doku, und KI-Tools werden deutlich zuverlässiger, wenn sie innerhalb klarer Regeln arbeiten.
Ehrliche Grenzen
Das ist ein Konzept, keine Produktionswebsite. Backend, Kalender und CRM sind Platzhalter, Testimonials sind Platzhalter und Preise werden nicht angezeigt. Safari und eine echte Kalenderintegration wurden nicht getestet.