Designübergabe: Wie man Figma an Entwickler übergibt, ohne das Design zu verlieren

Die meisten Designübergaben verlaufen nach demselben Muster: Der Designer liefert eine Figma-Datei. Der Entwickler öffnet sie, stellt drei Fragen, erhält zwei Antworten und beginnt mit einer Annäherung. Zwei Wochen später entspricht das ausgelieferte Produkt nur zu 80 % dem Entwurf, der Designer ist verärgert, der Entwickler reagiert defensiv, und der Projektmanager bezeichnet die Abweichung als „Iteration“. An diesem Workflow hat sich in den letzten zehn Jahren nichts verbessert.

Dieser Leitfaden ersetzt diesen Workflow. Eine echte Übergabe im Jahr 2026 ist ein System, kein Meeting. Die Figma-Dateistruktur verhindert Mehrdeutigkeiten, die Token-Disziplin macht das Design maschinenlesbar, die FigmaMCP-Verbindung ermöglicht es Codierungsagenten, das Design direkt zu lesen, und der Review-Loop deckt Abweichungen auf, bevor das Produkt ausgeliefert wird.

Was ist ein Design-Handoff wirklich?

Ein Design-Handoff ist der Moment, in dem ein Design in implementierbaren Code umgewandelt wird. Alles davor ist Design, alles danach Entwicklung. Der Handoff bildet die Schnittstelle zwischen den beiden Systemen und steht und fällt damit, wie maschinenlesbar das Design ist.

Die alte Definition (ein Meeting, in dem der Designer den Entwickler durch die Datei führt) hat sich als Fehlschlag erwiesen. Solche Walkthroughs sind nicht skalierbar, überstehen Personalwechsel nicht und entsprechen nicht den tatsächlichen Bedürfnissen der Entwickler. Die Definition von 2026 ist anders. Der Handoff ist das strukturierte Artefakt, das es einem Entwickler (oder einem Agenten) ermöglicht, das Design umzusetzen, ohne jemanden nach den ursprünglichen Absichten fragen zu müssen.

Dieses Artefakt befindet sich in der Datei. Die Qualität der Datei bestimmt die Qualität des Handoffs. Es gibt kein separates Handoff-Dokument, kein kommentiertes PDF, kein Briefing, das die Lücken füllt. Die Datei ist das Briefing.

Die vierschichtige Figma-Datei für die Übergabe

Eine für die Übergabe vorbereitete Figma-Datei ist in vier Schichten strukturiert. Fehlt eine Schicht, muss der Entwickler raten. Sind alle vier Schichten vorhanden, hat der Entwickler (oder der KI-Agent) keine weiteren Fragen mehr.

Schicht 1: Tokens

Tokens sind die Grundlage für alle Werte im Design. Farbe, Abstände, Typografie, Radius, Schatten, Bewegung. Jeder sichtbare Wert in jeder Komposition lässt sich auf ein Token zurückführen.

Tokens befinden sich in Figma-Variablen (oder im Tokens Studio, falls Ihr Team den älteren Workflow verwendet). Sie werden semantisch, nicht visuell benannt. color/background/primary, nicht gray-50. spacing/lg, nicht 24px. Semantische Namen bleiben auch nach einer Überarbeitung erhalten. Wörtliche Namen führen zu Problemen, sobald jemand den Wert ändert.

Eine Übergabedatei ohne Tokens ist eine Datei, in der jeder Entwickler unzählige Mikroentscheidungen trifft: Farbe, Abstand, Radius und Position der einzelnen Elemente. Multipliziert man diese hundert Entscheidungen auf ein Dutzend Komponenten, entspricht das fertige Produkt nicht mehr der Vorlage. Die Lösung ist nicht „vorsichtiger sein“. Die Lösung sind Tokens, die von Anfang an erzwungen werden. Die Leitfaden für Designsysteme-Aufschlüsselung deckt die vollständige Token-Taxonomie ab.

