Ersetzt das den Designer?

Nein. Der Agent übernimmt die repetitive Produktionsarbeit — Varianten und Zustände erzeugen. Der Designer definiert das System, schreibt den Prompt, prüft jedes Ergebnis und trifft die Entscheidungen. Ziel ist mehr Zeit für Problemlösung, nicht weniger Design-Verantwortung.

Wie wird die Qualität gesichert?

Durch drei Regeln: Der Code-Prototyp ist die einzige Quelle der Wahrheit; alles, was der Agent erzeugt, wird vom Designer gegen den Prototyp geprüft, mit Engineering als zweitem Blick auf das Datenmodell; Korrekturen laufen über den Prompt und Neuerzeugung, nicht über manuelles Nachzeichnen. Der Prompt selbst folgt einer Checkliste: Ort im Design-File, Kontext, Ausgabebeispiele, Varianten-Hinweise.

Muss das Designteam dafür programmieren können?

Nicht zwingend, aber es hilft, wenn mindestens eine Person im Team sich im Code zurechtfindet. In diesem Case hat der Lead Product Designer den Prototyp selbst gelesen und mitgestaltet, damit Design und Implementierung nah beieinander bleiben. Für die anderen Designer wurde der Workflow in einer Guideline und einem Video festgehalten.

Funktioniert das mit unserem bestehenden Designsystem in Figma?

Der Ansatz wurde in einem ausgereiften, realen B2B-Designsystem eingeführt, nicht auf der grünen Wiese. Voraussetzung ist, dass die Komponente eine saubere Quelle hat — einen Prototyp oder eine Implementierung mit klarer Zustandslogik — und dass die Matrix der Varianten vorher definiert ist. Dann lässt sich derselbe Weg auf weitere Komponenten und weitere Achsen wie Marken, Themes oder Plattformen übertragen.

Welche Werkzeuge kamen zum Einsatz, und sind wir daran gebunden?

Cursor als Entwicklungsumgebung, in der der Agent läuft; MCP als Schnittstelle, über die der Agent Komponenten in Figma anlegt; Figma als Design-File. Die Werkzeuge sind austauschbar — die Arbeitsweise (Quelle der Wahrheit, Prompt-Checkliste, Review durch den Designer) ist das, was bleibt.

Wird der Hersteller oder das Produkt genannt?

Nein. Die Plattform und die Komponente werden bewusst generisch beschrieben, und es werden keine Produktdetails über das hinaus genannt, was bereits öffentlich dokumentiert ist. Die Arbeit entstand in Festanstellung; die Beabstracto bringt die Arbeitsweise zu Kunden, nicht das Material des Arbeitgebers.

Enterprise-Software · Dokumentenmanagement · Designsystem in Figma

Jede Variante einer B2B-Komponente in Figma — erzeugt vom KI-Agenten, geprüft vom Designer.

Für den Hersteller einer Enterprise-Plattform für Dokumentenmanagement und Workflows haben wir die Varianten- und Zustandsmatrix einer konfigurierbaren Komponente nicht mehr von Hand gezeichnet, sondern aus dem Code-Prototyp heraus per Agent in Figma erzeugen lassen. Der Designer entwirft das System, schreibt den Prompt und prüft das Ergebnis; der Agent übernimmt die Produktion. Code und Designsystem bleiben synchron.

Erstgespräch vereinbaren Wie wir vorgegangen sind

Zwei App-Icons auf schwarzem Grund: links ein Code-Editor mit KI-Agent, rechts Figma — sie stehen für die automatisierte Brücke vom Code ins Design-File

Kunde: Hersteller einer Enterprise-Plattform für Dokumentenmanagement und Workflows (in Festanstellung)
Branche: Enterprise-Software · DMS/ECM · Workflow-Automatisierung
Rolle: Lead Product Designer, code-curious: Systemdesign, Prototyp im Code, Prompting, Review, Übergabe
Zeitraum: B. 2025]]
Systeme: Figma · Cursor · MCP (Model Context Protocol) · Code-Prototyp der Komponente
Team: Lead Product Designer, Engineering, Junior-Designteam für den Feinschliff

Kurz gesagt

