Dein Designsystem ist angebunden. Figma hängt dran, die Komponenten liegen im Code, die Dokumentation ist verlinkt, die Tokens sind exportiert. Die KI kann auf alles zugreifen.
Und trotzdem baut sie Dinge, die nicht stimmen. Eine Komponente, die ihr vor einem Jahr abgelöst habt. Einen Abstand, der in der Datentabelle richtig war und im Formular falsch ist. Eine Farbe, die technisch aus eurem System kommt und semantisch das Gegenteil von dem bedeutet, was gemeint war.
Der Reflex ist dann, noch eine Quelle anzubinden. Das hilft nicht. Das Problem sitzt eine Ebene tiefer: Eure Design-System-Dokumentation beschreibt, was es gibt – aber nicht, was davon wann gilt.
Zugriff ist nicht Verständnis
Ein angebundenes System macht Informationen verfügbar. Ein System, mit dem KI wirklich arbeiten kann, macht deren Bedeutung, Beziehungen, Status und Verbindlichkeit klar genug, dass man sie anwenden kann. Der Unterschied ist der zwischen einem Wörterbuch und sprechen können.
Nimm einen Button. In Figma siehst du die Varianten: primär, sekundär, kritisch. In der Komponentenbibliothek siehst du die Zustände: lädt, deaktiviert. In der Doku stehen Beispiele. Alles da.
Was nirgends steht: Wann ist die kritische Variante die richtige Wahl? Darf sie überhaupt deaktiviert sein? Wie viele primäre Buttons verträgt ein Screen, bevor keiner mehr primär ist? Die KI sieht, dass die Optionen existieren. Warum es sie gibt, sieht sie nicht. Woraus ein Designsystem grundsätzlich besteht, haben wir in Design System: Warum KI ohne Designsystem nur rät auseinandergenommen – hier geht es um die Ebene darüber.
Assets sind nicht Entscheidungen
Ein Designsystem hat zwei Hälften, und die meisten Systeme dokumentieren nur eine davon sauber. Die Assets sind die Komponenten, Tokens und Styles selbst. Die Entscheidungen sind die Regeln, wann und wie sie eingesetzt werden.
Ein Beispiel, das in fast jedem System steckt: Du hast drei Tokens, deren Farbwerte fast identisch aussehen – sekundärer Text, eine Trennlinie, ein deaktiviertes Element. Für ein Modell, das Werte vergleicht, sind das drei Varianten derselben Sache. Für dein System sind es drei Bedeutungen, die sich nie gegenseitig vertreten dürfen.
Dass die drei ähnlich aussehen, ist eine Eigenschaft der Palette. Dass sie nicht austauschbar sind, ist eine Entscheidung. Und die steht nirgends, solange du sie nicht hinschreibst.
Mehr Quellen, mehr Widersprüche
Hier wird es unangenehm. Jede zusätzliche Quelle verbessert die Abdeckung – und legt gleichzeitig eine weitere Version derselben Entscheidung offen.
Der normale Zustand in einem lebenden Projekt sieht so aus: Figma zeigt die neue Struktur. Der Code unterstützt noch die alte Schnittstelle, weil die Migration läuft. Die Doku beschreibt einen Idealzustand, den es so noch nirgends gibt. Und im Produktivsystem stehen Ausnahmen, die damals ihre Berechtigung hatten und die trotzdem niemand kopieren sollte.
Vier Quellen, vier Wahrheiten, kein Hinweis darauf, welche gerade gilt. Ein Modell entscheidet sich in so einer Lage für das, was am häufigsten vorkommt. Und am häufigsten vorkommt fast immer der alte Stand.
Beispiele verallgemeinern falsch
Dazu kommt ein verwandtes Problem. Ein dicht gesetztes Formular in einem internen Werkzeug ist dort genau richtig: viele Felder, Menschen, die täglich damit arbeiten, Effizienz vor Ruhe. Ohne den Vermerk „gilt für interne Werkzeuge, nicht für Kundenoberflächen“ ist das für eine KI schlicht ein Formular-Beispiel aus eurem System. Und dann steht dieselbe Dichte plötzlich im Bezahlformular.
Ein Beispiel ohne Geltungsbereich ist kein Beispiel. Es ist eine Einladung zum Verallgemeinern.
Woher soll die KI wissen, was noch gilt?
Das ist die Lücke, die am meisten kostet. Stell dir eine Komponente vor, die ihr abgelöst habt – nennen wir sie die alte Card. Die neue steht bereit, aber die Migration läuft noch.
Figma enthält beide. Der Code unterstützt beide, weil ältere Produkte nicht umgestellt sind. Die Doku beschreibt die neue. Und im Produktivsystem stehen dreihundert Stellen mit der alten.
Aus Sicht eines Modells, das aus Häufigkeit lernt, ist die alte Komponente die etablierte. Sie kommt öfter vor, sie funktioniert, sie ist überall. Dass sie nicht mehr neu eingesetzt werden soll, steht an keiner Stelle, die maschinell lesbar wäre.
Die Lösung ist unspektakulär: Status explizit machen. Experimentell, unterstützt, stabil, abgelöst. Ein Feld, vier mögliche Werte – und die häufigste Fehlerquelle in KI-gestützter Systemarbeit ist zu.
Wer hat recht, wenn sich Quellen widersprechen?
Die zweite Lücke ist Verbindlichkeit. Es gibt keine Quelle, die für alles die Wahrheit hält, und das ist auch richtig so. Jede weiß etwas anderes am besten:
- Der Code weiß, wie sich etwas zur Laufzeit tatsächlich verhält.
- Figma weiß, welche Struktur freigegeben ist.
- Die Dokumentation weiß, warum eine Entscheidung so gefallen ist.
- Die Tokens kennen die maschinenlesbaren Beziehungen.
- Die Release-Historie weiß, was aktuell unterstützt wird.
Das Ziel ist nicht, alles in eine Datei zu pressen. Das Ziel ist, pro Frage festzulegen, wer entscheidet. Dann löst sich ein Widerspruch durch Nachschlagen statt durch Raten.
Dazu gehört die Zuordnung über Systemgrenzen hinweg. Wenn eine Eigenschaft in Figma anders heißt als im Code, ist das kein Problem – solange irgendwo steht, dass beide dasselbe meinen. Steht es nicht da, behandelt die KI sie als zwei verschiedene Konzepte und baut entsprechend zwei verschiedene Dinge.
Was in eine KI-taugliche Dokumentation gehört
- Zweck: Wofür ist das da, welches Problem löst es?
- Geltungsbereich: Wo gilt es – und wo ausdrücklich nicht?
- Grenzen: Welche Kombinationen sind unterstützt, welche nicht?
- Status: experimentell, unterstützt, stabil oder abgelöst.
- Verbindlichkeit: Welche Quelle entscheidet im Konfliktfall?
- Zuordnung: Wie hängen Design, Code, Doku und Barrierefreiheit an derselben Entscheidung?
Das ist keine neue Dokumentationsgattung. Es ist die Dokumentation, die dir schon immer gefehlt hat – nur dass Menschen die Lücken bisher aus Erfahrung gefüllt haben. Eine KI füllt sie auch. Sie sagt dir nur nicht dazu, dass sie geraten hat.
Wie du diesen Kontext dann im Alltag einsetzt – eingegrenzte Aufgaben, echtes Review, Rückführung ins System – steht in KI Design Workflow: Warum ein guter Prompt nicht reicht.
Dokumentation ist der Skill, der plötzlich zählt
Dokumentation hatte lange den Ruf der Aufgabe, die man macht, wenn alles andere fertig ist. Das hat sich gedreht. Wenn Maschinen mit deinem System arbeiten sollen, ist die Dokumentation kein Anhang mehr. Sie ist die Schnittstelle.
Wer heute gestaltet, braucht deshalb beides: das Handwerk am Interface und die Fähigkeit, Entscheidungen so festzuhalten, dass andere sie anwenden können – Menschen wie Maschinen. Genau darauf zielen unsere Weiterbildungen UI-Designer:in und, wenn du UX und UI zusammen lernen willst, Product-Designer:in.
Beide Weiterbildungen sind AZAV-zertifiziert und mit Bildungsgutschein bis zu 100% förderfähig.
Fazit: Anbinden ist der erste Schritt, nicht der letzte
Zugriff ist die technische Verbindung zu Figma, Code, Dokumentation und Tokens. Verständnis entsteht erst durch die Entscheidungen, die erklären, wie diese Quellen zusammen zu lesen sind.
Ein verbundenes System hat seine Quellen verknüpft. Ein System, mit dem KI arbeiten kann, hat seine Entscheidungen explizit, aktuell und verbindlich gemacht. Der Weg dahin führt nicht über die nächste Integration, sondern über zwei unbequeme Fragen: Was gilt hier eigentlich noch? Und wer entscheidet das?
Du willst lernen, Systeme so aufzubauen? Meld dich für deine kostenlose Erstberatung – wir finden gemeinsam die passende Weiterbildung. Let's grow!
