Designsysteme für 30 Apps: Wie Figma und Flutter perfekt synchronisiert werden

Ein konsistentes Nutzererlebnis über Dutzende mobiler Anwendungen hinweg zu gewährleisten, ist eine Herausforderung – doch genau das haben wir bei Xenotix Labs gemeistert. Mit über 30 vertikalen Apps in Branchen wie E-Commerce, Bildung, Gesundheitswesen und Sportmarketing setzen wir auf ein zentrales Designsystem, das Figma und Flutter nahtlos verbindet. Der Schlüssel? Ein einziger Quell der Wahrheit, der Design und Entwicklung synchron hält.

Warum ein zentrales Designsystem unverzichtbar ist

Mehr als 30 Flutter-Apps in unterschiedlichen Domänen zu entwickeln, bringt eine zentrale Herausforderung mit sich: Jede App beginnt mit einem Figma-Entwurf, einem Designsystem und einer Komponentenbibliothek. Doch der Teufel steckt im Detail. Sobald sich Design und Code voneinander entfernen, entsteht Misstrauen zwischen Teams – und der vielzitierte Spruch „Von Figma in die Produktion“ wird zur Realität.

Die Lösung liegt in einem einheitlichen Designsystem, das Design und Entwicklung als eine einzige Quelle der Wahrheit behandelt. Design-Tokens, Komponenten und Layout-Primitiven werden zentral definiert und automatisch in beide Welten – Figma und Flutter – übertragen. So wird sichergestellt, dass jede Anpassung sofort in beiden Systemen sichtbar ist.

Design-Tokens: Die atomaren Bausteine

Design-Tokens sind die kleinsten, wiederverwendbaren Einheiten eines Designsystems: Farben, Schriftgrößen, Abstände, Radien und Bewegungsdauern. Statt diese Werte in Figma und Flutter manuell zu pflegen, definieren wir sie einmalig in einer JSON-ähnlichen Struktur und generieren daraus beide Systeme.

{
  "color": {
    "primary": {"value": "#3F51FF"},
    "surface": {"value": "#FFFFFF"},
    ...
  },
  "space": {
    "xs": {"value": 4},
    "sm": {"value": 8},
    ...
  },
  "radius": {
    "card": {"value": 12},
    ...
  }
}

Ein Build-Skript erzeugt daraus eine Flutter-Datei (tokens.dart), die stark typisierte Konstanten enthält. Gleichzeitig importieren Designer dieselbe JSON-Datei in Figma über das Tokens Studio-Plugin. Ändert ein Designer nun die Primärfarbe, passt sich sowohl die Figma-Bibliothek als auch der Flutter-Code automatisch an. Diese mechanische Synchronisation eliminiert Diskrepanzen und schafft Vertrauen zwischen Design und Entwicklung.

Komponentenbibliothek: Konsistenz durch Wiederverwendung

Auf den Tokens aufbauend entstehen Komponenten wie Buttons, Eingabefelder, Karten oder Modals. Jede Komponente wird jedoch zweimal umgesetzt: einmal als Figma-Komponente mit Varianten und Eigenschaften, einmal als Flutter-Widget mit benannten Parametern.

Ein zentraler Grundsatz: Flutter-Widgets greifen ausschließlich auf Tokens zu, niemals auf harte Werte. Statt padding: EdgeInsets.all(8) heißt es also padding: EdgeInsets.all(tokens.space.sm). Diese Herangehensweise stellt sicher, dass jede Anpassung eines Tokens automatisch in allen Komponenten und Apps wirksam wird.

Layout-Primitiven: Der Grundstein jeder App

Viele Teams starten mit der Entwicklung einzelner Widgets – doch das führt schnell zu Redundanz. Stattdessen setzen wir auf vorgefertigte Layout-Komponenten, die als Basis für jede Bildschirmansicht dienen:

• XScaffold(title, body, primaryAction) – Ein grundlegendes Scaffold mit Titel, Hauptinhalt und einer primären Aktion
• XBottomSheet(title, body, dismissAction, confirmAction) – Ein modaler Sheet mit Titel, Inhalt und Interaktionsmöglichkeiten
• XListPage(searchBar, items, onLoadMore, emptyState) – Eine Seite mit Suchleiste, unendlichem Scroll und leerem Zustand

Diese Primitiven ermöglichen es Teams, neue Projekte nicht auf Widget-Ebene, sondern auf Layout-Ebene zu starten. Eine Anmeldemaske besteht dann aus zwei Widgets, nicht aus zwanzig – und spart damit Zeit und reduziert Fehlerquellen.

Paketstruktur: Ein System für alle Apps

