Wonach suchst du?
Genau hier setzt ein Design System an. Es ist nicht das Farbschema aus dem Corporate-Design-Handbuch und auch nicht die Figma-Datei, in der irgendwo mal alles gesammelt wurde. Es ist ein System aus verbindlichen Bausteinen, Regeln und Entscheidungen, mit dem Design, Redaktion und Entwicklung dieselbe Sprache sprechen.
Und es kommt ein Argument hinzu, das die Diskussion verändert: Künstliche Intelligenz macht ein gutes Design System nicht überflüssig – sie macht es zur Voraussetzung. Denn KI beschleunigt genau das, was Ihr ihr vorgibt. Ohne saubere Grundlage skaliert sie Euer Chaos.
Die wichtigsten Punkte auf einen Blick:
Die Begriffe werden munter durcheinander verwendet. Drei Abgrenzungen, die im Projektalltag den Unterschied machen: Ein Styleguide beschreibt. Eine Bibliothek liefert. Ein Design System entscheidet.
Ein Styleguide dokumentiert, wie etwas aussehen soll: Farben, Typografie, Logo-Abstände, Bildsprache. Er beschreibt, aber er liefert nichts, mit dem man direkt arbeiten kann.
Eine Komponenten-Bibliothek liefert die Bausteine: Buttons, Cards, Formularelemente. Sie zeigt, was es gibt, aber nicht, wann welcher Baustein der richtige ist.
Ein Design System verbindet beides und ergänzt das Entscheidende: Regeln, Kontext und Governance. Es beantwortet nicht nur „Wie sieht der Button aus?“, sondern „Welcher Button in welcher Situation und warum?“. Es ist ein lebendes Produkt mit klaren Verantwortlichkeiten und einer versionierten Bibliothek. Kein Dokument, das man einmal abliefert.
Ein Design System spart Zeit, sichert Eure Marke und macht Teams schneller produktiv. Und es ist die Grundlage dafür, dass KI in Design und Entwicklung verwertbare Ergebnisse liefert. Fünf Effekte im Überblick.
Konsistenz entsteht nicht durch gute Absichten, sondern durch verfügbare Bausteine. Wenn das richtige Element in zwei Klicks bereitsteht, wird es benutzt. Wenn es erst gesucht oder nachgebaut werden muss, entstehen Varianten. Und Varianten sind der Anfang von Markenverwässerung.
Sparkbox hat acht Developer dieselbe Aufgabe zweimal umsetzen lassen: Einmal von Grund auf, einmal mit dem Carbon Design System. Ergebnis: 47 % Zeitersparnis im Median, von 4,2 auf 2 Stunden. Gleichzeitig kamen die beiden konsistentesten Umsetzungen aus der Design-System-Gruppe. Bei einem Developer sprang die Bewertung von Platz 14 auf Platz 1.
Rechnet das auf ein Relaunch-Projekt mit 40 Templates hoch und Ihr habt den Business Case.
Sobald mehrere Websites, Ländergesellschaften oder Sub-Brands ins Spiel kommen, wird Konsistenz zur organisatorischen Frage. Ein Design System ist die einzige Antwort, die nicht in monatlichen Abstimmungsrunden endet.
Neue Teammitglieder, neue Agentur, neue Redakteur:innen: Wer die Bausteine und Regeln an einem Ort findet, ist schneller produktiv. Genau dafür bauen wir bei jedem TYPO3-Projekt zusätzlich einen Living Styleguide direkt im CMS. Die Redaktionssicht auf das Design System. Das beendet auch die typische Diskussion im Redaktionsalltag, welche von drei Teaser-Varianten denn nun die aktuelle ist.
Kontrastwerte, Fokus-Zustände, Tastaturbedienbarkeit, Touch-Zielgrößen: Diese Themen einmal in der Komponente richtig zu lösen, ist deutlich effizienter, als sie in jedem Projekt neu zu prüfen. Barrierefreiheit wird so vom Nachgedanken zum Standardverhalten. Und viele der Reibungspunkte, die wir in UX-Audits finden, entstehen genau dort, wo Komponenten uneinheitlich umgesetzt wurden.
Die kleinsten Designentscheidungen, aus denen alles andere entsteht:
Buttons, Inputs, Cards, Navigation, Tabellen, Accordions, Modals – jeweils mit allen Zuständen: Default, Hover, Focus, Active, Disabled, Error, Loading, Empty.
Die Zustände sind der Teil, der am häufigsten fehlt und am teuersten nachgeliefert wird.
Aus Foundations und Komponenten entstehen Module: fertige Bausteine, aus denen später ganze Seiten zusammengesetzt werden – Hero-Varianten, Teaser-Reihen, Formular-Layouts, Content-Module, Leadmagnet-Blöcke.
Jedes Modul hat eine klare Aufgabe. Wer diesen Baukasten kennt, setzt eine neue Seite daraus zusammen, statt sie neu zu entwerfen.
Module ergeben in Kombination ganze Seiten. Auf dieser Ebene legt Ihr fest, welche Bausteine in welcher Reihenfolge einen Seitentyp bilden – eine Startseite, eine Leistungsseite, eine Landingpage, eine Detailseite.
Das Ergebnis sind Seitenvorlagen statt Einzelentwürfe: Wer eine neue Seite braucht, kombiniert vorhandene Module nach einem erprobten Muster. Aufbau und Wirkung sind damit planbar – und eine neue Seite entsteht in Stunden statt in Tagen.
Figma ist für uns nicht das schönere Design-Tool, sondern die Arbeitsumgebung, in der das System technisch tragfähig wird.
Farben, Abstände, Radien und Typo-Werte liegen als Variablen im System – nicht als Hex-Code in einer Ebene. Über Modes lassen sich Light- und Dark-Varianten, Brand-Themes oder Ländervarianten aus derselben Struktur ableiten, ohne alles zu duplizieren. Das ist die Grundlage für Design Tokens.
Jede Komponente existiert einmal, mit sauber benannten Properties für Größe, Zustand und Inhalt. Änderungen an der Master-Komponente wirken überall. Das ist der eigentliche Effizienzgewinn.
Das System liegt als publizierte Bibliothek vor, Projekte konsumieren es. Eine Änderung an der Bibliothek wird zentral veröffentlicht und kann projektweise übernommen werden. Damit bleibt kontrollierbar, was wann in welchem Projekt ankommt, statt dass Anpassungen per Zuruf in einzelnen Dateien landen.
Design und Entwicklung arbeiten auf derselben Grundlage: Was in der Bibliothek definiert ist, ist die verbindliche Vorgabe für die Umsetzung. Statt Werte aus Screenshots abzuleiten, greifen unsere Entwickler:innen auf das Design System als Referenz zu. Zunehmend KI-gestützt, indem sie sich Komponenten, Zustände und Werte direkt erschließen.
Der nächste Ausbauschritt ist eine direkte Verbindung zwischen Design- und Code-Komponenten, wie Figma sie mit Code Connect anbietet. Damit wäre im Design nicht nur sichtbar, wie ein Element aussieht, sondern auch, welche Code-Komponente dazugehört. Die klassische Rückfrage „ist das jetzt ein neuer Button oder unser bestehender?“ würde damit entfallen.
Ein System, drei Perspektiven: Design in Figma, Code im Frontend, Redaktion im CMS.
KI-Werkzeuge sind in Design- und Entwicklungsprozessen angekommen. Aber sie liefern nur dann brauchbare Ergebnisse, wenn sie wissen, in welchem System sie arbeiten.
Figma formuliert es treffend: Einen KI-Agenten ohne Design-System-Kontext Code generieren zu lassen, sei wie einen neuen Entwickler ohne Onboarding direkt Features ausliefern zu lassen.
Die Zahlen dazu sind eindeutig: Laut Figmas AI Report nutzen 68 % der Entwickler:innen KI zur Code-Generierung, aber nur 32 % der Designer:innen und Entwickler:innen vertrauen dem Output. Die Lücke ist kein KI-Problem. Sie ist ein Kontext-Problem.
Mit einem definierten System wird KI im Designprozess wirklich nützlich:
Wichtig: KI ersetzt hier keine Designentscheidung. Sie beschleunigt die Ausführung getroffener Entscheidungen. Das ist der Unterschied zwischen Werkzeug und Autopilot.
Auf der Code-Seite ist der Effekt noch direkter. Unsere Entwickler:innen greifen KI-gestützt auf das Design System zu und lesen daraus, welche Komponente in welchem Zustand mit welchen Werten vorgesehen ist. Die Umsetzung erfolgt anschließend regulär im Frontend, aber auf einer Grundlage, über die nicht mehr diskutiert werden muss.
Das Ergebnis:
Technisch geht das noch weiter: Über MCP-Server lässt sich der Design-Kontext aus Figma direkt in die Entwicklungsumgebung holen. Welche Komponente, welche Variable, welcher Token, welche bestehende Code-Komponente. Je vollständiger das System gepflegt ist, desto größer der Effekt.
Wer schon mit MCP-Anbindungen in TYPO3 gearbeitet hat, kennt das Prinzip: Nicht das Modell wird besser, sondern der Kontext, den es bekommt.
Und dann passiert etwas Interessantes: Besseres Design System, besserer KI-Output. Besserer KI-Output, mehr Nutzung des Systems. Mehr Nutzung, mehr Anlass zur Pflege. Figma nennt Design Systeme in diesem Zusammenhang die „Lingua franca zwischen Design und KI“.
Umgekehrt gilt das genauso: Wer kein System hat, produziert mit KI schneller Inkonsistenz als je zuvor. Das ist die eigentliche Dringlichkeit hinter dem Thema.
Wenn Ihr wissen wollt, wie das in Eurem Setup aussehen kann, sprecht uns gerne an.
Jetzt Kontakt aufnehmen
Ein Design System, das nur in einer Figma-Datei existiert, ist für Menschen lesbar. Liegt es in Tokens vor, ist es auch für Maschinen lesbar. Genau darauf läuft die Entwicklung zu.
Design Tokens sind benannte Designentscheidungen in maschinenlesbarer Form. Statt #0A3D62 heißt der Wert color.brand.primary. Statt „24 Pixel Abstand“ heißt es spacing.lg. Die Werte liegen strukturiert – als JSON – und lassen sich für jede Plattform übersetzen: CSS-Variablen für das Web, entsprechende Formate für iOS, Android oder Flutter.
Der Gewinn ist nicht Kosmetik. Ändert sich die Markenfarbe, ändert sich ein Token – und die Änderung landet in allen Kanälen, statt in 40 Dateien gesucht zu werden.
Bisher hatte jedes Tool sein eigenes Token-Format. Der Austausch war Bastelei. Das ändert sich gerade.
Die Design Tokens Community Group – eine Community Group beim W3C – hat am 28. Oktober 2025 die Version 2025.10 des Design Tokens Format Module veröffentlicht: die erste als stabil und produktionsreif deklarierte Fassung. Sie deckt unter anderem ab:
Auf Tool-Seite bewegt sich entsprechend viel: Style Dictionary, Tokens Studio und Terrazzo haben implementiert; Figma, Sketch, Penpot, Framer, Knapsack, Supernova und zeroheight haben Unterstützung angekündigt oder in Arbeit. Co-Chair Kaelig Deloumeau-Prigent fasst das Ziel so zusammen: Design-System-Teams könnten nun „eine Single Source of Truth bewahren, die überall funktioniert“ – von Design bis Produktionscode.
Eine Einordnung, die wichtig ist: Das Format Module ist ein Community Group Report, kein offizieller W3C-Standard, und durchläuft nicht den formalen W3C-Standardisierungsprozess. Wer also liest, „Design Tokens sind jetzt W3C-Standard“, liest eine Verkürzung. Praktisch relevant ist etwas anderes: Es ist das erste Format, hinter dem die gesamte Tool-Landschaft steht. Und genau das macht einen De-facto-Standard.
Wohin führt das? Unsere Einschätzung in drei Stufen:
Kurzfristig – Austauschbarkeit. Tokens wandern verlustfrei zwischen Design-Tool, Repository und Build-Prozess. Der manuelle Abgleich zwischen Design und Code entfällt.
Mittelfristig – Automatisierung. Der Weg von der Designentscheidung bis zum ausgelieferten CSS wird zur Pipeline. Ein Token-Update durchläuft Review, Build und Deployment wie jede andere Änderung. Design wird Teil der Continuous Integration.
Langfristig – eine Grundlage für Mensch und Maschine. Wenn Foundations als Tokens, Komponenten über Code Connect und Regeln als strukturierte Dokumentation vorliegen, entsteht ein Design System, das KI-Agenten vollständig erschließen können. Nicht als Inspiration, sondern als verbindliche Vorgabe. Die Frage ist dann nicht mehr, ob eine generierte Seite zur Marke passt – sondern nur noch, ob sie die richtige Antwort auf die Nutzerfrage ist.
Das ist keine ferne Zukunft. Die Bausteine existieren bereits. Was fehlt, ist in den meisten Unternehmen die aufgeräumte Grundlage.
Von der Bestandsaufnahme bis zur verbindlichen Grundlage: Ein Design System entsteht nicht in einem Rutsch, sondern in einer sinnvollen Reihenfolge.
Ein Design System entsteht in einer sinnvollen Reihenfolge. Nach diesen fünf Schritten gehen wir vor, wenn wir ein Design System für Kunden aufbauen:
Bestandsaufnahme
Sammelt, was tatsächlich im Einsatz ist: alle Button-Varianten, alle Farbwerte, alle Abstände über Website, Shop und Kampagnenseiten hinweg. Diese Übung ist unangenehm und aufschlussreich. Meist finden sich ein Vielfaches der geplanten Varianten.
Foundations festlegen
Systematisieren statt reduzieren. Der Unterschied ist entscheidend: Sieben zufällig entstandene Blautöne sind ein Problem. Eine bewusst definierte Range ist die Lösung.
Wir legen Primärfarben deshalb nicht als Einzelwerte an, sondern als Skala: 500 als Base, von dort in 100er-Schritten auf- und absteigend bis 50. Damit stehen für Hover-Zustände, gestapelte Flächen, Rahmen und Hintergründe abgestimmte Abstufungen bereit – statt dass im Projekt improvisiert wird. Dasselbe Prinzip gilt für Neutraltöne und Feedback-Farben.
Entscheidend ist die semantische Zuordnung: Nicht blue.500 steht im Design, sondern die Funktion, die dieser Wert erfüllt.
blue.500
Tokens strukturieren
Legt die Namenslogik fest, bevor Ihr 300 Tokens anlegt. Eine gute Struktur trennt Rohwerte (blue.600) von semantischen Tokens (color.action.primary) und komponentenspezifischen Tokens (button.primary.background). Diese Trennung ist später der Unterschied zwischen Pflege und Neuaufbau.
blue.600
color.action.primary
button.primary.background
Komponenten priorisieren
Nicht alles gleichzeitig. Beginnt mit den Bausteinen, die am häufigsten vorkommen: Buttons, Formularelemente, Karten, Navigation. 20 % der Komponenten decken meist 80 % der Oberflächen ab.
Verantwortlichkeit und Sichtbarkeit sichern
Legt fest, wer über Ergänzungen entscheidet, und macht das System dort sichtbar, wo gearbeitet wird. Ein Design System, das niemand findet, existiert nicht.
Und macht das System dort sichtbar, wo gearbeitet wird: für Redaktionen im CMS, nicht im geteilten Ordner. Ein Design System, das niemand findet, existiert nicht.
Ein Design System war lange ein Effizienzthema. Seine Rolle hat sich verschoben.
Weniger Doppelarbeit, konsistentere Marke, schnelleres Onboarding – diese Argumente gelten weiterhin. 47 % schnellere Umsetzung sind eine belastbare Zahl.
Aber ein Design System ist heute die Schnittstelle, über die Menschen und Maschinen an Eurem digitalen Auftritt arbeiten. Wer KI in Design und Entwicklung nutzt – und das tun mit 68 % die meisten Entwicklungsteams –, braucht diese Grundlage. Sonst entsteht schnell viel, das nicht zusammenpasst.
Design Tokens machen aus dem System eine maschinenlesbare Quelle, für die es mit Version 2025.10 erstmals ein stabiles Format gibt.
Die Reihenfolge entscheidet: Erst die Grundlage, dann die Beschleunigung. Wer das umdreht, skaliert nur die eigene Inkonsistenz.
Wir bauen diese Grundlage seit Jahren für B2B-Unternehmen: von den Foundations in Figma über die Komponentenbibliothek bis zum Living Styleguide in TYPO3, damit Design, Entwicklung und KI mit derselben Quelle arbeiten.
Hier findet Ihr Antworten auf die wichtigsten Fragen rund um Aufbau, Kosten, Werkzeuge und Pflege eines Design Systems.
Es ist keine Frage der Mitarbeitendenzahl, sondern der Anzahl an Berührungspunkten. Sobald mehr als eine Person Inhalte pflegt oder mehr als eine Website, Landingpage oder ein Shop im Spiel ist, entsteht Nutzen. Der Umfang skaliert mit: Kleinere Setups starten mit Foundations und rund 15 Kernkomponenten, große Organisationen mit mehreren Marken brauchen zusätzlich Theming und klare Verantwortlichkeiten.
Das hängt vom Umfang ab. Ein fokussiertes System für eine Corporate Website mit Foundations, Farb-Ranges und Kernkomponenten ist ein klar kalkulierbares Projekt. Multi-Brand-Systeme mit Theming, mehrsprachiger Dokumentation und Anbindung an die Entwicklung liegen deutlich darüber. Entscheidend ist die Gegenrechnung: Was kostet aktuell jede Neuentwicklung eines Moduls, das eigentlich schon existiert?
Wir denken in Sprints von zwei Wochen. Ein solides Basissystem – Audit, Foundations, Farb- und Komponentenstruktur, Kernkomponenten, Dokumentation – verteilt sich erfahrungsgemäß über etwa drei bis vier Sprints. Das ist ein Rahmen, keine Vollzeitauslastung: Wie schnell es tatsächlich geht, hängt vom Umfang, von der Zahl der Marken und Bereiche und vor allem von den Abstimmungsschleifen auf Eurer Seite ab. Wir arbeiten iterativ – die ersten Komponenten sind nutzbar, während weitere entstehen.
Ein Design System ist nicht an ein Tool gebunden. Wir arbeiten mit Figma, weil Variables, Komponenten-Varianten und Bibliotheks-Publishing dort am reifsten zusammenspielen – und weil es der Standard ist, an dem Kund:innen und Entwicklungsteams ohnehin arbeiten. Über das Token-Format bleibt Euer System außerdem portabel.
Sie sind zwei Sichten auf dieselbe Grundlage. Das Design System ist die Quelle in Figma und Code – die Perspektive von Design und Entwicklung. Der Living Styleguide im TYPO3-Backend ist die Redaktionssicht: alle Module beispielhaft eingebaut, mit Anleitung zur Nutzung. Redakteur:innen müssen kein Figma öffnen, um richtig zu arbeiten.
Das Gegenteil ist der Fall. KI generiert Oberflächen umso zuverlässiger, je klarer die Vorgaben sind. Ohne System erzeugt sie plausible, aber beliebige Ergebnisse – und Beliebigkeit ist für eine Marke das Gegenteil von Wiedererkennbarkeit. Das Design System ist der Kontext, der KI-Output verwertbar macht.
Nein, und diese Unterscheidung ist wichtig. Das Design Tokens Format Module ist ein Community Group Report der Design Tokens Community Group beim W3C und durchläuft nicht den formalen W3C-Standardisierungsprozess. Version 2025.10 ist aber die erste als stabil deklarierte Fassung und wird von der relevanten Tool-Landschaft implementiert – praktisch also ein De-facto-Standard.
Ja. Die Kernstruktur ist stabil, und der eigentliche Aufwand liegt nicht im Dateiformat, sondern in der Systematik: Welche Werte gibt es, wie heißen sie, wie sind sie hierarchisch geordnet. Diese Arbeit ist formatunabhängig wertvoll. Ein späterer Export in eine neuere Version ist ein technischer Schritt, keine Neukonzeption.
Durch drei Dinge: eine klar benannte Verantwortlichkeit, einen definierten Prozess für neue Anforderungen und Sichtbarkeit im Arbeitsalltag. Bei uns ist der Design Lead des jeweiligen Kunden die feste Ansprechperson – neue Anforderungen laufen dort zusammen, werden bewertet und, wenn sie systemtauglich sind, in die Bibliothek übernommen. Design Systeme scheitern selten an Technik, sondern fast immer an fehlender Zuständigkeit.
Wir begleiten den gesamten Weg: UI-Audit des Bestands, Aufbau von Foundations und Farb-Ranges in Figma, Komponentenbibliothek mit allen Zuständen, Abstimmung mit der Entwicklung, Umsetzung in TYPO3 und Living Styleguide für die Redaktion. Auf Wunsch übernehmen wir auch die laufende Pflege und Weiterentwicklung – mit einem festen Design Lead als Ansprechperson.
Mit einem UI-Audit. Wir sichten Eure bestehenden Oberflächen, erfassen alle im Einsatz befindlichen Varianten und zeigen auf, wo Inkonsistenzen und Aufwandstreiber liegen. Daraus entsteht eine priorisierte Roadmap – inklusive Aufwandsschätzung für die ersten Ausbaustufen.
Alle im Beitrag genannten Zahlen und Zitate im Überblick.