Zurueck zum Blog
22. Juli 20266 min

DS Bridge: wenn ein Design System für eine AI lesbar wird

ProductUX & DesignInnovation
DS Bridge: wenn ein Design System für eine AI lesbar wird

Das Problem

Seit einem Jahr arbeite ich täglich mit AI-Agenten. Und jeden Tag stoße ich an dieselbe Wand: die AI kennt mein Design System nicht. Ich kann ihr Tokens in einen Prompt kopieren, meine Komponenten beschreiben, erklären, dass der Sekundär-Button eben nicht diesen Radius hat. Sie versteht, im Moment. Dann schließt sich die Session und alles ist wieder zu tun.

Das Problem ist nicht das Modell. Es ist strukturell: das Design System lebt in Figma, und AI-Agenten haben keinen Zugriff darauf. Dazwischen stehe ich, kopiere, formuliere um und verliere bei jeder Iteration den Kontext. Ich habe irgendwann gedacht, dass diese Übersetzungsarbeit nicht mein Beruf ist, sondern der einer Software.

DS Bridge ist daraus entstanden. Es ist eine native Mac- und iPhone-App, die die beiden Welten verbindet, gestützt auf MCP, das Protokoll, das einem Agenten den Zugriff auf externe Quellen ermöglicht. Ziel ist nicht, Screens für mich zu generieren. Es ist bescheidener und nützlicher: die AI meine Sprache sprechen lassen, bevor ich sie überhaupt etwas frage.

Ein Design System ist keine Objektbibliothek. Es ist eine Grammatik. Solange eine AI die Grammatik nicht hat, schreibt sie in einer anderen Sprache.

Wie es funktioniert

Alles beginnt auf dem Mac. Dort wird ein Figma-Design-System ingestiert: Tokens, Komponenten, Styles, Struktur. DS Bridge macht daraus einen sauberen, abfragbaren Kontext, den ein Agent über MCP lesen kann, statt ihn zu erraten.

Dann übernimmt das Telefon, und dort wird das Projekt im Alltag interessant. Eine Screen-Idee kommt selten vor Figma. Sie kommt in der U-Bahn, in einem Meeting, vor dem Interface eines Wettbewerbers. Vom iPhone aus fotografiere oder beschreibe ich, und die App produziert ein strukturiertes Brief, bereits im Vokabular meines Design Systems geschrieben, bereit für Figma.

Generate · funktioniert Ende zu Ende

Aus einem Foto oder einer Beschreibung erzeugt die App ein strukturiertes Brief, das die Tokens und Komponenten des ingestierten Systems respektiert. Kein magischer Screen, sondern eine saubere, kohärente Basis für den Start.

Audit · in Arbeit

Der umgekehrte Weg: einen bestehenden Screen einreichen und prüfen, was vom System abweicht. Hartcodierte Werte, missbrauchte Komponenten, Spacing-Drift. Der Teil, der die meiste Feinheit verlangt, und an dem ich arbeite.

Die Architektur, klar

DS Bridge architecture
Die gestrichelten Blöcke sind die noch nicht fertigen Teile. Das direkte Schreiben in Figma über das Plugin ist das letzte Puzzleteil.

Nativ zu bauen war nicht kosmetisch. Eine plattformübergreifende SwiftUI-App gibt mir denselben Code auf Mac und iPhone, Zugriff auf die Kamera und vor allem den Keychain, um API-Keys lokal zu speichern, ohne dass sie irgendwo hin durchlaufen. Die Sync läuft über ein leichtes Backend, damit das auf dem Mac ingestierte Design System auf dem Telefon verfügbar ist.

  • App · SwiftUI plattformübergreifend, eine Codebasis für Mac und iPhone
  • Sync · Supabase, um dasselbe Design System auf mehreren Geräten wiederzufinden
  • Sicherheit · API-Keys im Keychain, nie in einer Config-Datei
  • AI-Anbindung · MCP-Server, exponiert das Design System als abfragbare Quelle
  • Rückweg Figma · Plugin-Bridge, um das Brief direkt in die Datei zu legen

Was ich beim Bauen gelernt habe

Ein Design System widersetzt sich der Übersetzung. Was in Figma sauber wirkt, entpuppt sich oft als implizit: Konventionen, die das Team kennt, ohne sie geschrieben zu haben, tolerierte Ausnahmen, Komponenten, deren Name nichts über den Einsatz sagt. Ein System maschinenlesbar zu machen, heißt zuerst, all das zu entdecken, was es nicht sagt. Ich habe das bereits an einem Produkt zur optischen Messung erlebt, bei dem zwei visuell identische 3D-Modelle zwei entgegengesetzte Präzisionsstufen versteckten. Das Problem war nicht technisch, es war Namensgebung.

AI braucht keine Kreativität, sie braucht Kontext. Der Unterschied zwischen einem unbrauchbaren Vorschlag und einer soliden Arbeitsbasis kommt fast nie vom Prompt. Er kommt von dem, was das Modell über das System weiß, in dem es arbeitet.

Mobile verändert die Natur des Werkzeugs. Solange es eine Mac-App war, war es ein Utility mehr. An dem Tag, an dem ich einen Screen im Meeting fotografieren und ein strukturiertes Brief zurückbekommen konnte, ist das Werkzeug in meinen echten Alltag eingezogen, den, in dem die Ideen fern vom Schreibtisch entstehen.

Wo ich stehe

Der Generate-Flow funktioniert Ende zu Ende. Audit und direktes Schreiben in Figma sind in Arbeit. Ich baue dieses Projekt, wie ich seit zehn Jahren alles baue: die Fundamente legen, prüfen, ob sie halten, dann erweitern. Und ich tue es mit AI als Coding-Partner, was es mir als Designer erlaubt, bis zum tatsächlich laufenden Produkt zu gehen, statt beim Mockup zu stoppen.

Wenn du an Design Systems oder MCP arbeitest, interessieren mich diese Themen sehr und ich rede gern darüber. Das Projekt geht öffentlich voran, mit seinen unfertigen Teilen offen benannt.