Design Handoff: Wie aus Screens ein Produkt wird

Es gibt diesen Moment in fast jedem Projekt, den alle kennen und über den niemand gern spricht: Das Design ist „fertig", die Entwicklung fängt an, und drei Wochen später steht ein Produkt auf dem Bildschirm, das dem Entwurf ähnelt wie eine entfernte Verwandte. Nichts davon ist falsch. Es ist nur nicht das, was gemeint war. Die Abstände sitzen anders, die Fehlermeldung erscheint an einer Stelle, an der sie niemand sucht, der Ladezustand fehlt komplett, und der leere Bildschirm zeigt eine Überschrift, die im Design nie existiert hat.

Die übliche Diagnose lautet: schlechter Handoff. Die übliche Reaktion darauf ist, das Übergabedokument zu verbessern. Noch eine Spalte in der Spezifikation, noch ein Textfeld neben dem Artboard, noch ein Termin, in dem das Design „durchgesprochen" wird. Und trotzdem passiert beim nächsten Mal dasselbe.

Ich habe das lange für ein Dokumentationsproblem gehalten. Es ist keins. In den Projekten, in denen die Übergabe wirklich funktioniert hat — eine Software für Kita-Beobachtung, eine Publishing-Oberfläche, ein Bildungsportal mit sehr vielen Zuständen —, war das entscheidende Merkmal nie die Ausführlichkeit der Spezifikation. Es war, dass Design und Entwicklung zum Zeitpunkt der Übergabe schon eine Weile miteinander gearbeitet hatten und dieselben Wörter benutzten.

Dieser Artikel handelt davon, was ein Handoff tatsächlich leisten muss, welche Artefakte ihre Arbeit machen und welche nur Arbeit machen — und wie das in kleinen Teams aussieht, in denen niemand eine Stelle für Design Ops hat.

1. Handoff ist kein Termin, sondern ein Zustand

Das Wort ist schon Teil des Problems. „Handoff" klingt nach Staffelübergabe: Einer läuft, übergibt den Stab, hört auf zu laufen. Genau so ist der Prozess in vielen Teams auch organisiert — Design bis Donnerstag, Übergabe am Freitag, Sprint ab Montag.

Nur beschreibt dieses Bild nicht, wie digitale Produkte entstehen. Ein Interface ist nicht fertig, wenn die Screens fertig sind. Es ist fertig, wenn alle Fälle entschieden sind, die im Screen nicht sichtbar sind: der zu lange Name, die leere Liste, der Abbruch mitten im Vorgang, die Zeile, die auf 320 Pixel Breite umbricht. Diese Entscheidungen fallen fast immer erst während der Umsetzung — weil die Fälle vorher schlicht niemandem auffallen.

Wenn die Übergabe ein Termin ist, fallen diese Entscheidungen in der Entwicklung, allein, unter Zeitdruck. Das Ergebnis ist kein schlechtes Handwerk, sondern eine Reihe kleiner, jeweils vernünftiger Notlösungen, die zusammen ein anderes Produkt ergeben.

Faustregel: Wenn dich eine Rückfrage aus der Entwicklung überrascht, war die Frage nicht schlecht gestellt — die Entscheidung war noch nicht getroffen. Rückfragen sind kein Zeichen für einen unklaren Entwurf, sondern für einen unvollständigen.

Praktisch heißt das weniger, als es klingt. Es heißt nicht, dass Designer:innen in jedem Stand-up sitzen müssen. Es heißt drei Dinge:

• Früher zeigen, unfertiger zeigen. Ein grober Flow, den die Entwicklung in Woche eins sieht, verhindert mehr Fehlentscheidungen als ein perfektes Artboard in Woche vier. Wer erst zeigt, wenn es schön ist, zeigt zu spät.
• Die Übergabe hört nicht auf. Sie beginnt beim ersten Wireframe und endet, wenn das Feature live ist — nicht, wenn die Datei geteilt wurde.
• Fragen zulassen, ohne Statusverlust. In Teams, in denen Nachfragen als Kritik am Design gelesen werden, wird nicht mehr gefragt. Es wird geraten. Und Raten sieht man dem Produkt an.

2. Was in der Entwicklung wirklich gebraucht wird

Wer Spezifikationen schreibt, ohne je eine umgesetzt zu haben, schreibt an der Sache vorbei. Deshalb lohnt es sich, einmal zu sortieren, was in der Umsetzung tatsächlich gebraucht wird — und was zwar in Übergabedokumenten steht, aber niemand liest.