Ebene 2: Komponenten

Komponenten sind die wiederverwendbaren Einheiten des Designsystems. Jeder Button, jedes Eingabefeld, jede Karte, jedes Modal, jede Navigation und jedes primitive Element ist eine Figma-Komponente mit allen Varianten, Zuständen und dem gesamten responsiven Verhalten.

Die Regel: Nichts, was keine Komponente ist, erreicht die Seitenebene. Ein „loses“ Element (ein manuell gestalteter Button in einem Hero-Bereich) ist ein potenzielles Fehlerrisiko. Ändert sich die Markenfarbe zum ersten Mal, wird dieses lose Element nicht aktualisiert. Auch beim zweiten Mal klappt es nicht. Nach sechs Monaten ist das Designsystem völlig veraltet.

Varianten sind genauso wichtig wie Komponenten. Ein Button ist nicht nur eine Komponente, sondern eine Button-Familie mit verschiedenen Größen, Typen (primär, sekundär, unsichtbar, destruktiv) und Zuständen (Standard, Hover, aktiv, deaktiviert, Ladezustand). Jede Variante, die der Entwickler benötigt, muss in der Datei vorhanden sein. Fehlt sie, erfindet der Entwickler sie, und die erfundene Version weicht von der Vorstellung des nächsten Designers ab.

Ebene 3: Muster

Muster sind die Zusammenstellung von Komponenten zu wiederverwendbaren Layoutblöcken. Hero-Bereiche, Feature-Grids, Navigationsleisten, Fußzeilen, Preistabellen. Sie sind keine vollständigen Seiten, sondern die Bausteine, aus denen die Seiten zusammengesetzt werden.

Muster befinden sich zwischen Komponenten und Seiten. Auf dieser Ebene ist der Großteil der Designabsicht verankert, denn ein Muster legt nicht nur fest, was die Komponenten sind, sondern auch, wie sie zueinander in Beziehung stehen. Ein Hero-Pattern definiert: Überschrift, Unterüberschrift, Call-to-Action (CTA) und unterstützendes Bildmaterial in dieser Reihenfolge, mit diesem Abstand und diesen Größenverhältnissen an jedem Breakpoint.

Patterns dokumentieren auch das responsive Verhalten. Ein Pattern ist erst dann vollständig dokumentiert, wenn es mindestens drei Breakpoint-Varianten (Mobilgeräte, Tablets, Desktop-Computer) aufweist. Patterns ohne Breakpoints sind dekorative Wireframes, die Systemkomponenten vortäuschen.

Ebene 4: Seiten

Seiten sind die finalen Kompositionen. Sie verwenden Patterns, die wiederum Komponenten und Tokens verwenden. Zum Zeitpunkt der Erstellung einer Seite sind alle Werte, alle Grundelemente und alle Blöcke bereits festgelegt.

Eine fertige Seite setzt sich aus Patterns zusammen und fügt nichts Neues hinzu. Sobald eine Seite eine neue Farbe, einen neuen Abstandswert oder einen neuen Button-Stil einführt, der im System nicht existiert, ist das Vier-Ebenen-Modell nicht mehr gültig und der Entwickler kann die Seite nicht mehr reproduzieren.

Seiten sollten außerdem mit ihrem Zweck gekennzeichnet sein: Hero, Überschrift, primärer CTA und Conversion-Pfad. Annotationen bedeuten hier nicht, dem Entwickler vorzuschreiben, was er bauen soll, sondern dem Agenten (Mensch oder KI) den Zweck der Seite zu verdeutlichen, damit bei realen Implementierungsbeschränkungen die richtigen Abwägungen getroffen werden können.

Token-Disziplin ist die tragende Säule

Von den vier Ebenen werden Tokens am häufigsten vernachlässigt, und ihr Fehlen führt am schnellsten zu Problemen bei der Übergabe. Eine Datei mit Token-Disziplin und fehlerhaften Komponenten wird dennoch annähernd korrekt an die Druckvorlage ausgeliefert. Eine Datei mit nachlässiger Token-Disziplin und perfekten Komponenten liefert hingegen nur eine Annäherung an eine Annäherung.

