Zum Inhalt springen

Design Handoff -- Zusammenarbeit zwischen Designern und Entwicklern

Felix Lenhard 12 min Lesezeit
Zurück zum Blog

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:

ProblemUrsacheAuswirkung
Pixel-AbweichungenUnklare SpezifikationenProdukt sieht "billig" aus
Fehlende ZuständeNur Happy Path designtBugs bei Edge Cases
Falsche Farben/FontsKein Design SystemInkonsistentes Erlebnis
Animations fehlenNicht dokumentiertStatisches, lebloses UI
Responsive LückenNur Desktop designtMobile funktioniert nicht
Hin und HerSchlechte KommunikationVerzö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:

  1. Auto Layout verwenden: Sorgt dafür, dass die CSS-Ausgabe sinnvoll ist
  2. Design Tokens als Variables: Entwickler sehen Token-Namen statt roher Werte
  3. Komponenten benennen: Konsistente, technische Namen (z.B. button/primary/medium)
  4. Constraints setzen: Definiere responsives Verhalten
  5. 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:

  1. Überblick: Was wird gebaut? Welche Screens gehören zusammen?
  2. Walkthrough: Jeden Screen durchgehen, Interaktionen zeigen
  3. Technische Fragen: Ist alles umsetzbar? Gibt es Bedenken?
  4. Prioritäten: Was wird zuerst gebaut? Was kann später kommen?
  5. 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:

BereichPrüfpunkte
LayoutAbstände, Ausrichtung, Proportionen korrekt?
TypografieSchriftart, -grösse, -gewicht, Farbe korrekt?
FarbenStimmen alle Farben mit den Design Tokens überein?
InteraktionenHover, Focus, Active States korrekt?
ResponsiveFunktioniert auf Mobile, Tablet, Desktop?
AnimationenTiming, Easing, Verhalten korrekt?
Edge CasesLange Texte, leere Zustände, Fehler?
AccessibilityKontrast, 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 sagtEntwickler verstehtBesser 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

ToolZweckKosten
Figma Dev ModeDesign-Inspection, Code-SnippetsIn Figma Professional inkl.
ZeplinDediziertes Handoff-ToolAb 0 EUR (1 Projekt)
StorybookKomponenten-Dokumentation im CodeOpen Source

Für die Kommunikation

ToolZweckEmpfehlung
Figma-KommentareAsynchrones Feedback direkt im DesignFür Design-spezifische Fragen
Slack/Teams-ChannelSchnelle Klärungen#design-dev-Kanal erstellen
Loom-VideosKomplexe ErklärungenDesign-Walkthrough aufnehmen
Linear/JiraAufgaben-TrackingDesign-Tasks mit Figma-Links

Für Design QA

ToolZweckKosten
PercyVisueller Vergleich (Screenshots)Ab 0 EUR (5.000 Screenshots)
ChromaticStorybook-basierter visueller TestAb 0 EUR (5.000 Snapshots)
Browser DevToolsManueller AbgleichKostenlos

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):

SchrittDauer
Anforderungen1-2 Stunden
Design-Exploration1-2 Tage
Design Review30-60 Minuten
Detailliertes Design2-3 Tage
Handoff-Meeting30-60 Minuten
Entwicklung3-10 Tage
Design QA2-4 Stunden
Iteration1-2 Tage

Fehler, die ich bei österreichischen Startups sehe

  1. "Wir machen kein Handoff, wir reden einfach drüber": Mündliche Absprachen werden vergessen. Dokumentiere mindestens die wichtigsten Spezifikationen.

  2. Designer übergibt und verschwindet: Handoff ist kein Wurf über den Zaun. Der Designer muss während der Entwicklung verfügbar bleiben.

  3. Kein Design QA: Wenn niemand prüft, ob die Implementierung dem Design entspricht, weicht das Produkt schleichend vom Design ab.

  4. "Pixel-Perfekt" als Ziel: 100% Übereinstimmung zwischen Figma und Browser ist weder realistisch noch nötig. Wichtiger: Das Erlebnis stimmt.

  5. 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:

  1. UX-Design Grundlagen -- Das Fundament
  2. User Research mit kleinem Budget -- Nutzer verstehen
  3. Wireframing und Prototyping -- Ideen visualisieren
  4. UI-Design-Prinzipien -- Visuell konvertieren
  5. Design System aufbauen -- Konsistenz skalieren
  6. Mobile-First Design -- Die Mehrheit erreichen
  7. Accessibility -- Niemanden ausschliessen
  8. Usability Testing -- Probleme finden
  9. Design-Tools im Vergleich -- Das richtige Werkzeug
  10. 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.

Veröffentlicht am
Alle Beiträge

Erstgespräch vereinbaren

Du überlegst zu gründen oder bist schon mittendrin? Schreib uns ein formloses E-Mail -- wir melden uns innerhalb weniger Tage.

E-Mail schreiben