Vom Design zum Code: Was geht beim Design Handoff verloren?

Kurz gesagt: was ist ein Design Handoff

Beim Design Handoff wird ein Screen aus Figma an die Entwicklung übergeben, bevor er zu Code wird. Auf dem Papier ist das einfach: Der Link zur Datei geht raus, die Entwicklung schaut drauf und schreibt den Code.

Das Problem: Ein Screen ist ein Bild, Code ist Verhalten. Im Bild ist ein Button in einem einzigen Zustand zu sehen. Im Code müssen auch Fokus, Laden und Deaktiviert desselben Buttons geschrieben werden.

Jede fehlende Entscheidung trifft die Entwicklung selbst. Diese Entscheidung ist meist vernünftig, aber nicht die, die das Design getroffen hätte. Nach ein paar Sprints sieht das Produkt seiner Figma-Fassung kaum noch ähnlich.

Was beim Handoff verloren geht

In Audits und in meinen eigenen Projekten sehe ich den Verlust immer an denselben Stellen. Ihr gemeinsamer Nenner ist einfach: Nichts davon ist auf einem Screenshot zu sehen.

1. Tokens

In Figma kann eine Buttonfarbe nur als #1A1916 erscheinen. Dieser Wert ist eine Farbentscheidung, aber ohne Namen kopiert die Entwicklung ihn so in den Code. Ändert sich die Markenfarbe, findet niemand diese Zeile.

Bekommt ein Wert einen Namen, heißt er Design Token. In Figma werden diese Namen als Variablen gehalten, im Code werden sie zu CSS-Variablen. Steht auf beiden Seiten derselbe Name, bleibt für diese Farbe beim Handoff nichts zu besprechen.

Die Prüfung ist leicht. Klicken Sie in Figma auf eine Füllung: Sehen Sie einen rohen Farbcode oder einen Namen? Sehen Sie einen Rohwert, kann diese Entscheidung beim Handoff verloren gehen.

2. Zustände von Komponenten

In Designdateien fehlen am häufigsten die Zustände. Der Button ist gezeichnet, aber nicht, wie er bei Tastaturfokus oder beim Laden aussieht.

Bei jeder interaktiven Komponente prüfe ich diese Zustände: Standard, Hover, gedrückt, Fokus, Laden, deaktiviert und fehlerhaft. Nicht jede Komponente braucht alle. Aber welcher wegfällt, sollte das Design entscheiden, nicht die Entwicklung raten.

In Figma lassen sich Zustände als Varianten einer Komponente halten. Ist der Variantenname derselbe wie der Zustandsname im Code, muss die Entwicklung nicht fragen, was wozu gehört.

3. Abstände und Typografie

Abstände gehen beim Handoff am leisesten verloren. Das Design lässt 24 Pixel, die Entwicklung schreibt nach Augenmaß 20. Auf einem Screen fällt es nicht auf, nach zwanzig Screens wirkt die Seite unordentlich.

Die Lösung ist, Abstände an eine Skala zu binden. Auf dieser Website stammen Abstände aus einer Skala, die über 4, 8, 12, 16 und 24 Pixel wächst. Jede Stufe hat einen Namen. Sehe ich im Design einen Wert außerhalb der Skala, notiere ich ihn als Fehler oder als bewusste Ausnahme.

In der Typografie geht oft nicht die Schriftgröße verloren, sondern Zeilenhöhe und Laufweite. Legt man Design und Code nebeneinander, fällt der Unterschied sofort auf. Halten Sie auch Textstile benannt, etwa „Fließtext“ oder „Überschrift 2“.

4. Hinweise zur Barrierefreiheit

Ein Screenshot zeigt keine Tastatur. In welcher Reihenfolge man mit der Tab-Taste navigiert, steht nicht im Bild. Auch nicht, wie ein Icon-Button im Screenreader vorgelesen wird.