Alle Tokens, Komponenten und Layouts werden in einem internen Flutter-Paket (xenotix_design) gebündelt. Jede App bezieht dieses Paket entweder als Pfadabhängigkeit oder über Git. Updates des Pakets propagieren in alle Apps, sobald die Entwickler ihr pubspec.yaml aktualisieren.

Die Versionierung folgt klaren Regeln:

• Hauptversionen enthalten Breaking Changes
• Nebenversionen fügen neue Komponenten oder nicht-brechende Verbesserungen hinzu
• Apps binden sich an eine Hauptversion und aktualisieren Nebenversionen nach eigenem Zeitplan

Diese strenge Versionierung verhindert unerwartete Änderungen und gibt Teams die Kontrolle über den Aktualisierungsprozess.

Der Workflow: Von Figma zur Produktion ohne Reibungsverluste

Der Übergang von Figma zu Flutter ist oft ein neuralgischer Punkt. Unser Workflow minimiert diese Reibung:

1. Der Designer arbeitet in Figma mit der geteilten Bibliothek, die auf den zentralen Tokens basiert
2. Der Designer veröffentlicht einen Frame mit Notizen zu Interaktionszuständen, Inhalten und Randfällen
3. Der Entwickler identifiziert, welche bestehenden Komponenten verwendet werden und welche neu benötigt sind
4. Bei neuen Komponenten arbeiten Designer und Entwickler gemeinsam an der Erweiterung der geteilten Bibliothek – beide Systeme (Figma und Flutter) werden gleichzeitig aktualisiert
5. Der Entwickler setzt die Bildschirmansicht durch Komposition bestehender Komponenten um

Dokumente wie „Kannst du den Abstand hier von 14 auf 16 Pixel erhöhen?“ gehören der Vergangenheit an, da Abstände als Tokens definiert sind und automatisch synchronisiert werden.

Designsystem als interaktives Storybook

Um die Konsistenz weiter zu stärken, pflegen wir ein Storybook – eine interaktive Flutter-App, die alle Komponenten, Varianten und Zustände auf einer einzigen navigierbaren Oberfläche darstellt. Designer können es auf ihrem Smartphone durchblättern, Entwickler nutzen es als Nachschlagewerk: „Gibt es diesen Button bereits in dieser Variante?“ – und erhalten sofort eine Antwort.

Das Storybook dient zudem als automatisierte Testoberfläche. Visuelle Snapshot-Tests laufen bei jedem Pull Request und fangen selbst minimale Änderungen wie „Der Button ist in diesem PR einen Pixel höher“ ab.

Fünf essenzielle Ratschläge für den Einstieg

Wer ein eigenes Designsystem für Flutter aufbaut, sollte folgende Prinzipien beachten:

• Tokens zuerst, Komponenten danach – Ein Komponentensystem, das ohne Tokens aufgebaut wird, führt später zu technischen Schulden
• Ein Paket, nicht drei – Tokens, Komponenten und Layouts sollten zunächst in einem Paket gebündelt werden, um Abhängigkeitsprobleme zu vermeiden
• Storybook von Woche eins an – Es ist der schnellste Weg, um Abweichungen zwischen Design und Code zu erkennen
• Visuelle Differenztests in der CI – Fängt selbst kleinste Änderungen ab, bevor sie ein Designer bemerkt
• Keine Anpassungen pro App – Customizations sollten über Tokens (z. B. Farbüberlagerungen, Abstandsanpassungen) erfolgen, nicht durch Forks der Widgets

Technischer Stack im Überblick

• Tokens: JSON, generiert für Dart und synchronisiert mit Figma via Tokens Studio
• Komponentenbibliothek: Eigenes Flutter-Paket mit wiederverwendbaren Widgets
• Layout-Primitiven: Vordefinierte Scaffold- und List-Widgets für schnelle Prototypen
• Storybook: Interaktive Flutter-App mit visuellen Tests
• Verteilung: Internes Git-Monorepo, versionsgestützte Abhängigkeiten
• Tests: flutter_test für Unit-Tests, alchemist oder golden_toolkit für visuelle Snapshots

Ein zentrales Designsystem ist der Unterschied zwischen einer kohärenten Marke und 30 isolierten Produkten. Wenn du eine Produktfamilie mit mehreren Apps skalierst und dabei ein einheitliches Nutzererlebnis sicherstellen möchtest, bietet dieses Vorgehen einen bewährten Leitfaden. Die Investition in ein solches System zahlt sich aus – in Form von Zeitersparnis, konsistentem Branding und weniger Frustration zwischen Design und Entwicklung.