Beim Hersteller einer Enterprise-Plattform für Dokumentenmanagement und Workflow-Automatisierung brauchte eine konfigurierbare Workflow-Komponente in Figma jede Kombination aus vier Quelltypen, vier Zieltypen und mehreren Interaktionszuständen. Statt diese Matrix von Hand zu zeichnen, haben wir in Festanstellung als Lead Product Designer einen agentischen Workflow aufgesetzt: Der Code-Prototyp ist die einzige Quelle der Wahrheit, ein KI-Agent in Cursor erzeugt über eine MCP-Brücke das Komponenten-Set mit allen Varianten und Zuständen in Figma, der Designer schreibt den Prompt und prüft jedes Ergebnis. Die repetitive Produktionsarbeit entfällt, Code und Designsystem bleiben synchron.

Für Produktteams in Enterprise-Software ist das relevant, weil fast jede komplexe Komponente eine solche Matrix ist: Konfigurationen, Zustände, später auch Marken, Themes und Plattformen. Wer sie von Hand pflegt, verliert Designerzeit an Duplikation und riskiert, dass Figma und Code auseinanderdriften. Dieser Case zeigt, welche Schritte ein Agent zuverlässig übernimmt, wo der Mensch bleibt und wie die Qualität gesichert wird.

Zahlen

Die Zahlen beschreiben den Umfang der Varianten-Matrix, wie er in der Case-Dokumentation festgehalten ist. Eine Zeitmessung „vorher/nachher“ gab es im Projekt nicht; wir schätzen sie bewusst nicht.

4 × 4
Quelltypen × Zieltypen — jede Kombination verändert die Steuerelemente der Zeile: 5
Zustände je Kombination: gefüllt, leer, Fehler, Dropdown offen, beim Ziehen: 1
Quelle der Wahrheit: der Code-Prototyp, aus dem Figma abgeleitet wird

Ausgangslage

Was war die Ausgangslage? Eine ausgereifte Enterprise-Plattform mit einem etablierten Designsystem — und eine einzelne Komponente, die sich mit jeder Auswahl verändert.

Die Arbeit entstand in Festanstellung als Lead Product Designer beim Hersteller einer Enterprise-Plattform für Dokumentenmanagement und Workflow-Automatisierung. Produkte dieser Art werden von Fachabteilungen und Administratoren konfiguriert, nicht programmiert: Ein einzelner Dialog muss Dutzende Konfigurationspfade abbilden, und das Designsystem muss jeden davon kennen, damit Produktmanagement, Design und Engineering über dasselbe Bild sprechen.

Die Oberfläche in diesem Case ist ein Konfigurationsdialog im Workflow-Designer, mit dem Daten aus einer Quelle einem Zielfeld zugewiesen werden. Sein Kernbaustein ist eine konfigurierbare Zeile, die wir hier AssignmentRow nennen: eine Reihe von Dropdowns, die festlegt, woher ein Wert kommt und wohin er geschrieben wird. Wer als Quelle einen Ausdruck wählt, bekommt ein Eingabefeld für die Formel; wer ein Dialogfeld wählt, bekommt eine Auswahlliste; wer einen Festwert wählt, bekommt ein Textfeld. Die Komponente steht also nie still — je nach Auswahl erscheinen weitere Dropdowns, Optionen ändern sich, neue Zustände tauchen auf.

Für das Designsystem ist das der klassische Fall einer Varianten-Matrix. In B2B-Designsystemen kommen solche Achsen regelmäßig vor: Konfigurationen wie hier, Zustände, Dichtestufen, Marken, Themes und Plattformen. Jede Achse multipliziert die Zahl der Frames, die jemand in Figma anlegen, benennen und pflegen muss. Bei dieser Komponente waren es vier Quelltypen, vier Zieltypen und mehrere Interaktionszustände — genug, um die manuelle Pflege zur Dauerbeschäftigung zu machen.

Gleichzeitig existierte die Komponente bereits im Code: als Prototyp mit einer sauberen Zustandslogik, aus der sich jede Variante ableiten lässt. Das war der entscheidende Ausgangspunkt. Es gab eine Quelle der Wahrheit; sie lag nur nicht in Figma, sondern im Code. Die Frage war, wie das Designsystem davon profitiert, ohne dass jemand die Logik ein zweites Mal von Hand nachzeichnet.

