Aktualisiert 15. Juli 2026

Design Tokens sind die Schnittstelle zwischen Design und KI

Design Tokens funktionieren als Schnittstelle zwischen Design und KI, weil sie Designentscheidungen als Daten speichern: Jedes Token verbindet einen Namen — accent, space-4 — mit genau einem Wert, in einer Datei, die beide Seiten lesen können. Die KI wird zu einem weiteren Konsumenten derselben Quelle, die bereits CSS, Figma und nativen Code speist; statt zu raten, was dein Design beabsichtigt, liest sie es einfach ab.

Dieser Satz trägt drei Behauptungen — Tokens sind ein Vertrag, die KI ist ein Konsument, und das Referenzieren ist das, was die KI-Ausgabe steuerbar macht — und dieser Artikel, das konzeptionelle Stück unseres Leitfadens zu KI und Design-Systemen, nimmt sie eine nach der anderen vor.

Was macht eine Token-Datei zu einem Vertrag?

Ein Vertrag im Software-Sinne des Wortes: eine Vereinbarung über Namen, die es zwei Seiten erlaubt, sich unabhängig voneinander zu ändern. Die Namen sind stabil; die Werte dahinter können sich ändern. Die Design-Seite kann frei ändern, was accent speichert — ein Rebrand, ein saisonales Theme, eine Dark-Variante — und jeder Konsument, der den Namen referenziert hat, aktualisiert sich, ohne angefasst zu werden. Die Konsumenten-Seite kann accent an tausend Stellen verwenden, ohne den Wert dahinter zu besitzen oder auch nur zu kennen.

Das funktioniert nur, weil Tokens Entscheidungen sind, die als Daten gespeichert werden — unsere Einführung in Design Tokens baut diese Idee von Grund auf auf. Ein PDF-Styleguide formuliert dieselben Entscheidungen für einen menschlichen Leser; eine Token-Datei formuliert sie in einer Form, mit der ein Build-Schritt, ein Design-Tool oder ein Sprachmodell etwas anfangen kann. In dem Moment, in dem eine Entscheidung einen maschinenlesbaren Namen hat, kann alles, was Dateien liest, sie berücksichtigen.

Warum ist die KI nur ein weiterer Konsument?

Weil die Liste der Konsumenten schon immer offen war. Eine Token-Quelle wurde nie direkt konsumiert: Stylesheets konsumieren einen generierten Satz von Custom Properties, Figma konsumiert generierte Variables, native Plattformen konsumieren generierte Ressourcen. Jeder Konsument bekommt eine Darstellung derselben Entscheidungen in dem Format, das er am besten liest. Ein KI-Coding-Tool reiht sich ohne Umstände in diese Liste ein — es liest, welche Darstellung auch immer im Repository liegt, meist die CSS Custom Properties oder ein Tailwind-Theme; das Setup selbst behandelt wie du einem KI-Coding-Tool dein Design-System gibst.

Dafür musste nichts KI-Spezifisches erfunden werden: kein neues Format, kein Plugin, kein Protokoll. Dieselbe Datei, die der DTCG-Formatspezifikation für den Austausch zwischen Design-Tools folgt, ist aus Sicht des Modells auch einfach lesbarer Kontext. Die Disziplin, die die Branche eingeführt hat, um Design-Dateien und ausgelieferten Code in Übereinstimmung zu halten, überträgt sich unverändert auf den neuesten Teilnehmer.

Was ermöglicht „Referenz, nicht Wert”?

Steuerbarkeit. Wenn ein Modell einen Rohwert in eine Komponente schreibt, ist dieser Wert die Momentaufnahme einer Vermutung — plausibel zum Zeitpunkt der Generierung, danach von allem abgekoppelt. Wenn es eine Referenz schreibt, bleibt die Ausgabe an die Quelle gebunden. Daraus folgen zwei Konsequenzen, eine für jede Richtung der Zeit:

  • Rückwärts: Vergangene Ausgabe bleibt korrekt. Code, den die KI im März generiert hat, sagt immer noch --color-accent; ändere im September, was das Token speichert, und dieser Code stellt die neue Entscheidung dar, ohne noch einmal angefasst zu werden.
  • Vorwärts: Die Generierung wird begrenzt. Bittet man ein Modell, eine Farbe zu wählen, wählt es aus einem praktisch unbegrenzten Raum plausibler Werte. Bittet man es, eine Rolle aus einer Datei in seinem Kontext zu wählen, wählt es aus einem Dutzend sichtbarer Namen. Jeden Wert zu prüfen, den ein Generator erfindet, skaliert nicht; von ihm zu verlangen, keinen zu erfinden, schon.