Drei Regeln gewährleisten Token-Disziplin:

Jeder sichtbare Wert wird zu einem Token aufgelöst. Nicht die meisten. Alle. Wenn ein Wert für Farbe, Abstand, Radius oder Typografie kein Token ist, handelt es sich um einen potenziellen Fehler.

Tokens werden semantisch benannt. surface/raised, text/muted, border/strong. Nicht gray-100, gray-400, gray-700. Semantische Namen spiegeln die Intention wider. Wörtliche Namen hingegen sind nur bedingt aussagekräftig und funktionieren nicht mehr, sobald die Marke aktualisiert wird.

Tokens haben eine einzige Datenquelle. Sie befinden sich in einer Figma-Bibliothek, werden einmal exportiert und überall verwendet. Ein Token, das an drei Stellen definiert ist, ist im Grunde null, da niemand weiß, welche Version aktuell ist.

Die Farbtheorie für Designer-Aufschlüsselung beschreibt, wie man eine tokenfreundliche Palette von Grund auf erstellt. Der Abschnitt Typografie-Systemdesign beschreibt dasselbe für Typ-Tokens.

Figma und MCP verändern die Übergabe

Die wichtigste Änderung im Übergabe-Workflow im Jahr 2026 ist Figma und MCP. Der von Figma veröffentlichte Model Context Protocol-Server ermöglicht es Codierungsagenten (Claude Code, Cursor, Claude Desktop), die Figma-Datei direkt zu lesen, einschließlich Tokens, Komponenten, Variablen und Code Connect-Zuordnungen.

Das verändert die Vorgehensweise grundlegend. Der Entwickler muss das Design nicht mehr manuell abschreiben. Der Agent liest die Datei, generiert die Komponente, und der Entwickler überprüft sie. Die Genauigkeit sinkt. Die Geschwindigkeit steigt sprunghaft an. Die Übergabe ist kein Übersetzungsschritt mehr, sondern ein Kompilierungsschritt.

Der Haken: MCP funktioniert nur so gut wie die zugrunde liegende Datei. Eine vierschichtige Datei mit sauberen Tokens, echten Komponenten und Code Connect-Bindungen erzeugt sauberen Code. Eine unvollständige Datei ohne Tokens erzeugt dieselbe Genauigkeit wie zuvor, nur schneller. MCP erweitert die Datei, optimiert sie aber nicht.

Für eine detailliertere Beschreibung der Einrichtung bietet Figma MCP-Anleitung eine umfassende Darstellung der Verkabelung zwischen Claude Code, Cursor und Claude Desktop. Die Aufschlüsselung unter Claude Code für Designer zeigt, wie sich der Agent in den Arbeitsalltag von Designern integriert.

Die Code-Connect-Schicht

Code Connect stellt die explizite Verbindung zwischen einer Figma-Komponente und der zugehörigen Produktionscodekomponente her. Ohne Code Connect muss die MCP-gesteuerte Generierung den Komponentennamen, die Prop-API und den Importpfad erraten. Mit Code Connect erfolgt die Generierung deterministisch.

Teams, die eine Benutzeroberfläche für ein echtes Produkt entwickeln, sollten Code Connect unbedingt verwenden. Der Einrichtungsaufwand ist gering (eine Zuordnung pro Komponente), und der Nutzen summiert sich mit jeder weiteren Generierung. Davon profitieren Coding-Agenten, Storybook-Integrationen, Tools zur Qualitätssicherung im Design und visuelle Vergleichssysteme.

Die Zuordnung befindet sich in einer kleinen .figma.tsx-Datei pro Komponente. Diese deklariert die React-Komponente, ihre Eigenschaften (Props) und wie die Figma-Varianten diesen Eigenschaften zugeordnet werden. Anschließend ruft der Agent oder Entwickler Komponenteninstanzen von Figma ab und erhält vollständig typisierte React-Komponenten zurück.