Was die Beabstracto aus dieser Arbeit für Kunden mitnimmt: die Erfahrung, ein agentisches Werkzeug in ein reales, ausgereiftes Designsystem einzuführen — mit Review-Verantwortung beim Designer, mit Engineering als Partner und mit einer Übergabe, die ein Junior-Team weiterführen kann.

Das Problem

Was war das Problem? Jede Variante und jeden Zustand dieser Komponente von Hand zu entwerfen, war langsam, repetitiv und skalierte nicht — und mit jeder Änderung am Produkt begann die Arbeit von vorn.

Eine Matrix, keine Bildschirmseite
AssignmentRow ist keine einzelne Ansicht, sondern eine Matrix. Jeder Quelltyp rendert ein anderes Steuerelement, und jede Kombination mit einem Zieltyp hat eigene Zustände: gefüllt, leer, Fehler, Dropdown offen, Zeile beim Ziehen. Wer das vollständig abbilden will, zeichnet Dutzende Frames für eine einzige Zeile.
Mechanische Arbeit statt Entscheidungen
Das Duplizieren, Umbenennen und Nachpflegen von Varianten in Figma ist genau die manuelle Arbeit, die Designerzeit frisst, ohne eine Produktentscheidung zu verbessern. Das Team sollte seine Zeit in Problemlösung investieren, nicht in Duplikation.
Figma und Code driften auseinander
Sobald die Komponente im Code weiterentwickelt wird, stimmt das Design-File nicht mehr. Dann diskutieren Produktmanagement, Design und Engineering über unterschiedliche Bilder derselben Komponente — und die Abstimmung kostet mehr als die Änderung selbst.
Nur ein Beispiel von vielen
Diese Komponente ist eines von vielen komplexen Datenmodellen und Konfigurationsmustern, mit denen B2B-SaaS-Produkte arbeiten. Eine Lösung, die nur für diese eine Zeile funktioniert, hätte wenig Wert. Gesucht war eine Arbeitsweise, die sich auf jede komplexe Komponente übertragen lässt.
Prompting aus dem Bauchgefühl
Erste Versuche mit KI-Werkzeugen scheitern typischerweise nicht am Werkzeug, sondern am Auftrag: zu wenig Kontext, kein klarer Ort im Design-File, keine Beispiele für die erwartete Struktur. Ohne eine wiederholbare Art, den Agenten zu briefen, bleibt das Ergebnis Glückssache.

Wie wir vorgegangen sind

Wie sind wir vorgegangen? Mit einem agentischen Workflow in Cursor und einer MCP-Brücke nach Figma — und mit einer klaren Arbeitsteilung: Der Mensch entwirft das System, schreibt den Prompt und prüft; der Agent erzeugt. Drei Rollen, sauber getrennt: der KI-Agent, der die Arbeit macht und mit dem man über den Prompt spricht; Cursor, die Entwicklungsumgebung, in der der Agent läuft; und MCP, die Schnittstelle, über die der Agent Komponenten in Figma anlegt und aktualisiert.