Öffne die DTCG-Datei, die Scale Composer generiert, um den Vertrag in seiner rohen Form zu sehen — primitive Tokens, die exakte OKLCH-Werte halten, und semantische Rollen wie background, text und accent, die sie referenzieren, statt sie zu wiederholen. Die Referenz-Syntax ist die ganze Idee in einer Zeile JSON.

Eine DTCG-Design-Tokens-Datei in Scale Composer, die semantische Rollen zeigt, die primitive Farbwerte referenzieren

Was passiert, wenn sich eine Entscheidung ändert?

Sie propagiert — das ist der Gewinn davon, Entscheidungen an einem Ort zu halten. In Scale Composer treibt eine einzige globale Skala (Basis, Ratio, Schritte) die Farbrampen, die Schriftgrößen und die Raster-Abstände gemeinsam an, und die semantischen Rollen werden aus den Rampen mit einer Kontrast-Untergrenze abgeleitet. Ändere einen Parameter, und alles Nachgelagerte leitet sich neu ab; jeder Export — DTCG, CSS Custom Properties, Tailwind-Theme, Figma Variables — trägt die Änderung, weil jeder eine Darstellung desselben Zustands ist.

Für einen KI-Konsumenten bedeutet das: Korrektur hat eine einzige Adresse. Wenn sich die Markenfarbe verschiebt, promptest du nicht jeden Screen neu, den das Modell je erzeugt hat; du änderst die Quelle, und die nächste Generierung — zusammen mit jeder Darstellung vergangener Generierungen — liest die neue Antwort über dieselben Namen.

Warum passt diese Aufteilung sowohl zu Menschen als auch zu Maschinen?

Für die Maschinen ergänzen sich die beiden Hälften. Ein generatives Modell ist stark bei Struktur, Komposition und Variation und schwach darin, viele exakte Werte stabil zu halten, weil jede Antwort frisch gesampelt wird. Eine Token-Datei ist das Spiegelbild: Sie hält Werte exakt und generiert nichts. Jede ist die fehlende Hälfte der anderen, weshalb das Paar besser funktioniert als jede Seite für sich.

Für die Menschen ist das Argument perzeptiv. Menschen lernen eine Oberfläche durch Wiederholung: Ein Button, den man fünfmal mit identischer Farbe und Schriftstärke sieht, kostet keine Aufmerksamkeit mehr, und diese Wiedererkennung entsteht daraus, dass Signale gleich sind, nicht bloß ähnlich. Ein Konsument, der Werte abliest, führt nie fast-identisches Rauschen ein; ein Konsument, der sie aus dem Gedächtnis abruft oder rät, tut es früher oder später immer. Der Vertrag ist mit anderen Worten keine Bürokratie — er ist der Grund, warum die Oberfläche wiedererkennbar bleibt, während ein unbegrenzter Generator an ihr arbeitet.

Sieh den Vertrag in Bewegung

Die Schnittstellen-Behauptung lässt sich am leichtesten spüren, indem man eine Seite von ihr verändert: öffne die globale Skala in Scale Composer und verschiebe die Ratio um einen Schritt. Die Schriftgrößen, Abstands-Schritte und Rampen leiten sich neu ab; die Namen bleiben stehen. Werte in Bewegung unter stabilen Namen — das ist der Vertrag bei der Arbeit — und der Grund, warum eine KI, die diese Namen liest, markenkonform bleibt, selbst während sich das Design darunter weiterentwickelt.

Weiterlesen

  • Was sind Design Tokens?

    Was sind Design Tokens? Benannte Design-Entscheidungen — brand-600 enthält genau ein Blau — über Referenzen zusammengesetzt und nach CSS, Figma und nativen Code exportiert.

  • Warum KI-generierte Interfaces vom Markendesign abdriften

    KI-Design-Konsistenz scheitert, weil ein Modell jede Antwort neu auswürfelt. Warum das Abdriften vom Markendesign der Normalfall ist – und wie eine feste Token-Quelle es stoppt.

  • So gibst du einem KI-Coding-Tool dein Design-System

    Cursor Design-System einrichten: Exportiere deine Tokens als CSS-Variablen oder Tailwind-Theme, lege die Datei ins Repo und lass die KI Rollen beim Namen referenzieren.