Vom Pixel zum Produkt – Warum das Design-Handover nicht das Ende ist

Die Übergabe von UI-Designs an die Entwicklung ist ein spannender Moment. Wochenlange Arbeit wird nun in echte Funktionalität übersetzt. Man könnte meinen, die Designarbeit sei nun getan. Doch genau da beginnt oft der Teil, den viele Designer:innen unterschätzen.

„Designs übergeben und dann Daumen drücken, dass alles passt“ – so habe ich früher gearbeitet. Bis ich verstanden habe: Gutes Design endet nicht mit der Übergabe an das Entwicklungsteam. Es beginnt erst dann, sich wirklich zu beweisen.

Übergabe heißt nicht Abschied

In meinen Projekten lief es anfangs so: Ich erstellte mit viel Liebe zum Detail Figma-Dateien. Alles war sauber benannt, konsistent aufgebaut, beschriftet und vorbereitet. Die Entwickler:innen erhielten Zugang, wir führten ein Handover-Meeting durch und alles schien klar zu sein.

Und dann: zwei Wochen später ein erster Zwischenstand. Ich sah plötzlich Dinge, die ich nie so designed hatte. Padding, das irgendwo verloren ging. Farben, die nicht ganz stimmten. Abstände, die nicht zueinander passten. Und das alles nicht, weil die Entwickler:innen keine Ahnung hatten. Sondern weil mein Handover nur ein Teil der Arbeit war.

Der andere Teil ist der, der oft vergessen wird: die Umsetzung aktiv zu begleiten. Also nicht nur Designs zu übergeben, sondern auch nach dem Handoff weiter ansprechbar zu sein, Fragen mitzukriegen und bei Entscheidungen mitzusprechen. Genau das hatte ich oft nicht mit bedacht.

Denn ein Design ist nicht abgeschlossen, sobald es in den Händen von Entwicklern liegt. Es lebt weiter, und wie es am Ende aussieht, hängt nicht nur davon ab, wie genau das Design im Code umgesetzt wird, sondern auch davon, wie eng wir in dieser Phase zusammenarbeiten, wie gut Fragen geklärt werden und ob Entscheidungen im Sinne der Nutzer:innen getroffen werden.

Warum es nach dem Handover erst richtig losgeht

Rückblickend war mir nicht bewusst, was nach dem Handover noch alles passieren kann. Ich dachte, mein Design sei klar. Schließlich stand alles in Figma. Aber im Entwicklungsalltag tauchten Fragen auf, die auch ein responsiver Figma-Prototyp nicht beantworten konnte:

• Was passiert bei langen Texten oder Namen, die das Layout sprengen könnten?
• Wie soll ein Formular reagieren, wenn der Nutzer plötzlich offline ist?
• Wie gehen wir mit Fehlermeldungen um, die im Design nicht explizit dargestellt sind?
• Was passiert, wenn Inhalte über eine API nachgeladen werden und noch nicht vollständig vorliegen?

Diese Beispiele sind nur ein kleiner Ausschnitt, die Realität ist oft noch komplexer. Und genau das zeigt, dass während der Implementierung ständig neue Fragen auftauchen. Viele davon hatte ich anfangs gar nicht auf dem Schirm. Wenn ich als Designerin in diesen Momenten nicht greifbar bin, wird improvisiert mit Lösungen, die am Design und den Nutzer:innen vorbeigehen. Das Ergebnis sind unnötige Iterationsschleifen, viele Rückfragen, Missverständnisse und Frust – auf beiden Seiten.

Heute plane ich Designs vorausschauender, nicht nur in Screens, sondern auch mit Varianten und „Was wäre wenn“-Szenarien. Ich lege bewusst Zustände an, in denen das System nicht optimal reagiert: Fehlermeldungen, Ladephasen, ungewöhnliche Inhalte. Wenn ein Nutzername plötzlich 45 Zeichen hat oder eine Datenverbindung ausfällt, sollte das nicht zu improvisierten Lösungen führen.

Je nach Projekt richte ich im Figma-File eine eigene Sektion ein, in der ich Edge Cases und alternative Zustände abbilde. Was nicht visualisiert wird, dokumentiere ich mit Annotations in Figma oder als Jira-Ticket. Immer mit einem Ziel: Entwickler:innen nicht raten zu lassen, sondern sicher entscheiden zu können. Selbst dann, wenn etwas schiefläuft.

Learning #1: Der Handover startet viel früher als du denkst

Damit das Handover überhaupt reibungslos funktioniert, ist etwas anderes entscheidend: Die Entwickler:innen sind bereits von Anfang an Teil des Designprozesses. Wir sprechen früh über Konzepte, technische Machbarkeit und Komponenten, die wiederverwendet werden können. So entsteht ein gemeinsames Verständnis und oft auch neue Ideen, auf die weder Design noch Dev allein gekommen wären.

Gemeinsam mit meinem Kollegen Oliver habe ich einen weiteren Artikel über die Zusammenarbeit von Design und Entwicklung verfasst, hier geht’s zum Beitrag.