1
System entwerfen: die Komponente als Matrix definieren
Bevor ein Agent etwas erzeugt, muss klar sein, was erzeugt werden soll. Wir haben die Komponente mit ihren Varianten und Zuständen als eine Quelle der Wahrheit definiert — nicht als Sammlung einzelner Screens. Die Zustandsmatrix wurde aus dem Code-Prototyp abgeleitet: zwei Dropdowns steuern jede Variation, der Quelltyp tauscht das Steuerelement der Quelle, der Zieltyp verändert die Optionen des Ziels. Diese Struktur ist die Grundlage für alles Weitere, auch für die Dokumentation in Figma. Verantwortlich: der Designer, im Austausch mit Engineering.
2
Basiskomponente aus dem Prototyp nach Figma übertragen
Der Agent erzeugt über die MCP-Brücke die Basiskomponente in Figma — gezogen aus dem Prototyp im Code, gesteuert aus Cursor. Sie startet als eine einzige Variante. Dieser Schritt ist klein, aber entscheidend: Er stellt sicher, dass Figma von Anfang an dieselbe Struktur hat wie der Code, statt eine Nachzeichnung davon. Verantwortlich: der Agent; der Designer prüft Struktur und Benennung.
3
Den Prompt schreiben — und als Checkliste festhalten
Der Prompt ist der eigentliche Auftrag. Vier Dinge haben sich als entscheidend erwiesen: den Link auf die Figma-Datei oder den konkreten Abschnitt mitgeben, damit der Agent genau weiß, wo er arbeitet; so viel Kontext wie möglich über die Komponente und ihr Verhalten vorab liefern; Ausgabebeispiele beilegen, damit das Ergebnis die beabsichtigte Struktur trifft; und Hinweise zu den Varianten und Zuständen geben, die erzeugt werden sollen. Diese vier Punkte überführen wir in eine wiederverwendbare Guideline für andere Designer — ehrlich gesagt ein Work in Progress, mit noch viel Bauchgefühl. Verantwortlich: der Designer.
4
Alle Varianten in einem Durchlauf erzeugen lassen
Der Agent bildet sämtliche Varianten und Zustände der Komponente auf einmal ab — in einem einzigen Komponenten-Set in Figma, generiert aus dem Prototyp und unter Einhaltung des Datenmodells des Projekts. Er baut nichts von Grund auf neu, sondern leitet ab. Die Figma-Seite „States & Variations“ dokumentiert das Ergebnis so, dass es prüfbar bleibt: Je Abschnitt wird eine Dimension variiert, die andere konstant gehalten, damit der Unterschied isoliert sichtbar ist. Verantwortlich: der Agent.
5
Prüfen: alles, was der Agent erzeugt, geht durch den Designer
Der Agent liefert, der Mensch verantwortet. Jedes erzeugte Komponenten-Set wird vom Designer gegen den Prototyp geprüft: Stimmen die Steuerelemente je Quelltyp, sind die Zustände vollständig, passt die Struktur des Sets zum Designsystem, sind Benennung und Anordnung so, dass das Team damit arbeiten kann? Was nicht passt, wird im Prompt korrigiert und neu erzeugt — nicht von Hand nachgezeichnet, sonst bricht die Quelle der Wahrheit. Verantwortlich: der Designer, mit Engineering als zweitem Blick auf das Datenmodell.
6
Rahmen, übergeben, vervielfältigen
Die geprüfte Arbeit wurde gerahmt und an ein Junior-Designteam für den Feinschliff übergeben, zusammen mit der Prompt-Guideline und dem kurzen Prozess-Video, das den Weg von der Einzelvariante zur vollständigen Matrix zeigt. So wird der Workflow unabhängig von einer Person und lässt sich auf die nächste komplexe Komponente anwenden. Verantwortlich: der Lead Product Designer.

Figma-Seite „AssignmentRow — States & Variations“: untereinander liegende Zeilen mit je vier Dropdowns, jede Zeile zeigt einen anderen Quelltyp — Dialogfeld, Dokumentindex, Ausdruck gefüllt, Ausdruck leer mit Fehler, Aktenschrank, Festwert — bei konstantem Ziel — Die Dokumentationsseite in Figma, erzeugt aus dem Prototyp: pro Abschnitt wird eine Dimension variiert, die andere bleibt konstant. So lässt sich jede Variante gegen den Code prüfen.

Ergebnis

Was war das Ergebnis? Kein auffälliges Werkzeug, sondern eine Arbeitsweise: Die repetitive Variantenarbeit ist automatisiert, das Designsystem bleibt konsistent, und der Prototyp hält mit dem Produkt Schritt — weil Design und Code eine gemeinsame Brücke haben.