Wird gebraucht:

• Regeln statt Werte. „16px Abstand" hilft an genau dieser Stelle. „Abstand innerhalb einer Gruppe: eine Stufe kleiner als zwischen Gruppen" hilft überall. Regeln lassen sich auf Fälle anwenden, die im Entwurf nicht vorkommen — Werte nicht.
• Verhalten bei Veränderung. Was passiert bei zwei Zeichen, was bei zweihundert? Was, wenn das Bild fehlt? Was, wenn die Liste 4.000 Einträge hat? Diese Fragen entscheiden über die Umsetzung mehr als jede Farbangabe.
• Alle Zustände. Dazu gleich mehr — es ist der wichtigste Punkt der Liste.
• Priorität. Was ist Kern, was ist Kür? Wenn eine Umsetzung teuer wird, muss klar sein, was verhandelbar ist. Sonst wird das Falsche gestrichen — nämlich das, was am aufwendigsten aussah.

Wird kaum gelesen:

• Bemaßungspfeile über dem ganzen Screen. Sie erzeugen das Gefühl von Präzision und werden trotzdem überschrieben, sobald ein reales Textfeld reale Inhalte enthält.
• Redundante Wertelisten, die dieselbe Information tragen wie die Komponente im Code, aber schneller veralten.
• Prosa über Designabsicht, die drei Absätze braucht, um zu sagen: „Das ist der wichtigste Knopf auf der Seite."

Der gemeinsame Nenner: Alles, was Design und Code doppelt beschreiben, driftet auseinander. Alles, was eine Entscheidung festhält, die man dem Code nicht ansieht, ist Gold wert.

Spezifikation und Entscheidung sind nicht dasselbe

Diese Unterscheidung hat bei mir mehr verändert als jedes Werkzeug. Eine Spezifikation beschreibt, wie etwas aussieht. Eine Entscheidung legt fest, warum es so ist und was daraus für andere Fälle folgt.

„Der Speichern-Knopf steht rechts unten" ist eine Spezifikation. Sie beantwortet genau eine Frage. „Bestätigende Aktionen stehen rechts, abbrechende links, und der Fokus liegt beim Öffnen auf der abbrechenden" ist eine Entscheidung. Sie beantwortet jede zukünftige Frage nach der Knopfreihenfolge, auch in Dialogen, die es noch gar nicht gibt.

Spezifikationen veralten in dem Moment, in dem sich der Screen ändert. Entscheidungen überleben Redesigns. Wenn du dich fragst, was in ein Übergabedokument gehört und was nicht, ist das der Filter: Steht hier eine Regel, die auch morgen noch gilt — oder eine Beschreibung des heutigen Zustands, die der Code ohnehin genauer kennt?

Beispiel: In der Publishing-Oberfläche war die aufwendigste Spezifikation die für ein Autoren-Dropdown — dreißig Zeilen Beschreibung. Die nützlichste war ein Satz daneben: „Bei mehr als sieben Einträgen wird gesucht, nicht gescrollt." Der eine Satz hat die Komponente bestimmt, die dreißig Zeilen waren nach dem ersten Sprint veraltet.

3. Die Zustandsmatrix: das wichtigste Artefakt der Übergabe

Wenn ich nur ein Artefakt aus der Übergabe retten dürfte, wäre es dieses. Nicht die Screens. Die Zustandsmatrix.

Ein Screen im Entwurf zeigt fast immer den Idealfall: Daten vorhanden, Namen kurz, Netz schnell, Nutzer:in eingeloggt und berechtigt. In der Realität ist dieser Fall einer von acht. Die anderen sieben werden im Design vergessen und in der Entwicklung erfunden.

Die Matrix ist banal: eine Zeile pro Komponente oder Bildschirm, eine Spalte pro Zustand. Ausgefüllt wird sie nicht mit Screens, sondern mit Sätzen — ein Screen pro Zelle wäre unbezahlbar, ein Satz pro Zelle ist in einer Stunde geschrieben.

Die Spalten, die sich bei mir eingebürgert haben:

• Leer: Es gibt noch keine Daten. Unterschiedlich zu behandeln je nach Grund — noch nie welche gehabt, oder gerade alle gelöscht. Wie sehr das über die Produktbindung entscheidet, ist ein eigenes Thema.
• Lädt: Wie lange, und was sieht man solange? Skelett, Spinner oder gar nichts, weil es unter 200 Millisekunden bleibt?
• Gefüllt, wenig: Ein Eintrag. Sieht die Ansicht damit noch aus wie beabsichtigt oder wie ein Fehler?
• Gefüllt, viel: Die Grenze, ab der Paginierung, Virtualisierung oder Suche nötig wird.
• Fehler: Was ist passiert, was kann die Person tun? Ein Fehlerzustand ohne nächsten Schritt ist eine Sackgasse.
• Keine Berechtigung: Ausgeblendet oder sichtbar-aber-gesperrt? Diese Entscheidung ist fachlich, nicht gestalterisch — und wird trotzdem regelmäßig in der Komponente getroffen.
• Offline / Zeitüberschreitung: Vor allem in mobilen Kontexten. Ein halb geladener Bildschirm ohne Erklärung ist der Klassiker.

In der Kita-Software war genau diese Tabelle der Wendepunkt. Der Beobachtungsbogen hatte in der ersten Fassung sieben Screens und fühlte sich fertig an. Die Matrix hat ergeben, dass hinter diesen sieben Screens 34 Zustände lagen — darunter Fälle wie „Bogen begonnen, Kind hat die Einrichtung gewechselt", an die im Entwurf niemand gedacht hatte. Diese Fälle kosten in der Konzeption Minuten. Nachträglich in der Umsetzung kosten sie Tage, weil sie die Datenstruktur berühren.

Tipp: Fülle die Matrix gemeinsam mit einer Person aus der Entwicklung aus, nicht allein. Die Hälfte der Zustände fällt überhaupt erst auf, wenn jemand weiß, wo die Daten herkommen.

4. Namen sind die Schnittstelle zwischen Design und Code

Ein unterschätzter Teil der Übergabe hat mit Pixeln nichts zu tun: Es geht um Vokabular.

Wenn eine Komponente im Design „Card Large" heißt, im Code ContentTile und im Ticketsystem „die Kachel mit dem Bild", dann kostet jedes Gespräch über dieses Element eine Übersetzung. Das klingt nach einer Lappalie und ist in Wahrheit die häufigste Quelle für Missverständnisse, die niemand als Missverständnis erkennt — beide Seiten glauben, über dasselbe zu reden.

• Ein Name pro Ding, über alle Werkzeuge hinweg. Egal welcher. Wichtig ist nur, dass er in Figma, im Code und im Ticket derselbe ist.
• Nach Rolle benennen, nicht nach Aussehen. card-highlight überlebt einen Rebrand, card-blue nicht. Dasselbe gilt für Farben, wie ich im Artikel über semantische Farbrollen ausführlicher beschrieben habe.
• Varianten statt Kopien. Fünf Komponenten namens „Button/Primary/Hover/Disabled/Mobile" sind fünf Dinge, die getrennt veralten. Eine Komponente mit vier Eigenschaften ist ein Ding.
• Zustandsnamen vereinheitlichen. Wenn das Design „inaktiv" sagt und der Code disabled kennt, während es fachlich eigentlich „gesperrt" heißt, sind das drei verschiedene Konzepte, die versehentlich zusammenfallen.

Der Aufwand dafür ist gering, der Effekt sofort spürbar: Sobald beide Seiten dieselben Wörter benutzen, verschwindet ein erheblicher Teil der Rückfragen, weil sie nie entstehen.

5. Tokens statt Bemaßungspfeilen

Die eigentliche Antwort auf das Handoff-Problem ist keine bessere Spezifikation, sondern eine gemeinsame Quelle. Genau das leisten Design Tokens: benannte Werte für Farbe, Abstand, Radius, Schriftgröße und Dauer, die im Design und im Code dieselben sind.

Der Unterschied ist grundsätzlich. Eine Bemaßung sagt: „Hier sind es 24 Pixel." Ein Token sagt: „Hier gilt space-l." Im ersten Fall muss die Zahl übertragen werden und kann dabei falsch werden. Im zweiten Fall wird eine Entscheidung übertragen, die an einer Stelle geändert werden kann und überall gilt.

Was sich in der Praxis bewährt hat:

• Klein anfangen. Abstände und Farben zuerst. Das sind die beiden Kategorien, in denen Design und Umsetzung am häufigsten auseinanderlaufen, und beide sind in einem Nachmittag erfasst.
• Zwei Ebenen reichen lange. Eine Ebene mit Rohwerten (teal-600), eine mit Rollen (color-action). Drei Ebenen sind für die meisten Teams eine Ebene zu viel.
• Bewegung gehört dazu. Dauer und Beschleunigung als Token zu führen ist der einzige Weg, wie Motion konsistent bleibt, statt in jeder Komponente neu erfunden zu werden.
• Kein Token ohne Anwendung. Ein Satz von 200 Tokens, von denen 40 benutzt werden, ist keine Ordnung, sondern ein zweiter Ort, an dem Unordnung entsteht.

Wo Tokens an ihre Grenze kommen

Tokens lösen die Frage nach dem Wert. Sie lösen die Frage nach der Anwendung nicht. Dass space-l überall dasselbe bedeutet, sagt noch nicht, wann space-l und wann space-m richtig ist — und genau da entstehen die Abweichungen, die man dem fertigen Produkt ansieht.

Was hilft, ist eine kurze Anwendungsregel neben dem Token-Satz, in Prosa, keine Tabelle: welche Stufe zwischen Abschnitten gilt, welche innerhalb einer Gruppe, welche innerhalb eines Elements. Drei Sätze. Sie ersparen die immer gleiche Rückfrage und machen aus einer Werteliste ein System.

Die zweite Grenze ist Layout. Für Raster, Umbruchpunkte und das Verhalten zwischen ihnen gibt es keine Token-Entsprechung, die sich sauber übertragen ließe. Hier bleibt nur, das Verhalten zu beschreiben statt der Maße: ab welcher Breite aus zwei Spalten eine wird, was dabei zuerst weicht, und was auf keinen Fall unter den Falz rutschen darf.

Wichtig ist die realistische Erwartung: Tokens ersetzen die Übergabe nicht, sie verkleinern sie. Was vorher besprochen werden musste, ist nachher vereinbart. Wie viel Systematik ein kleines Team dabei wirklich trägt, habe ich im Artikel über Design Systems für kleine Teams beschrieben — die kurze Fassung lautet: deutlich weniger, als die Vorbilder aus Konzernen suggerieren, und deutlich mehr als gar nichts.

6. Design-QA: der Rückweg, den fast alle vergessen

Die Übergabe hat eine zweite Richtung, die in den meisten Prozessen schlicht nicht vorgesehen ist: der Blick auf das Umgesetzte, bevor es live geht.

Ohne diesen Schritt ist die einzige Rückmeldung, die das Design je bekommt, die Produktionsversion — und dann ist die Korrektur ein neues Ticket, das gegen neue Features priorisiert wird und verliert. So entsteht die schleichende Erosion, die man vielen Produkten nach zwei Jahren ansieht: Jede einzelne Abweichung war zu klein, um sie zu melden.

Design-QA muss nichts Aufwendiges sein. Bei mir sind es zwanzig Minuten pro Feature, immer in derselben Reihenfolge:

• Zustände durchklicken, nicht Screens ansehen. Leer, lädt, Fehler — genau die Spalten aus der Matrix. Der Idealfall stimmt fast immer; die anderen sind der Grund für die Prüfung.
• Mit der Tastatur bedienen. Einmal durch das Feature tabben. Fokus sichtbar? Reihenfolge sinnvoll? Kommt man aus dem Dialog wieder heraus? Das findet mehr echte Probleme in fünf Minuten als jeder Pixelvergleich — und es sind die Probleme, die Barrierefreiheit tatsächlich ausmachen.
• Auf 320 Pixel Breite ansehen. Nicht auf einem Gerät. Im Browserfenster, schmalgezogen. Dauert zehn Sekunden.
• Mit echten Inhalten füllen. Der längste reale Name, die längste reale Überschrift. Kein Blindtext, der zufällig gut passt.

Und der Teil, der am meisten Disziplin verlangt: unterscheiden zwischen „ist anders" und „ist schlechter". Nicht jede Abweichung ist ein Fehler. Manche Umsetzungsentscheidung ist besser als der Entwurf, weil sie ein Verhalten berücksichtigt, das im Entwurf nicht sichtbar war. Wer alles zurückmeldet, wird nicht mehr gelesen. Fünf Punkte, sortiert nach Auswirkung, werden abgearbeitet.