WCAG 2.2 verlangt das ausdrücklich. Nach Kriterium 2.4.7 (AA) muss jede per Tastatur bedienbare Oberfläche eine Bedienweise haben, bei der der Tastaturfokus sichtbar ist. Kriterium 4.1.2 (A) verlangt, dass Name und Rolle jeder Komponente programmatisch ermittelbar sind.

Deshalb notiere ich beim Handoff Fokusreihenfolge, zugängliche Namen von Icons und wo die Fehlermeldung vorgelesen wird. Welche Stufe die Kriterien haben, beschreibe ich im WCAG-Ratgeber.

5. Randfälle

Eine Designdatei wird meist mit den schönsten Daten gezeichnet. Der Name ist kurz, die Liste endet nach fünf Zeilen. Im echten Produkt bricht der Nachname in zwei Zeilen um, die Liste kommt leer, die Anfrage läuft in ein Timeout.

Für jeden Screen frage ich: Was ist zu sehen, wenn keine Daten da sind, was passiert, wenn die Anfrage scheitert, was bricht, wenn der Text doppelt so lang wird? Für leere Screens hilft das Muster leerer Zustand, für Fehler die Muster zu Fehlermeldungen.

Steht die Antwort auf diese Fragen nicht in Figma, gibt die Entwicklung sie beim Programmieren. Meist die, die am schnellsten geschrieben ist: eine leere weiße Fläche oder „Ein Fehler ist aufgetreten“.

Wie eine Komponente von Figma zu CSS kommt

Unten habe ich fünf Entscheidungen eines Buttons dieser Website einzeln zugeordnet. Die erste Spalte ist die Entsprechung in Figma, die zweite der Token, die dritte die Zeile im Code.

Ausprobieren

Zahlung bestätigen

• BestätigenStandard
• BestätigenHover
• BestätigenFokus
• BestätigenDeaktiviert

1. In FigmaFüllung: Variable surface/inverse
   Token--surface-inverse
   CSSbackground: var(--surface-inverse);
2. In FigmaEckenradius: 18, radius/md
   Token--r-md
   CSSborder-radius: var(--r-md);
3. In FigmaInnenabstand im Auto Layout: 12 und 24
   Token--sp-3 --sp-5
   CSSpadding: var(--sp-3) var(--sp-5);
4. In FigmaTextstil: Instrument Sans, fett, 17
   Token--fs-3 --font-body
   CSSfont: 700 var(--fs-3)/1 var(--font-body);
5. In FigmaVariante: Zustand = Fokus, Deaktiviert
   Token--focus --surface-sunken
   CSS:focus-visible { outline: 3px solid var(--focus); } :disabled { background: var(--surface-sunken); }

Fünf Designentscheidungen eines Buttons dieser Website. Drücken Sie auf eine Eigenschaft: Der passende Token und die CSS-Zeile werden hervorgehoben, der Teil der Komponente wird gerahmt. Die Tokens sind die echten Tokens der Website, die Namen auf der Figma-Seite sind Beispiele.

In keiner CSS-Zeile steht ein Rohwert, jede Zeile verweist auf einen Namen. Ändert sich Farbe oder Abstand, ändert sich nur der Wert des Tokens. Die CSS-Zeilen muss niemand anfassen.

Diese Zuordnung Komponente für Komponente zu pflegen, nennt man Designsystem. Wie man es aufbaut, beschreibe ich Schritt für Schritt im Ratgeber zum Designsystem.

Was Figma Dev Mode leistet

Dev Mode ist der Arbeitsbereich, den Figma für die Entwicklung vorsieht. Laut Figma-Hilfe öffnet man ihn in der Designdatei über den Dev-Mode-Schalter in der Werkzeugleiste oder mit dem Kürzel Umschalt D. Er ist in den Tarifen Professional, Education, Organization, Government und Enterprise enthalten.

Die für den Handoff nützlichen Funktionen stehen unten. Die Namen habe ich so gelassen, wie sie in Figma heißen.