Aspekt	Vorher	Nachher
Varianten und Zustände anlegen	Jede Kombination aus Quelltyp, Zieltyp und Zustand von Hand in Figma gezeichnet, dupliziert und benannt	Der Agent erzeugt das vollständige Komponenten-Set in einem Durchlauf aus dem Prototyp
Quelle der Wahrheit	Verstreute Screens; Figma und Code beschreiben dieselbe Komponente unterschiedlich	Der Code-Prototyp ist die einzige Quelle; Figma wird daraus abgeleitet
Rolle des Designers	Produktion: duplizieren, nachpflegen, angleichen	System entwerfen, Prompt schreiben, Ergebnis prüfen, Entscheidungen treffen
Änderung an der Komponente	Nacharbeit in allen betroffenen Frames, oft mit Verzögerung	Prompt anpassen, neu erzeugen lassen, prüfen
Wissen über das Briefing des Agenten	Bauchgefühl, von Versuch zu Versuch	Vier-Punkte-Checkliste als Guideline für andere Designer (in Arbeit)
Übergabe an das Team	Wissen bei einer Person	Gerahmte Arbeit plus Guideline und Prozess-Video für ein Junior-Team

Für Designer: Zeit für Entscheidungen
Die mechanische Arbeit — Frames duplizieren, Zustände nachziehen, Benennungen angleichen — entfällt. Was bleibt, ist die anspruchsvolle Arbeit: das System sauber definieren, den Agenten präzise briefen, das Ergebnis kritisch prüfen.
Für Engineering: ein Design-File, das dem Code entspricht
Weil Figma aus dem Prototyp abgeleitet wird und das Datenmodell des Projekts respektiert, diskutiert das Team über dieselbe Komponente. Das Designsystem ist etwas, das Engineering tatsächlich bauen und pflegen kann — nicht eine Interpretation davon.
Für das Designsystem: eine governte Matrix
Eine komplexe, konfigurierbare Komponente wird als Komponenten-Set mit klar benannten Varianten und Zuständen geführt — eine Quelle der Wahrheit statt verstreuter Bildschirmseiten. Das ist die Grundlage, auf der auch weitere Achsen wie Marken oder Themes sauber bleiben.
Für das Team: ein übertragbarer Workflow
Derselbe Ansatz funktioniert für jede komplexe Komponente. Prompt-Guideline, Prozess-Video und die Übergabe an ein Junior-Team machen die Arbeitsweise unabhängig von einer einzelnen Person.
Ehrlich: Produktivität hat einen Preis
Der Einsatz von KI-Agenten kostet Geld — Rechenzeit und Lizenzen. Die Rechnung geht auf, wenn die gewonnene Zeit in Problemlösung und Produktentscheidungen fließt, nicht in noch mehr Produktion.

Was wir gelernt haben

01
Erst die Quelle der Wahrheit, dann der Agent
Automatisierung multipliziert, was schon da ist — auch Unordnung. Der Workflow hat funktioniert, weil die Komponente im Code als Prototyp mit sauberer Zustandslogik existierte und die Matrix vorher definiert war. Wer mit dem Agenten beginnt, bevor das System definiert ist, bekommt schnell viele Frames und wenig Konsistenz. Für Designsystem-Teams heißt das: Zuerst klären, wo die Wahrheit liegt — im Code, in Tokens oder in Figma — und erst dann automatisieren.
02
Der Prompt ist ein Briefing, kein Zauberspruch
Vier Dinge entscheiden über das Ergebnis: der Ort im Design-File, der Kontext zur Komponente und ihrem Verhalten, Ausgabebeispiele für die erwartete Struktur und Hinweise zu den gewünschten Varianten. Das ist dieselbe Disziplin wie ein gutes Briefing an einen neuen Kollegen. Wir halten diese Punkte als Guideline fest, damit andere Designer nicht bei null anfangen — und sagen offen, dass sie noch wächst.
03
Der Agent produziert, der Mensch verantwortet
Alles, was der Agent erzeugt, geht durch die Review des Designers, mit Engineering als zweitem Blick auf das Datenmodell. Korrekturen passieren im Prompt und durch Neuerzeugung, nicht durch Nachzeichnen von Hand — sonst entsteht wieder eine zweite Wahrheit. Diese Regel ist der eigentliche Qualitätsmechanismus, nicht das Werkzeug.
04
In Systemen denken schlägt schneller klicken
Der Gewinn kam nicht aus einem besseren Figma-Plugin, sondern daraus, die Komponente als Matrix und das Designsystem nach atomaren Prinzipien zu denken. Wer die Prinzipien kennt, kann dem Agenten präzise sagen, was er bauen soll — und erkennt sofort, wenn das Ergebnis vom System abweicht.
05
Übergeben, bevor es fertig ist
Die Arbeit wurde gerahmt und an ein Junior-Team übergeben, als der Workflow lief, nicht als er perfekt war. Mit Guideline und Prozess-Video konnte das Team den Feinschliff übernehmen und den Ansatz auf weitere Komponenten anwenden. Für Kunden der Beabstracto bedeutet das: Wir bauen Arbeitsweisen, die im Team bleiben, nicht Abhängigkeiten von einem externen Berater.