Faustregel für die Rückmeldung: Was ändert die Bedeutung? Was ändert die Bedienbarkeit? Was ändert nur das Aussehen? Die ersten beiden Gruppen kommen ins Ticket. Die dritte kommt in die Sammlung für den nächsten Aufräum-Sprint.

Wenn niemand Zeit für QA hat

Der häufigste Einwand gegen Design-QA ist nicht, dass sie unnötig wäre, sondern dass niemand sie einplant. Sie fällt in die Lücke zwischen „Design ist fertig" und „Entwicklung ist fertig", und Lücken haben keine Verantwortlichen.

Was bei mir funktioniert hat, ist unspektakulär: die QA nicht als eigenen Vorgang führen, sondern als Bedingung. Ein Feature ist nicht fertig, wenn der Code gemergt ist, sondern wenn jemand aus dem Design es einmal angesehen hat. Das kostet keine zusätzliche Planung, weil es keine neue Aufgabe ist — es verschiebt nur, wo die Ziellinie liegt.

Und wenn wirklich niemand da ist: Die vier Punkte oben kann auch die Entwicklung selbst abarbeiten. Sie sind bewusst so formuliert, dass sie kein Designurteil verlangen. Zustände durchklicken, tabben, schmalziehen, mit langen Inhalten füllen — dafür braucht es kein geschultes Auge, sondern nur die Gewohnheit.

7. Handoff im kleinen Team — was realistisch trägt

Fast alles, was über Design Handoff geschrieben wird, stammt aus Teams mit eigener Design-Ops-Rolle, festen Ritualen und einem gepflegten System. In der Realität vieler Projekte ist die Lage anders: eine Designerin, zwei Entwickler, ein Kunde mit Termin. Was davon trägt dann noch?

Meine ehrliche Kurzliste, in dieser Reihenfolge:

• Die Zustandsmatrix. Wenn du nur eine Sache machst, mach diese. Aufwand: eine Stunde pro Feature. Wirkung: die größte von allen.
• Ein gemeinsames Vokabular. Kostet nichts außer Konsequenz.
• Abstände und Farben als Tokens. Ein Nachmittag, danach dauerhaft weniger Abweichungen.
• Zwanzig Minuten Design-QA vor jedem Release. Der einzige Weg, wie das System nicht langsam zerfällt.

Und was ich mir spare, wenn die Zeit knapp ist: vollständig bemaßte Artboards, gepflegte Übergabedokumente parallel zum Code, ein Komponentenkatalog, der über das hinausgeht, was tatsächlich gebaut wurde. Diese Dinge fühlen sich nach Professionalität an. Sie erzeugen aber vor allem Pflegeaufwand — und die Version, die niemand pflegt, richtet mehr Schaden an als gar keine, weil ihr trotzdem jemand glaubt.

Beispiel: Im Bildungsportal haben wir die Spezifikationsseiten nach vier Monaten ersatzlos gestrichen. Was blieb, war die Zustandsmatrix pro Modul und ein wöchentlicher Termin von dreißig Minuten, in dem wir das Umgesetzte gemeinsam angesehen haben. Die Anzahl der Abweichungen ist danach gesunken, nicht gestiegen.

Fazit

Design Handoff ist kein Dokumentationsproblem. Es ist ein Problem der gemeinsamen Entscheidungen — und Entscheidungen lassen sich nicht übergeben, sie müssen getroffen werden.

Was daraus folgt, ist überschaubar:

• Die Übergabe ist ein Zustand, kein Termin. Früher zeigen, unfertiger zeigen, Rückfragen als Signal für offene Entscheidungen lesen.
• Regeln schlagen Werte. Was sich auf unbekannte Fälle anwenden lässt, ist mehr wert als was den bekannten Fall exakt beschreibt.
• Die Zustandsmatrix ist das wichtigste Artefakt. Der Idealfall ist einer von vielen; die anderen entscheiden über die Qualität.
• Gemeinsame Namen und gemeinsame Tokens verkleinern die Übergabe, statt sie zu beschreiben.
• Design-QA ist der Rückweg, ohne den ein Produkt über Jahre auseinanderdriftet.

Der beste Handoff, den ich je hatte, bestand aus einer Tabelle, einem gemeinsamen Vokabular und einem wöchentlichen halbstündigen Blick auf das Gebaute. Kein Dokument, das jemand hätte lesen müssen. Das ist keine Nachlässigkeit — das ist der Punkt.