Der Übergabe-Prüfprozess

Die Übergabe erfolgt nicht mit der Auslieferung der Datei, sondern erst, wenn das bereitgestellte Produkt der Komposition entspricht. Drei Prüfpunkte erkennen Abweichungen vor der Auslieferung.

Prüfpunkt 1: Selbstprüfung des Designs vor der Übergabe

Bevor die Datei an die Entwicklung gesendet wird, führt der Designer fünf Prüfungen durch.

Jeder sichtbare Wert wird zu einem Token aufgelöst. Jedes Seitenelement ist eine Komponenteninstanz, keine einzelnen Primitiven. Jede Komponente verfügt über alle Varianten, die die Seite verwendet. Jeder responsive Breakpoint ist für jedes Muster auf der Seite dokumentiert. Jede Seite ist mit ihrem Hauptzweck und dem Conversion-Pfad versehen.

Seiten, die einen der fünf Punkte nicht erfüllen, gehen zurück in die Designphase, nicht in die Entwicklung. Dies ist der kostengünstigste Zeitpunkt, um Fehler zu erkennen, da noch nichts erstellt wurde.

Checkpoint 2: Komponentenprüfung im ersten Build

Der Entwickler (oder der Agent) erstellt zuerst die Komponenten, bevor die Seiten erstellt werden. Der Designer prüft die Komponenten anhand der Figma-Bibliothek, bevor mit der Seitenbearbeitung begonnen wird.

Hier werden Token-Abweichungen, fehlende Varianten und Inkompatibilitäten mit der Prop-API erkannt. Die Behebung dieser Fehler auf Komponentenebene behebt sie überall. Die Behebung auf Seitenebene behebt sie nur einmal und führt sie auf der nächsten Seite wieder ein.

Eine 30-minütige Komponentenprüfung an diesem Checkpoint spart später 30 Stunden Nacharbeit auf Seitenebene. Die Rechnung ist eindeutig zugunsten des Teams.

Checkpoint 3: Visuelle Qualitätssicherung anhand des Layouts

Nachdem die Seite auf die Staging-Umgebung übertragen wurde, führt der Designer eine visuelle Qualitätssicherung anhand des Layouts durch. Nicht „Sieht es gut aus?“, sondern „Entspricht es der Komposition pixelgenau?“ Tokens, Abstände, Gewichtungen, Breakpoints, Zustände, Bewegung.

Die Qualitätssicherung ist keine Liste von Kleinigkeiten. Sie ist ein strukturierter Vergleich mit der vierschichtigen Datei. Jede Abweichung ist entweder ein Fehler, eine Designentscheidung des Entwicklers unter vorgegebenen Bedingungen oder eine Komposition, die an die bessere Umsetzung in der Praxis angepasst werden muss. Alle drei Ergebnisse sind gültig. Es geht darum, den Unterschied sichtbar und entschieden zu machen, nicht unsichtbar und einfach ausgeliefert.

Wenn Sie ein Team möchten, das diesen Prozess als einen einzigen Workflow durchläuft, anstatt zwei voneinander getrennte Teams, dann nutzen Sie Brainy einstellen. Marken-, Web- und Produkt-UI werden ohne Abweichungen bei der Übergabe ausgeliefert.

Die Kurzanleitung für die Übergabe

Speichern Sie diese. Heften Sie sie an das Design-Ops-Dokument an.

| Ebene | Befindet sich in | Was wird ausgeliefert | Fehlermodus |

-------|----------|---------------|--------------|

| Tokens | Figma Variablen | Farbe, Abstand, Typ, Radius, Schatten, Bewegung | Lose Werte, die nicht in Tokens aufgelöst werden |

