--- title: "Design Systems in Flutter: Tokens, die Menschen und KI-Agenten verstehen" description: "Brand Drift schleicht sich unbemerkt ein. Wie semantische Design Tokens, ein App-UI-Package und Golden Tests deine Flutter-App konsistent halten, für Menschen und KI-Agenten." canonical_url: "https://robocitrus.com/blog/design-system-flutter-design-tokens-ki-agenten" --- > Index of every page on this site: [llms.txt](https://robocitrus.com/llms.txt) ## Wenn die App langsam komisch aussieht Du kennst das vielleicht. Die App ist poliert, alle benutzen dieselben Komponenten, und trotzdem sieht irgendwas leicht schief aus. Der Primary Button hat auf zwei Screens zwei Blautöne. Die Abstände sind auf Seiten, die gleich aufgebaut sein sollten, unterschiedlich. Auf der FlutterCon 2026 hat ein Talk genau dafür einen Namen geliefert: Brand Drift. Der Kern: Niemand entscheidet sich dafür. Es sind viele kleine Abkürzungen. Ein Sonderfall, wenig Zeit, ein schnell gebauter Custom-Button. Einzeln ist das okay. Dann nutzt ihn jemand anderes woanders, und du merkst es nicht mal, weil das Team gewachsen ist. Das Problem ist laut Talk nicht, dass Leute nachlässig sind. Die Begründung hinter einer Entscheidung wurde nie so festgehalten, dass das ganze Team sie wiederverwenden kann. Ich finde, das beschreibt auch meinen Alltag ziemlich gut. Und dann kam ein zweiter Talk dazu, der das Thema aus einer ganz anderen Richtung beleuchtet hat: KI-Agenten. ## Ein Design System ist eine Sprache Der erste Talk hat das Design System als Sprache erklärt. Mit Vokabular und Grammatik. Das Bild trägt erstaunlich weit. **Vokabular sind Tokens.** Ein Token ist eine benannte Designentscheidung: eine Farbe, eine Schriftgröße, ein Radius. Und der Name entscheidet alles. `blue500` sagt nur, was der Wert ist. `color.action.primary` sagt, wofür er da ist. Das Gegenteil davon sind fest verdrahtete Werte, wie ich sie in [Was ist Hardcoding?](https://robocitrus.com/blog/was-ist-hardcoding) erkläre. Der Unterschied zeigt sich beim Dark Mode oder bei einem Rebrand. Zeigt jeder Button auf `blue300`, suchst du alle Stellen. Zeigt er auf `color.action.primary`, änderst du eine Zuordnung. Der Button hängt an einer Rolle, nicht an einem Blau. **Grammatik sind Komponenten.** Tokens sagen nichts über Verhalten. Eine Komponente schon: hover, pressed, disabled, loading. Die Speaker nennen sie einen Vertrag. Designer wissen, was schon gebaut ist. Entwickler wissen, welche Zustände sie unterstützen müssen. Eine Regel daraus will ich mir merken: Eine Komponente ist erst fertig, wenn alle Zustände und das komplette Verhalten durchdacht sind. Nicht, wenn die Farbe stimmt. ## Wie Flutter diese Sprache spricht Zur Technik. Die Speaker haben Material, Cupertino und die Widgets-Library verglichen: - **Material** ist ausgereift und flexibel genug. Für die meisten Teams der pragmatische Start. - **Cupertino** ist näher an Apples Human Interface Guidelines, lässt sich aber nur begrenzt anpassen. - **Widgets** ist die unterste Ebene. Maximale Kontrolle, aber du baust Komponenten und Theming komplett selbst. Wer Material nutzt und eine eigene Markenidentität braucht, erweitert `ThemeData` mit `ThemeExtensions`. Dort wohnen zusätzliche Farben und Komponentenstile. Für Interaktionszustände gibt es `WidgetStateProperty`. Damit definierst du einmal, wie ein Button auf hover, pressed oder disabled reagiert, statt es auf jedem Screen neu zu bauen. Spannend fand ich auch die Richtung des Frameworks. Flutter stellt immer mehr Widgets über die Widgets-Library bereit, unabhängiger von Material oder Cupertino. Das gibt mehr Freiheit für eigene Design Systems. Wenn du tiefer in Flutter einsteigen willst, [warum ich Flutter liebe](https://robocitrus.com/blog/warum-ich-flutter-liebe) erklärt, warum ich dabei bleibe. ## Ein Package für die Designentscheidungen Der Vorschlag der Speaker: ein eigenes Package, zum Beispiel `app_ui`. Dort leben Themes, Tokens und Komponenten. Die Abhängigkeit geht nur in eine Richtung. `app_ui` weiß nichts von deinen Features. Ein Button darf einen Text und einen Loading-Zustand bekommen. Er darf nicht wissen, ob er gerade eine Bestellbestätigung zeigt. Damit das Package kein Müllplatz für Widgets wird, braucht es Aufnahmekriterien: 1. Ist das eine geteilte Designentscheidung? 2. Wird es in mehreren Features genutzt? 3. Ist es ein wiederverwendbares visuelles Muster ohne Domänenwissen? Ein Button oder eine Card gehören hinein. Eine `CheckoutSummary` bleibt beim Feature. Dazu kommt eine klare öffentliche API, damit du intern umbauen kannst, ohne dass jedes Feature mitzieht. Ein Detail, das ich sofort übernehme: Benenne Dinge im Code genauso wie in Figma. Heißt es dort Primary Button, heißt es bei dir nicht `BlueButton`. Jede Übersetzung zwischen den Namen ist eine Fehlerquelle. ## Der Plot-Twist: Agenten brauchen dieselbe Ordnung Dann der zweite Talk. Dominik von Visible, einer Plattform für Menschen mit chronischen Erkrankungen, hat erzählt, wie sie ihre Codebase für KI-Agenten zugänglich gemacht haben. Sein Team ist klein, zwei bis drei Entwickler über rund viereinhalb Jahre, mit Fokus auf Time-to-Market. Das Ergebnis war genau das, was Brand Drift im Code aussieht: Seiten, die nach unterschiedlichen Konventionen gebaut waren. Seine Beobachtung Anfang 2026: Agenten erfanden neue Muster und brachen Konventionen. Sein Beispiel war ein Button, der im Code `primary` hieß, aber eigentlich der Sekundär-Button war. Ein Mensch kennt die Geschichte dahinter. Der Agent sucht einen Primary Button und findet den falschen. Was das Team getan hat: - **Komponenten-APIs vereinheitlicht**, mit klaren Namen und Verhalten. - **Styles als Enums** statt loser Text-Styles mit Padding und Extension-Methoden. - **Eingeschränkte Seitenlayouts.** Statt rohe Widget-Bäume zu schreiben, wählt man über Parameter aus, was oben und in der unteren Leiste erscheint. Das sind Konfigurationen, keine Widgets. - **Design Tokens vereinheitlicht.** Ein Label mit Primärfarbe, eines mit Blau, eines mit Navy: Für Menschen dieselbe Farbe, für einen Agenten eine Ratestunde. Dazu kam, dass Figma Hex-Codes liefert. Der Satz, der hängen bleibt: Die Änderungen machten den Code nicht nur für Agenten zugänglicher, sondern auch für Menschen. Wer ein 60-Zeilen-PR voller roher Widgets reviewt, ist schnell überfordert. Mit Constraints und Live-Vorschau ist es lesbar. ## Previews statt Warten Beide Talks landen bei derselben Idee: Mach Komponenten sichtbar. Talk eins empfiehlt eine Gallery-App, die alle Komponenten isoliert zeigt: mit Zuständen, Varianten, Themes, Textlängen und Schriftgrößen. Figma und Umsetzung nebeneinander zeigen sofort die Lücken. Die Gallery läuft in der CI und deployt bei jeder Änderung eine aktuelle Vorschau. Dominiks Team hat dasselbe als Web-Playground gebaut. Der Auslöser: Bis ein Mobile-Build beim Designer ankommt, vergehen Stunden. Mit dem Playground sieht der Designer neue Komponenten direkt im PR. Außerdem lief die App auf macOS, damit auch Nicht-Entwickler sie ohne Android Studio und Simulatoren starten können. Das Ergebnis: Designer haben begonnen, selbst Code beizutragen. ## Tests als Leitplanken Ohne Absicherung verliert ein Design System Vertrauen. Der erste Talk setzt auf zwei Testarten: - **Widget Tests** prüfen Verhalten: Callbacks, Zustandswechsel, was bei Tap passiert. - **Golden Tests** prüfen Aussehen. Du speicherst einen Snapshot, die CI vergleicht jede Änderung damit. Schlägt der Test fehl, entscheidet ihr gemeinsam mit dem Design, ob die neue Optik Absicht war. Das funktioniert nur, wenn es in der CI läuft und den Pull Request blockiert. Ich halte das für den günstigsten Weg, "den richtigen Weg zum Standardweg zu machen". Wie ich das bei Tests im Allgemeinen sehe, steht auch in meinem Beitrag zu [Flutter State Management](https://robocitrus.com/blog/flutter-state-management-2026). ## Menschen bleiben im Loop Beide Talks sind sich an einer Stelle einig: Technik allein reicht nicht. Talk eins nennt es Governance. Ist das ein neuer Token? Variante wiederverwenden oder neu anlegen? Ausnahme oder Teil des Systems? Entwickler besitzen das Design System mit. Und ein Argument fand ich pragmatisch: Sprich über Geld. Probleme früh zu stoppen ist billiger, als sie über mehrere Sprints zu reparieren. Dominik berichtete, dass Reviews trotz mehrerer automatisierter Durchgänge immer noch Fehler fanden: eine komplett falsche Zeile, eine unnötige neue Datenbanktabelle. Sein Fazit: Man wird damit vielleicht kein 25-facher oder 50-facher Entwickler, aber ein fünffacher. Ich sehe das genauso. Mehr dazu, wie ich [KI in der App-Entwicklung](https://robocitrus.com/blog/ki-in-der-app-entwicklung) nutze, steht in einem eigenen Beitrag. ## Was ich daraus mitnehme Das mache ich in meinen eigenen Projekten, das ist meine Meinung und nicht die der Speaker: - **Tokens nach Rolle benennen**, nicht nach Wert. Das ist ein Nachmittag Arbeit und spart bei jedem Rebrand Tage. - **Ein app_ui-Package früh anlegen**, auch für eine kleine App. Je später, desto mehr Aufräumen. - **Eine Komponente erst als fertig zählen, wenn alle Zustände stehen.** - **Golden Tests für die zehn wichtigsten Komponenten.** Nicht für alles. - **Constraints als Feature sehen.** Eine enge API hilft dem Agenten, dem Reviewer und dir in drei Monaten. ## Fazit Brand Drift entsteht durch Abkürzungen, nicht durch Böswilligkeit. Dagegen helfen semantische Tokens als Vokabular, Komponenten als Vertrag und Tests als Leitplanke. Der Zusatz aus dem zweiten Talk: Dieselbe Ordnung, die Menschen hilft, hilft auch KI-Agenten. Wer klare Namen, enge APIs und sichtbare Vorschauen hat, bekommt bessere Ergebnisse von beiden. Fang klein an. Ein Token-Schema, eine Komponente mit allen Zuständen, ein Golden Test. Der Rest wächst daraus. --- ## Häufig gestellte Fragen (FAQ) Brand Drift beschreibt, wie eine App durch viele kleine Ausnahmen und Abkürzungen nach und nach inkonsistent wird, obwohl alle dieselben Komponenten nutzen. Typisch sind mehrere Varianten desselben Buttons oder uneinheitliche Abstände. Ein Token, der die Rolle beschreibt statt den Wert, etwa `color.action.primary` statt `blue500`. Bei Dark Mode oder Rebrand änderst du die Zuordnung an einer Stelle, nicht jede Komponente. Widget Tests für Verhalten (Callbacks, Zustände) und Golden Tests für das Aussehen. Beide gehören in die CI, damit inkonsistente UI nicht im Main-Branch landet. Rein gehört, was eine geteilte Designentscheidung ist, in mehreren Features genutzt wird und kein Domänenwissen hat, etwa Button oder Card. Feature-spezifische Widgets wie eine Bestellübersicht bleiben im jeweiligen Feature. Agenten sehen nicht die Geschichte hinter dem Code. Heißt ein Button `primary`, ist aber sekundär, greifen sie falsch zu. Klare Namen, enge APIs und eindeutige Tokens nehmen ihnen das Raten ab. --- *Dieser Artikel wurde inspiriert von zwei Talks auf der FlutterCon 2026: einem zu Design Systems und Brand Drift in Flutter und dem Vortrag von Dominik (Visible) über lesbaren Flutter-Code für Menschen und KI-Agenten.* ## Sitemap See the full [sitemap](https://robocitrus.com/sitemap.md) for all pages.