• Ready for dev: Das Design markiert einen Frame, eine Komponente oder einen Abschnitt mit „Mark as ready for dev“ als fertig. Markiertes sammelt sich im Ebenenbedienfeld unter „Ready for development“.
• Changed: Ändert sich ein als fertig markiertes Design später, setzt Figma diesen Status selbst. Von Hand lässt er sich nicht setzen. Ist die Änderung fertig, nimmt das Design die Markierung mit „Done with changes“ weg.
• Completed: Ein zweiter Status, der zeigt, dass die Arbeit erledigt ist. Laut Hilfeseite nur in manchen Tarifen.
• Inspect-Tab: Zeigt Layout, Farbe, Schrifteigenschaften, Stile und Variablen der gewählten Ebene. Im Bereich „Code“ erscheinen automatisch erzeugte Code-Schnipsel, Sprache oder Codegen-Plugin wählt man aus einer Liste.
• Variablen: Sie sehen Wert und Modus einer Variablen und verfolgen die Alias-Kette bis zum Rohwert. Figma schlägt auch Variablen vor, die zu Rohwerten passen.
• Messen und Anmerkungen: Wer die Datei bearbeiten darf, fügt in Design oder Dev Mode mit Umschalt M Maße und mit Umschalt T Anmerkungen (annotations) hinzu. Die vorgegebenen Kategorien der Anmerkungen sind Development, Interaction, Accessibility und Content.
• Compare changes: Vergleicht einen geänderten Frame mit seinen früheren Versionen. Für eine Instanz einer Komponente gibt es den Vergleich mit der Hauptkomponente.
• Focus view: Öffnet nur eines der als fertig markierten Designs. Die übrigen Dev-Mode-Werkzeuge funktionieren auch in dieser Ansicht.
• Figma for VS Code: Eine Erweiterung, mit der Sie die Designdatei im Code-Editor durchsehen und inspizieren. Sie sehen Kommentare in Echtzeit und verknüpfen Code-Dateien mit Komponenten im Design.
• Code Connect: Bringt den echten Komponenten-Code aus Ihrer Codebasis in Dev Mode. In den Tarifen Professional, Organization und Enterprise verfügbar.

Der natürliche Ort für Hinweise zur Barrierefreiheit ist die Kategorie Accessibility. Schreiben Sie Fokusreihenfolge und zugängliche Namen dorthin, findet die Entwicklung sie, wo sie sucht.

Zwei kleine Details helfen noch. Wollen Sie statt Code eine einfache Liste der Eigenschaften sehen, schalten Sie von „Code“ auf „List“ um. Um den Abstand zwischen zwei Ebenen zu messen, halten Sie Option (Mac) oder Alt (Windows) gedrückt und fahren über die zweite Ebene.

An Anmerkungen mag ich ein Detail besonders. Laut Figma bleibt eine Ebeneneigenschaft, die man einer Anmerkung hinzufügt, aktuell, auch wenn sich das Design später ändert.

Was Dev Mode nicht zeigt

Dev Mode zeigt, was in der Datei steht. Ein nicht gezeichneter Fehlerzustand oder eine nicht geschriebene Fokusreihenfolge fehlt auch im Inspect-Tab.

Automatisch erzeugter Code kennt keine Designentscheidung, nur den Wert. Ist die Ebene an keine Variable gebunden, steht im Code-Schnipsel eine Rohfarbe. Deshalb funktioniert Dev Mode gut in einer Datei, in der Tokens und Zustände vorher sauber angelegt sind.

Checkliste vor dem Handoff

Bevor ich einen Screen auf „Ready for dev“ setze, gehe ich diese Liste durch. Kann ich einen Punkt nicht mit Ja beantworten, ist der Screen noch nicht fertig.

• Jeder Wert für Farbe, Abstand, Ecke und Schrift ist an eine Variable oder einen Stil gebunden.
• Die nötigen Zustände jeder interaktiven Komponente sind gezeichnet, die nicht nötigen notiert.
• Abstände stammen aus der Skala, Ausnahmen sind mit einer Notiz erklärt.
• Fokusreihenfolge, zugängliche Namen der Icons und der Ort der Fehlermeldung stehen in einer Accessibility-Anmerkung.
• Leer, Laden, Fehler und langer Text sind gezeichnet.
• Mobile und Desktop-Breite sind getrennt gezeigt.
• Komponenten- und Variantennamen in Figma sind dieselben wie im Code.