Learning #2: Übergabe ist keine Einbahnstraße

„Ein guter Handover ist keine Datei und auch kein einzelnes Meeting. Es ist ein Prozess.“

Ich begleite die Umsetzung aktiv:

• Ich bin erreichbar, wenn Fragen auftauchen. Am besten direkt im Tool, sei es Jira, GitLab oder Slack,
• ich schaue regelmäßig in die Entwicklungsumgebung und gleiche sie mit dem finalen Design in Figma ab
• und ich mache ein finales UI-Review, bevor etwas live geht.

Für das Review arbeite ich direkt mit Figma. Ich vergleiche die reale Umsetzung mit dem Designfile, dokumentiere Abweichungen in Jira und beschreibe dort den Ist-Zustand, den Soll-Zustand sowie einen Link zum entsprechenden Figma-Frame. Ich versuche, konkret zu sein: „Margin oben 1rem statt 2rem“, nicht „fühlt sich irgendwie anders an“. Das spart nicht nur Zeit, sondern sorgt für Klarheit.

Gerade wenn ich mehrere Projekte parallel betreue, merke ich, wie wichtig die kontinuierliche Begleitung ist. Wenn mein Fokus mal auf einem anderen Projekt liegt, sehe ich später oft Umsetzungen, bei denen etwas hinzugefügt oder verändert wurde, weil offene Fragen nicht geklärt wurden. Und dann wird improvisiert. Das zeigt mir immer wieder, wie wichtig es ist, auch zwischen den offiziellen Übergabepunkten präsent und ansprechbar zu bleiben.

Das klingt erstmal nach Mehraufwand, ist es aber nicht. Es spart Zeit, Rückfragen, Diskussionen und verhindert enttäuschte Gesichter beim Kunden, wenn das Design am Ende anders aussieht als das, was abgenommen wurde.

Learning #3: Dokumentation ersetzt keine Kommunikation

Figma kann viel. Aber es ersetzt kein Gespräch. Figma-Kommentare, Annotierungen, Libraries – all das ist hilfreich. Wenn Entwickler:innen jedoch nicht verstehen, warum etwas so designt wurde, gehen sie verständlicherweise eigene Wege.

Deshalb spreche ich, erkläre, frage und bin präsent. Nicht als Designerin, die ihr Werk beschützt, sondern als Partnerin im Projekt mit dem gleichen Ziel wie die Devs: ein sauberes, funktionierendes und ästhetisch stimmiges Produkt.

Ein Design erklärt sich nicht nur visuell, sondern auch durch seine Wirkung. Wenn Entwickler:innen verstehen, dass eine bestimmte Button-Platzierung messbar Einfluss auf die Conversion hat oder dass eine zu laute Fehlermeldung Nutzer:innen abschrecken kann, treffen sie bewusstere Entscheidungen. Ich versuche deshalb, nicht nur das Wie zu zeigen, sondern auch das Warum zu erklären.

Learning #4: Weniger Korrekturschleifen, mehr Flow

Ich erinnere mich an Projekte, in denen wir nach der ersten Umsetzung fünf Feedbackrunden durchlaufen haben. Heute passiert das seltener. Nicht, weil Feedback überflüssig geworden ist. Im Gegenteil: Weil ich früh dafür sorge, dass Design und Entwicklung Hand in Hand arbeiten. Das spart am Ende viele Korrekturen.

Je früher ich mitbekomme, wenn etwas schiefläuft, desto weniger muss später zurückgebaut werden. Gleichzeitig lernen die Entwickler:innen mit jedem Projekt besser, worauf ich Wert lege. Und ich lerne, wie ich das Design-File noch klarer und verständlicher vorbereiten kann.

Natürlich kommen immer wieder neue Entwickler:innen ins Projekt, jede:r bringt einen anderen Stil mit oder ist unterschiedlich mit Figma vertraut. Aber gerade deshalb ist es so wichtig, das Design nicht einfach nur zu übergeben, sondern auch danach aktiv am Umsetzungsprozess beteiligt zu bleiben.

Kurz gesagt

Der Handover ist wie ein Staffelstab. Und wie gut der nächste Teamkollege läuft, hängt davon ab, wie ich diesen übergebe und ob ich nach dem Übergeben noch mitrenne.

Ich wünsche mir weniger Momente, in denen wir überrascht feststellen, dass die Umsetzung anders ist als geplant und mehr echte Zusammenarbeit. Kein Design, das irgendwo allein vor sich hinwerkelt, sondern ein gemeinsamer Prozess. Vom ersten Pixel bis zum letzten Commit.

Sophie Rauhut

Sophie arbeitet als UX-Designerin bei Inspired Consulting. Sie unterstützt und begleitet die Kunden in der Konzeption und Realisierung von digitalen Produkten. Um die Feedbackschleife kurz zu halten, setzt sie dabei auf klickbare Prototypen und zeitnahe Verprobung durch User-Tests.