| Komponenten | Figma Bibliothek | Schaltflächen, Eingabefelder, Karten, Primitive mit allen Varianten | Lose Elemente, die manuell innerhalb von Seiten gestaltet werden |

| Muster | Figma Bibliothek | Hero-, Navigations-, Feature- und Footer-Baugruppen mit Breakpoints | Muster mit einem Breakpoint ohne responsives Verhalten |

| Seiten | Figma Datei | Endgültige Kompositionen aus Mustern und Komponenten | Seiten, die neue, nicht im System vorhandene Werte einführen |

| Tools | Rolle | Wann es sich lohnt |

---------|------|------------------|

| Figma Variablen | Token als zentrale Datenquelle | In jedem Projekt, ohne Ausnahme |

| Code Connect | Komponenten von Figma den Komponenten von React zuordnen | Wenn MCP zum ersten Mal eine Komponente für Sie generiert |

Figma MCP | Coding-Agenten die Datei lesen lassen | Wenn Claude Code zum ersten Mal einen Bildschirm erstellen soll |

Storybook | Live-Komponentenreferenz für Entwickler | Teamübergreifende Übergabe mit mehreren Entwicklern |

Visueller Unterschied (Chromatic, Percy) | Abweichungen nach dem Deployment erkennen | Für jedes Team, das die Arbeit mehrerer Designer ausliefert |

Was ändert sich 2026?

Drei Veränderungen haben die Übergabe in den letzten 18 Monaten beeinflusst.

KI-Agenten lesen die Datei direkt. Claude Code, Cursor, Claude Desktop und v0 nutzen alle Figma bis MCP. Die Übergabe erfolgt nicht mehr nach dem Prinzip „Designer erklärt, Entwickler implementiert“, sondern nach dem Prinzip „Designer liefert eine strukturierte Datei, Agent generiert Code, Entwickler prüft und integriert ihn“. Der Engpass verlagerte sich von der Übersetzung zur Dateiqualität.

Code Connect schloss die Lücke in der Prop-API. Bis 2026 musste die Generierung von MCP die Prop-Namen erraten. Code Connect-Mappings machten die Verknüpfung deterministisch, wodurch KI-generierte Komponenten tatsächlich integrierbar und nicht nur für Demozwecke geeignet waren.

Tokens wurden zur Grundvoraussetzung. Vor drei Jahren galt die Disziplin im Umgang mit Tokens als Reifemerkmal für Top-Designteams. Heute ist sie eine Grundvoraussetzung für die Veröffentlichung jeglicher Anwendungen, die KI-Tools nutzen. Ein Designsystem ohne Tokens ist für MCP, Code Connect und jeden Coding-Agenten, der die Datei liest, unsichtbar.

Die Teams, die 2026 die saubersten Produkte auf den Markt bringen, sind nicht die mit den schönsten Entwürfen. Sie sind die Teams mit den kompaktesten vierschichtigen Dateien, der strengsten Token-Disziplin und den saubersten Code-Connect-Bindungen. Ästhetik spielt weiterhin eine Rolle. Sie ergänzt die Struktur, ersetzt sie aber nicht.

---

FAQ

Was ist Design Handoff?

Design Handoff ist der Prozess der Übertragung eines Designs von einem Design-Tool (üblicherweise Figma) in den Produktionscode. 2026 basiert der Handoff auf einer vierschichtigen Figma-Datei (Tokens, Komponenten, Patterns, Seiten), die es Entwicklern und KI-Coding-Agenten ermöglicht, das Design deterministisch statt approximativ zu implementieren.

Wie übergibt man Figma am besten an Entwickler?

Erstellen Sie eine vierstufige Datei. Tokens für jeden sichtbaren Wert. Komponenten mit allen Varianten. Muster mit allen Breakpoints. Seiten, die ausschließlich aus bestehenden Mustern und Komponenten bestehen. Fügen Sie Code-Connect-Mappings hinzu, falls das Team MCP-gesteuerte Codierungsagenten verwendet. Führen Sie eine dreistufige Überprüfung durch (Audit vor der Übergabe, Build-Review mit Komponenten, visuelle Qualitätssicherung anhand der Komposition).