Am häufigsten hakt es bei Formularen, weil jedes Feld seinen eigenen Fehlerzustand hat. Worauf Sie Feld für Feld achten, habe ich im Muster Formulardesign gesammelt.

Beispiel: der Handoff eines Überweisungs-Screens

Denken Sie an den Überweisungs-Screen einer Banking-App. In Figma gibt es einen einzigen Screen: Name des Empfängers, IBAN, Betrag und der Button „Senden“. Der Screen sieht sauber aus und geht so an die Entwicklung.

Sobald programmiert wird, kommen Fragen. Wo erscheint der Fehler, wenn die IBAN falsch ist? Wird der Button gesperrt, wenn das Guthaben nicht reicht, oder warnt er erst beim Drücken? Was zeigt der Button, während gesendet wird?

Nichts davon steht auf dem Screen. Die Entwicklung gibt auf jede Frage ihre eigene Antwort. Der Fehler kann ganz oben auf der Seite erscheinen, der Button während des Sendens nichts zeigen. Dann drückt der Nutzer vielleicht ein zweites Mal.

Geht derselbe Screen vor dem Handoff durch die fünf Punkte, steht Folgendes in der Datei:

• Die Varianten Laden und Deaktiviert des Buttons, mit Namen.
• Der fehlerhafte Zustand des IBAN-Felds und der Platz des Fehlertexts direkt unter dem Feld.
• Die Meldung bei zu geringem Guthaben und der Zustand des Betragsfelds.
• Eine Accessibility-Anmerkung: wie die Fehlermeldung an den Screenreader geht und wohin der Fokus nach dem Fehler springt.
• Wie ein langer Empfängername in zwei Zeilen umbricht.

Diese Liste fügt der Datei ein paar Varianten und Anmerkungen hinzu. Dafür fallen die meisten Entscheidungen weg, die die Entwicklung allein treffen müsste.

Wann der Handoff stattfinden sollte

Den Handoff einmal am Ende zu machen, ist der riskanteste Weg. Die Entwicklung bekommt zwanzig Screens auf einmal und weiß nicht, welcher feststeht.

Ich empfehle, Screens Stück für Stück als fertig zu markieren. Ist ein Ablauf fertig, setzen Sie ihn auf „Ready for dev“, der Rest bleibt im Design. Ändert sich ein markierter Screen, zeigt Figma das selbst an, niemand muss von Hand Bescheid geben.

Verlinken Sie außerdem nicht die Datei, sondern den Frame. „Irgendwo in der Datei“ erhöht die Gefahr, dass die Entwicklung auf den falschen Frame schaut.

Meine Notiz

In meinen Projekten gibt es fast keinen Handoff, weil dieselbe Person gestaltet und programmiert. Zeichne ich in Figma einen Button, weiß ich, dass ich auch sein CSS schreibe. Den Token benenne ich im Design und lege ihn im Code mit demselben Namen an.

Die Erklärung ist einfach: Es gibt keinen Wechsel der Hände. Bleiben Design und Code im selben Kopf, fragt niemand „Was meintest du hier?“. Auch die Zahl verlorener Entscheidungen sinkt.

Trotzdem arbeite ich, als würde ich an mich selbst übergeben. Randfälle und Hinweise zur Barrierefreiheit schreibe ich in Figma, weil Ihr Team das Projekt später übernimmt. Am Ende des Design & Ship Sprint liegt die Arbeit mit diesen Notizen in Ihrem Repository.

Sind Design und Entwicklung in Ihrem Team getrennt, hilft diese Gewohnheit am meisten: Setzen Sie sich vor dem Handoff zusammen und gehen Sie einen Screen nur mit der Tab-Taste durch. Lücken, die auf dem Screenshot nicht zu sehen sind, kommen in dieser Runde schnell ans Licht.