Design Handoff -- Zusammenarbeit zwischen Designern und Entwicklern
"Das sieht aber nicht so aus wie im Design!" -- Wenn dieser Satz in deinem Startup fällt, hast du ein Handoff-Problem. Design Handoff -- die Übergabe von Design-Dateien an Entwickler -- ist einer der kritischsten und gleichzeitig am meisten unterschätzten Prozesse in der Produktentwicklung.
In diesem letzten Beitrag unserer UX/UI-Serie bringe ich alles zusammen: Wie Designer und Entwickler effektiv zusammenarbeiten, damit aus dem Figma-Design ein Produkt wird, das genauso aussieht und funktioniert wie geplant.
Warum Design Handoff so oft schiefgeht
In meiner Arbeit mit österreichischen Startups sehe ich immer wieder die gleichen Probleme:
| Problem | Ursache | Auswirkung |
|---|---|---|
| Pixel-Abweichungen | Unklare Spezifikationen | Produkt sieht "billig" aus |
| Fehlende Zustände | Nur Happy Path designt | Bugs bei Edge Cases |
| Falsche Farben/Fonts | Kein Design System | Inkonsistentes Erlebnis |
| Animations fehlen | Nicht dokumentiert | Statisches, lebloses UI |
| Responsive Lücken | Nur Desktop designt | Mobile funktioniert nicht |
| Hin und Her | Schlechte Kommunikation | Verzögerte Deadlines |
Das Resultat: Frustrierte Designer ("Die haben alles falsch umgesetzt!"), frustrierte Entwickler ("Die Designs sind unvollständig!") und ein Produkt, das niemanden begeistert.
Was ein guter Design Handoff beinhaltet
Die Handoff-Checkliste
Bevor du ein Design an Entwickler übergibst, prüfe folgende Punkte:
Visuelle Spezifikationen
- Alle Farben als Hex/RGB-Werte definiert (idealerweise als Design Tokens, siehe Post 280)
- Typografie: Schriftart, -grösse, -gewicht, Zeilenhöhe, Zeichenabstand
- Abstände: Padding, Margin für alle Elemente
- Border Radius, Shadows, Opacity
- Icons als SVG exportiert
- Bilder in benötigten Grössen und Formaten
Interaktionsdesign
- Alle Zustände dokumentiert (Default, Hover, Active, Focus, Disabled, Loading, Error)
- Transitions und Animationen beschrieben (Dauer, Easing, Eigenschaft)
- Responsive Verhalten für alle Breakpoints
- Tastatur-Navigation spezifiziert
- Screenreader-Verhalten definiert (ARIA-Labels)
Inhalte
- Finale Texte (keine Lorem-ipsum-Platzhalter!)
- Fehlermeldungen formuliert
- Empty States designt
- Loading States designt
- Erfolgs-/Bestätigungsmeldungen
Edge Cases
- Sehr lange Texte (Was passiert bei einem 200-Zeichen-Namen?)
- Sehr kurze Texte (Was passiert bei leerem Content?)
- Viele Einträge (Was passiert bei 1.000 Listeneinträgen?)
- Kein Eintrag (Empty State)
- Langsame Verbindung (Loading)
- Fehler (Error States)
Design Handoff mit Figma
Figma ist das Standard-Tool für Design Handoff in 2027. So nutzt du es optimal:
Der Dev Mode
Figma's Dev Mode ist speziell für Entwickler konzipiert:
Was Entwickler im Dev Mode sehen:
- CSS-Code für jedes Element (Farben, Abstaände, Typografie)
- Abstände zwischen Elementen (automatisch gemessen)
- Asset-Export (Icons, Bilder in verschiedenen Grössen)
- Inspect-Panel mit allen Design-Properties
- Code-Snippets (CSS, iOS, Android)
So bereitest du Figma für den Dev Mode vor:
- Auto Layout verwenden: Sorgt dafür, dass die CSS-Ausgabe sinnvoll ist
- Design Tokens als Variables: Entwickler sehen Token-Namen statt roher Werte
- Komponenten benennen: Konsistente, technische Namen (z.B.
button/primary/medium) - Constraints setzen: Definiere responsives Verhalten
- Assets exportierbar machen: Setze Export-Settings für Icons und Bilder
Figma-Datei strukturieren
Projekt-Datei
|
|-- Cover (Projektuebersicht, Status, Links)
|
|-- Screens
| |-- Desktop
| | |-- Home
| | |-- Dashboard
| | |-- Settings
| | |-- ...
| |-- Tablet
| | |-- ...
| |-- Mobile
| |-- ...
|
|-- Components (lokale Komponenten)
|
|-- Zustaende & Edge Cases
| |-- Loading States
| |-- Error States
| |-- Empty States
| |-- Hover & Focus States
|
|-- Interaktionen & Flows
| |-- User Flow Diagramme
| |-- Prototyp-Links
| |-- Animations-Spezifikationen
|
|-- Annotationen
|-- Technische Hinweise
|-- Accessibility-Anforderungen
|-- Content-Anforderungen
Annotationen richtig einsetzen
Annotationen sind Notizen im Design, die Entwicklern zusätzliche Informationen geben. Sie beantworten Fragen, die das Design allein nicht beantwortet:
Was annotieren:
- Interaktionsverhalten: "Bei Klick öffnet sich ein Dropdown mit max. 5 sichtbaren Einträgen"
- Bedingte Logik: "Button nur aktiv, wenn alle Pflichtfelder ausgefüllt"
- Animationen: "Slide-in von rechts, 300ms, ease-in-out"
- API-Bezug: "Daten kommen vom /users Endpoint"
- Accessibility: "aria-label='Schliessen', Fokus zurück zum Trigger"
Tipp: Nutze ein Figma-Plugin wie "Annotator" oder erstelle eine eigene Annotations-Komponente in deinem Design System.
Der Handoff-Prozess für Startups
Schritt 1: Design Review (vor dem Handoff)
Bevor du das Design übergibst, mache ein internes Review:
Review-Fragen:
- Sind alle Screens für alle Breakpoints vorhanden?
- Sind alle Zustände dokumentiert?
- Stimmen die Designs mit dem Design System überein?
- Sind die Texte final?
- Ist die Accessibility berücksichtigt? (siehe Post 282)
Schritt 2: Handoff-Meeting (30-60 Minuten)
Geh die Designs gemeinsam mit den Entwicklern durch:
Agenda:
- Überblick: Was wird gebaut? Welche Screens gehören zusammen?
- Walkthrough: Jeden Screen durchgehen, Interaktionen zeigen
- Technische Fragen: Ist alles umsetzbar? Gibt es Bedenken?
- Prioritäten: Was wird zuerst gebaut? Was kann später kommen?
- Unklarheiten: Offene Fragen klären, TODOs notieren
Wichtig: Dieses Meeting ist keine Präsentation -- es ist eine Diskussion. Die besten Ergebnisse entstehen, wenn Entwickler früh Feedback geben können.
Schritt 3: Laufende Zusammenarbeit
Design Handoff ist kein einmaliger Vorgang. Während der Entwicklung:
- Täglicher Check-in: 5 Minuten -- gibt es Fragen zum Design?
- Design QA: Designer prüft die Implementierung regelmässig
- Schnelle Iterationen: Kleine Anpassungen direkt im Gespräch klären
- Figma-Kommentare: Für asynchrone Klärungen
Schritt 4: Design QA (Quality Assurance)
Nachdem die Entwickler eine Funktion umgesetzt haben, prüft der Designer:
Design QA Checkliste:
| Bereich | Prüfpunkte |
|---|---|
| Layout | Abstände, Ausrichtung, Proportionen korrekt? |
| Typografie | Schriftart, -grösse, -gewicht, Farbe korrekt? |
| Farben | Stimmen alle Farben mit den Design Tokens überein? |
| Interaktionen | Hover, Focus, Active States korrekt? |
| Responsive | Funktioniert auf Mobile, Tablet, Desktop? |
| Animationen | Timing, Easing, Verhalten korrekt? |
| Edge Cases | Lange Texte, leere Zustände, Fehler? |
| Accessibility | Kontrast, Tastatur-Nav, Screenreader? |
Tipp: Nutze ein Tool wie Percy oder Chromatic für automatisierten visuellen Vergleich zwischen Design und Implementierung.
Kommunikation zwischen Design und Entwicklung
Die häufigsten Konflikte -- und wie du sie löst
Konflikt 1: "Das ist technisch nicht möglich"
Oft bedeutet das: "Das ist aufwändig" -- nicht unmöglich. Lösung: Gemeinsam eine pragmatische Alternative finden, die den UX-Kern erhält.
Konflikt 2: "Das Design ist unvollständig"
Berechtigte Kritik. Lösung: Nutze die Handoff-Checkliste oben und schliesse die Lücken vor dem nächsten Mal.
Konflikt 3: "Das sieht im Design anders aus als im Browser"
Browser rendern anders als Figma. Lösung: Design QA mit echten Browsern, nicht im Figma-Prototyp.
Konflikt 4: "Wir haben keine Zeit für diese Animation"
Priorisiere: Welche Animationen sind essentiell für die UX, welche sind Nice-to-have? Kernanimationen (Loading, Feedback) sind Pflicht; dekorative Animationen können später kommen.
Gemeinsame Sprache finden
Designer und Entwickler sprechen oft verschiedene Sprachen. Ein gemeinsames Vokabular hilft:
| Designer sagt | Entwickler versteht | Besser sagen |
|---|---|---|
| "Das soll so schweben" | ??? | "Box-shadow: 0 4px 12px rgba(0,0,0,0.1), z-index: 10" |
| "Das soll sliden" | ??? | "transform: translateX, transition 300ms ease-out" |
| "Mach das responsive" | "Wie genau?" | "Ab 768px: 2 Spalten, ab 1024px: 3 Spalten" |
| "Der Button soll primär sein" | "Welcher Style?" | "Button-Component, Variant: Primary, Size: Medium" |
Ein Design System (siehe Post 280) hilft enorm, weil beide Seiten die gleichen Komponentennamen verwenden.
Tools für bessere Zusammenarbeit
Für den Handoff
| Tool | Zweck | Kosten |
|---|---|---|
| Figma Dev Mode | Design-Inspection, Code-Snippets | In Figma Professional inkl. |
| Zeplin | Dediziertes Handoff-Tool | Ab 0 EUR (1 Projekt) |
| Storybook | Komponenten-Dokumentation im Code | Open Source |
Für die Kommunikation
| Tool | Zweck | Empfehlung |
|---|---|---|
| Figma-Kommentare | Asynchrones Feedback direkt im Design | Für Design-spezifische Fragen |
| Slack/Teams-Channel | Schnelle Klärungen | #design-dev-Kanal erstellen |
| Loom-Videos | Komplexe Erklärungen | Design-Walkthrough aufnehmen |
| Linear/Jira | Aufgaben-Tracking | Design-Tasks mit Figma-Links |
Für Design QA
| Tool | Zweck | Kosten |
|---|---|---|
| Percy | Visueller Vergleich (Screenshots) | Ab 0 EUR (5.000 Screenshots) |
| Chromatic | Storybook-basierter visueller Test | Ab 0 EUR (5.000 Snapshots) |
| Browser DevTools | Manueller Abgleich | Kostenlos |
Best Practices für kleine Teams
In einem Startup trägt oft eine Person mehrere Hüte. Hier sind spezifische Tipps für verschiedene Team-Konstellationen:
Gründer designt und entwickelt selbst
- Nutze ein CSS-Framework wie Tailwind (Design direkt im Code)
- Starte mit einer Komponentenbibliothek wie shadcn/ui
- Skizziere grob in Figma, setze direkt im Code um
- Halte dich an ein bestehendes Design System (z.B. Material Design)
Ein Designer, mehrere Entwickler
- Designer erstellt das Design System in Figma
- Wöchentliches 30-Minuten-Sync für Design-Fragen
- Entwickler nutzen Figma Dev Mode für Inspection
- Designer macht wöchentliches Design QA
Agentur für Design, internes Entwickler-Team
- Klare Design-Spezifikationen einfordern (Handoff-Checkliste!)
- Design System als Vertragsbestandteil
- Regelmässige Abstimmungen (nicht erst am Ende)
- Alle Zustände und Edge Cases einfordern
Der ideale Design-Development-Workflow
1. Anforderungen definieren (gemeinsam)
|
2. Design-Exploration (Designer)
|
3. Design Review (gemeinsam)
|
4. Detailliertes Design + Spezifikation (Designer)
|
5. Handoff-Meeting (gemeinsam, 30 min)
|
6. Entwicklung (Entwickler, mit laufenden Rueckfragen)
|
7. Design QA (Designer prueft Implementierung)
|
8. Iteration (Anpassungen basierend auf QA)
|
9. Launch
|
10. Nutzer-Feedback sammeln und naechste Iteration planen
Zeitrahmen für ein Feature (Startup-Tempo):
| Schritt | Dauer |
|---|---|
| Anforderungen | 1-2 Stunden |
| Design-Exploration | 1-2 Tage |
| Design Review | 30-60 Minuten |
| Detailliertes Design | 2-3 Tage |
| Handoff-Meeting | 30-60 Minuten |
| Entwicklung | 3-10 Tage |
| Design QA | 2-4 Stunden |
| Iteration | 1-2 Tage |
Fehler, die ich bei österreichischen Startups sehe
-
"Wir machen kein Handoff, wir reden einfach drüber": Mündliche Absprachen werden vergessen. Dokumentiere mindestens die wichtigsten Spezifikationen.
-
Designer übergibt und verschwindet: Handoff ist kein Wurf über den Zaun. Der Designer muss während der Entwicklung verfügbar bleiben.
-
Kein Design QA: Wenn niemand prüft, ob die Implementierung dem Design entspricht, weicht das Produkt schleichend vom Design ab.
-
"Pixel-Perfekt" als Ziel: 100% Übereinstimmung zwischen Figma und Browser ist weder realistisch noch nötig. Wichtiger: Das Erlebnis stimmt.
-
Zu späte Einbindung der Entwickler: Wenn Entwickler erst beim Handoff zum ersten Mal das Design sehen, fehlen ihre technischen Inputs. Beziehe sie früh ein.
Zusammenfassung der gesamten UX/UI-Serie
In den letzten 10 Beiträgen haben wir den gesamten UX/UI-Design-Prozess abgedeckt:
- UX-Design Grundlagen -- Das Fundament
- User Research mit kleinem Budget -- Nutzer verstehen
- Wireframing und Prototyping -- Ideen visualisieren
- UI-Design-Prinzipien -- Visuell konvertieren
- Design System aufbauen -- Konsistenz skalieren
- Mobile-First Design -- Die Mehrheit erreichen
- Accessibility -- Niemanden ausschliessen
- Usability Testing -- Probleme finden
- Design-Tools im Vergleich -- Das richtige Werkzeug
- Design Handoff (dieser Beitrag) -- Vom Design zum Produkt
Gemeinsam bilden diese Beiträge einen vollständigen Leitfaden für Startups, die nutzerzentrierte Produkte entwickeln wollen -- ohne riesiges Budget, ohne grosses Team, aber mit Methode und Fokus.
Dein nächster Schritt
Bei Startup Burgenland unterstützen wir dich bei der gesamten Produktentwicklung -- vom ersten User Research bis zum erfolgreichen Launch. Hol dir jetzt den Gründungszuschuss und mach deine Designer-Entwickler-Zusammenarbeit zum Wettbewerbsvorteil.
Dieser Beitrag ist Teil der Serie "UX, UI und Design" auf Startup Burgenland. Alle Beiträge findest du in unserem Blog.
Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.