Was ist der Figma-Entwicklermodus?

Der Figma-Entwicklermodus ist eine kostenpflichtige Version, die Entwicklern, die eine Datei betrachten, Designspezifikationen (CSS, iOS, Android), Code-Snippets und das Code-Connect-Mapping-Panel zur Verfügung stellt. Er ist nützlich für Teams, die nativen Code ausliefern oder erstklassige Entwicklerergonomie in Figma wünschen. Der Nutzen wird durch die Kombination mit Token-Disziplin und Komponentenvarianten noch verstärkt.

Benötige ich Figma MCP für die Designübergabe?

Nicht unbedingt, aber es ändert die Berechnung. Mit MCP lesen Coding-Agents die Figma-Datei direkt und generieren Komponenten anhand der tatsächlichen Tokens und Komponentenvarianten. Ohne MCP überträgt der Entwickler das Design manuell, was langsamer und fehleranfälliger ist. Teams, die Claude Code oder Cursor für die Produktion verwenden, profitieren erheblich von der Integration von MCP.

Wie vermeide ich Designabweichungen nach der Übergabe?

Drei Regeln: Token-Disziplin an der Quelle (jeder sichtbare Wert wird in ein Token aufgelöst). Komponentenbasierte Builds (Entwickler erstellen Komponenten vor Seiten, Designer überprüfen sie vor der Seitenbearbeitung). Strukturierte visuelle Qualitätssicherung nach dem Deployment (Vergleich mit der vierschichtigen Datei, nicht mit visuellen Darstellungen). Abweichungen sind kein Persönlichkeitsproblem, sondern ein Prozessproblem.

Welche Tools benötige ich für eine moderne Designübergabe?

Das Minimum ist Figma mit Variablen und Komponenten. Der nächste Schritt ist Figma Entwicklermodus plus Code Connect für typisierte React Mappings. Die fortgeschrittene Stufe ist Figma MCP, integriert in die von Ihrem Team verwendeten Coding-Agenten (Claude Code, Cursor, Claude Desktop). Storybook und visuelle Diff-Tools (Chromatic, Percy) vervollständigen den Stack für größere Teams.

Die Übergabe ist das System, nicht das Meeting

Früher war die Designübergabe ein einzelner Moment. Ein Meeting, ein Loom, ein Notion-Dokument, eine Slack-Nachricht mit der Aufforderung „Bei Fragen melden“. Dieses Modell war nie skalierbar und wird nun von KI-Agenten abgelöst, die strukturierte Eingaben benötigen, keine menschlichen Anleitungen.

Das Modell von 2026 ist anders. Die Übergabe erfolgt über die Datei. Die Datei ist das System. Das System besteht aus vier Schichten: Tokens, Komponenten, Muster und Seiten. Stimmen die Schichten, liefert der Entwickler das Design intakt aus, der Agent generiert kompilierbaren Code, und die Qualitätssicherung ist schnell erledigt. Stimmen die Schichten nicht, verschlechtert sich jede nachgelagerte Schnittstelle, unabhängig davon, wie gut das Design isoliert betrachtet aussieht.

Wählen Sie ein Projekt. Prüfen Sie die Datei anhand der vier Schichten. Finden Sie die größte Lücke. Beheben Sie diese zuerst. Führen Sie dann die Übergabe mit der neuen Struktur erneut durch und beobachten Sie, wie viel schneller, sauberer und genauer die Implementierung erfolgt.

Wenn Sie ein Team wünschen, das Design und Entwicklung als einen einzigen Prozess abwickelt, bei dem die Datei als Vertrag dient und keine Übergabeprobleme auftreten, dann ist Brainy einstellen die richtige Wahl. Gleiches Team, gleiches System, gleiches Produkt.