Was wir geliefert haben

Definition der Komponente als Varianten- und Zustandsmatrix (Quelltyp × Zieltyp × Zustand)
Code-Prototyp der Komponente als einzige Quelle der Wahrheit
Agentischer Workflow in Cursor mit MCP-Brücke nach Figma
Komponenten-Set in Figma mit allen Varianten und Zuständen, aus dem Prototyp erzeugt
Figma-Dokumentationsseite „States & Variations“ mit isolierten Dimensionen je Abschnitt
Prompt-Vorlagen mit den vier Pflichtbestandteilen (Link, Kontext, Beispiele, Varianten-Hinweise)
Prompt-Guideline für Designer (Work in Progress)
Review-Routine: Prüfung jedes erzeugten Sets gegen den Prototyp, Korrektur über den Prompt
Kurzes Prozess-Video von der Einzelvariante zur vollständigen Matrix
Gerahmte Übergabe an ein Junior-Designteam für den Feinschliff

Häufige Fragen

Ersetzt das den Designer?: Nein. Der Agent übernimmt die repetitive Produktionsarbeit — Varianten und Zustände erzeugen. Der Designer definiert das System, schreibt den Prompt, prüft jedes Ergebnis und trifft die Entscheidungen. Ziel ist mehr Zeit für Problemlösung, nicht weniger Design-Verantwortung.
Wie wird die Qualität gesichert?: Durch drei Regeln: Der Code-Prototyp ist die einzige Quelle der Wahrheit; alles, was der Agent erzeugt, wird vom Designer gegen den Prototyp geprüft, mit Engineering als zweitem Blick auf das Datenmodell; Korrekturen laufen über den Prompt und Neuerzeugung, nicht über manuelles Nachzeichnen. Der Prompt selbst folgt einer Checkliste: Ort im Design-File, Kontext, Ausgabebeispiele, Varianten-Hinweise.
Muss das Designteam dafür programmieren können?: Nicht zwingend, aber es hilft, wenn mindestens eine Person im Team sich im Code zurechtfindet. In diesem Case hat der Lead Product Designer den Prototyp selbst gelesen und mitgestaltet, damit Design und Implementierung nah beieinander bleiben. Für die anderen Designer wurde der Workflow in einer Guideline und einem Video festgehalten.
Funktioniert das mit unserem bestehenden Designsystem in Figma?: Der Ansatz wurde in einem ausgereiften, realen B2B-Designsystem eingeführt, nicht auf der grünen Wiese. Voraussetzung ist, dass die Komponente eine saubere Quelle hat — einen Prototyp oder eine Implementierung mit klarer Zustandslogik — und dass die Matrix der Varianten vorher definiert ist. Dann lässt sich derselbe Weg auf weitere Komponenten und weitere Achsen wie Marken, Themes oder Plattformen übertragen.
Welche Werkzeuge kamen zum Einsatz, und sind wir daran gebunden?: Cursor als Entwicklungsumgebung, in der der Agent läuft; MCP als Schnittstelle, über die der Agent Komponenten in Figma anlegt; Figma als Design-File. Die Werkzeuge sind austauschbar — die Arbeitsweise (Quelle der Wahrheit, Prompt-Checkliste, Review durch den Designer) ist das, was bleibt.
Wird der Hersteller oder das Produkt genannt?: Nein. Die Plattform und die Komponente werden bewusst generisch beschrieben, und es werden keine Produktdetails über das hinaus genannt, was bereits öffentlich dokumentiert ist. Die Arbeit entstand in Festanstellung; die Beabstracto bringt die Arbeitsweise zu Kunden, nicht das Material des Arbeitgebers.