Viele Webprojekte verlieren Zeit und Nerven an einer Stelle: beim Übergang vom Design ins Frontend. Im Designtool sieht alles perfekt aus, aber im Browser wirkt das UI plötzlich enger, schief oder einfach „anders“. Der Kern des Problems ist fast immer derselbe: ein unsauberer Design-Handoff.
Dieser Leitfaden zeigt, wie Layouts so vorbereitet werden, dass Entwickler nicht raten müssen, sondern strukturiert umsetzen können – egal ob mit Figma, Adobe XD, Sketch oder anderen Tools gearbeitet wird.
Design-Handoff im Webdesign verstehen
Beim Design-Handoff werden UI-Layouts, Komponenten und Interaktionen aus dem Designtool an das Entwicklungsteam übergeben. Ziel ist, dass aus statischen Screens ein funktionierendes Frontend entsteht – ohne ständiges Nachfragen und ohne Interpretationsspielraum.
Typische Reibungspunkte zwischen Design und Entwicklung
Immer wieder treten ähnliche Probleme auf:
- Abstände und Schriftgrößen sind im Code andere als im Layout.
- Breakpoints (Umsprungpunkte fürs Responsive Design) wurden nie klar festgelegt.
- Zustände von Buttons und Formularfeldern fehlen oder sind nur als Notiz gedacht.
- Icons und Illustrationen liegen in falschen Formaten oder Auflösungen vor.
Das Ergebnis: Entwickler treffen Annahmen, Designer fühlen sich „überstimmt“ und das Projekt verliert Tempo.
Rolle von Designsystem und Komponenten
Ein durchdachtes UI-Design-System mit wiederverwendbaren Komponenten reduziert diesen Frust massiv. Wer systematisch mit Buttons, Inputs, Karten und klar definierten Abständen arbeitet, liefert Entwickler:innen nicht zehn verschiedene Varianten, sondern ein Set aus Bausteinen.
Wie sich so ein System in Figma aufbauen lässt, zeigt ausführlich der Beitrag UI-Design-System in Figma aufbauen. Für den Handoff ist wichtig: Komponenten müssen sauber benannt, konsistent verwendet und dokumentiert sein.
UI-Datei strukturieren: Ordnung statt Layer-Chaos
Bevor über Export oder Dokumentation gesprochen wird, braucht die Design-Datei selbst Struktur. Unaufgeräumte Ebenen, kryptische Benennungen und doppelte Varianten verlängern jeden Handoff.
Seiten, Frames und Ebenen logisch gliedern
Eine sinnvolle Gliederung hilft Entwickler:innen, sich schnell zurechtzufinden:
- Startseite/Overview: Übersicht der wichtigsten Screens, User-Flows und Links zu Detailseiten.
- Seiten für Designsystem: Farben, Typografie, Spacing, Komponenten, Icons.
- Seiten nach Funktionsbereich: z. B. „Onboarding“, „Checkout“, „Profil“.
Innerhalb eines Frames sollten Ebenen klar benannt sein. Statt „Rectangle 123“ lieber „btn/primary/bg“ oder „card/product/image“. Tools wie Figma oder Sketch filtern nach Ebenennamen – das spart Zeit bei der Umsetzung.
Komponenten, Variants und Auto-Layout sinnvoll nutzen
Moderne Designtools bieten Funktionen wie Auto-Layout, Constraints und Responsive-Resizing. Wer diese nutzt, zeigt Entwickler:innen direkt, wie sich Elemente in verschiedenen Breiten verhalten sollen.
Hilfreich ist ein Baukasten aus:
- Basis-Komponenten: Buttons, Inputs, Dropdowns, Badges, Labels.
- Layout-Containern: Karten, Modale, Seitenleisten, Header, Footer.
- Seiten-Templates: Standardseiten, Listenansichten, Detailseiten.
Komponenten sollten Variants für Zustände enthalten: z. B. Button „default“, „hover“, „pressed“, „disabled“. So lassen sich Interaktionen später klar definieren.
Design-Tokens für Farben, Schriften und Abstände definieren
Damit Entwickler Layouts sauber nachbauen können, brauchen sie mehr als Screenshots. Sie benötigen eine klare Übersetzung von Gestaltung in Code: Design-Tokens.
Farbsystem und Kontrast im Griff
Statt zehn beliebiger Blautöne ist ein strukturiertes Farbsystem sinnvoll. Beispiel:
- primary/500 – Hauptfarbe für Buttons und Links
- primary/600 – Hover-Zustand
- neutral/100 – Karten-Hintergrund
- neutral/900 – Standard-Text
Diese Benennungen können Entwickler:innen direkt als CSS-Variablen, SCSS-Variablen oder Design-Tokens im Code nutzen. Wichtig ist, dass Kontraste ausreichend sind – vor allem bei Text und Buttons. Eine klare Farbpalette unterstützt auch andere Themen wie Farben und Kontraste im UI.
Typografie-System statt Einzellösungen
Für Schriften gilt: Besser ein strukturiertes Set von Textstilen als viele Einzelentscheidungen. Zum Beispiel:
- Heading/XL – Seitenüberschrift
- Heading/M – Abschnittsüberschrift
- Body/M – Standard-Text
- Body/S – Meta-Infos, Labels
Wichtig ist, dass diese Stile konsequent im gesamten Layout eingesetzt werden. Das verhindert, dass Entwickler bei jeder Überschrift rätseln müssen, welche Schriftgröße oder Zeilenhöhe gemeint ist.
Spacing-System als Grundlage für Layout
Ein konsistentes Spacing-System macht Abstände im UI berechenbar. Statt beliebiger Pixelwerte werden feste Schritte genutzt, die sich leicht in Code abbilden lassen, etwa in 4er- oder 8er-Schritten.
Ein systematisch geplanter Abstandsraster sorgt nicht nur im Frontend für Klarheit, sondern auch in der Design-Datei. Detailliert beschrieben wird das im Beitrag Designsystem-Abstände im UI planen.
Interaktionen, Zustände und Flows dokumentieren
Screens zeigen oft nur den Idealzustand. Für eine realistische Umsetzung brauchen Entwickler:innen aber auch Fehlermeldungen, Loading-Zustände und Sonderfälle.
States für Buttons, Inputs und Fehlermeldungen
Folgende Zustände sollten mindestens dokumentiert sein:
- Buttons: normal, hover, active, disabled, loading.
- Formulare: leer, ausgefüllt, Fokus, Fehler, Erfolg.
- Systemmeldungen: Info, Warning, Error, Success.
Jeder Zustand sollte im Design klar erkennbar sein – durch Farbe, Icon, Text oder Kombinationen. Am besten werden diese States als eigene Komponenten oder Variants angelegt, nicht nur als schnelle Skizze am Rand.
User-Flows und Prototyping im Handoff nutzen
Neben einzelnen Screens sind Flows wichtig: Wie gelangt ein Nutzer von A nach B? Wo wird validiert, wo geladen, wo ein Fehler angezeigt?
Mit Prototyping-Funktionen in Figma oder ähnlichen Tools können Klickpfade visualisiert werden. Markierungen wie „First click“, „Weiter-Button hier“ oder „Error-Overlay“ helfen, dass Entwickler:innen den Kontext verstehen und keine Schritte übersehen.
Responsive Verhalten für Kern-Breakpoints definieren
Responsive Design entsteht nicht erst im Code. Schon im Handoff sollte klar sein, wie sich Layouts bei verschiedenen Bildschirmbreiten verhalten – etwa für Mobil, Tablet und Desktop.
Sinnvoll ist es, für zentrale Templates mindestens zwei bis drei Breiten auszuarbeiten. Wenn bestimmte Inhalte in der mobilen Version entfallen oder anders sortiert sind, muss das im Layout deutlich werden. Sonst entstehen parallele „Interpretationen“ von Desktop-Designs.
So geht’s: Strukturierter Design-Handoff in der Praxis
Die folgenden Schritte lassen sich als kompakter Ablauf für den Alltag nutzen – ob im Agenturprojekt oder im Inhouse-Team.
- Design-Datei aufräumen: unnötige Frames entfernen, Ebenen logisch benennen, Farben und Textstile vereinheitlichen.
- Designsystem-Seite anlegen: Farben, Typografie, Abstände, Grundkomponenten klar dokumentieren.
- Komponenten finalisieren: Variants für Zustände (hover, active, error usw.) anlegen und im Layout einsetzen.
- Responsive Varianten bauen: zentrale Templates in 2–3 Bildschirmbreiten durchdenken und als Frames anlegen.
- Prototyp-Links und Kommentare nutzen: Flows markieren, Sonderfälle benennen, offene Fragen im Tool notieren.
- Assets vorbereiten: Icons, Illustrationen und Logos in passenden Formaten exportierbar machen (SVG, PNG, ggf. WebP).
- Handoff-Meeting einplanen: Layout vorstellen, Entscheidungen erklären, Randfälle durchgehen, offene Punkte sammeln.
Handoff-Dokumentation: Was Entwickler konkret brauchen
Neben der gut strukturierten Datei selbst hilft eine knappe, aber klare Dokumentation. Sie muss kein Handbuch sein, sollte aber alle wiederkehrenden Fragen abfangen.
Mini-Ratgeber: Welche Infos gehören in ein Handoff-Dokument?
Ein kompaktes Handoff-Dokument (z. B. als Notion-Seite, PDF oder innerhalb des Designtools) kann folgende Punkte enthalten:
- Projekt-Überblick: Kurzbeschreibung, Zielgruppe, wichtigste Use-Cases.
- Designprinzipien: Tonalität (freundlich, sachlich), visuelle Schwerpunkte, Barrierefreiheit als Ziel.
- Tokens: Farbliste mit Namen, Typografiestile, Spacing-Definition.
- Komponentenübersicht: Liste zentraler UI-Elemente mit Links in die Datei.
- Interaktionen: Hover-Effekte, Animationen, Ladezustände, Fokus-Stile für Tastaturnutzung.
- Technische Hinweise: Maximalbreiten, verwendete Icon-Bibliotheken, Bildgrößen für Hero-Visuals, Cards und Thumbnails.
Je klarer diese Informationen sind, desto weniger Detailfragen entstehen im laufenden Projekt.
Checkliste: Datei vor dem Handoff prüfen
Eine kurze Checkliste hilft, den eigenen Handoff-Standard konstant zu halten.
| Bereich | Frage |
|---|---|
| Struktur | Sind Seiten, Frames und Ebenen logisch benannt und gruppiert? |
| Designsystem | Sind Farben, Textstile und Abstände als wiederverwendbare Stile angelegt? |
| Komponenten | Gibt es Varianten für wichtige Zustände (hover, error, disabled)? |
| Responsive | Sind für Schlüssel-Screens mobile und Desktop-Varianten verfügbar? |
| Assets | Sind Icons, Logos und Illustrationen als exportierbare Assets markiert? |
| Dokumentation | Gibt es eine kurze Übersicht mit Tokens, Regeln und Besonderheiten? |
Kommunikation im Handoff: Meetings, Feedback und Änderungen
Selbst der beste Handoff braucht Austausch. Design und Entwicklung sollten sich nicht nur Dateien zuschieben, sondern Verständnis füreinander entwickeln.
Handoff-Meeting effektiv gestalten
Ein kurzes Meeting zum Start der Implementierung spart später viele kleine Rückfragen. Sinnvolle Inhalte:
- Kurze Vorstellung der wichtigsten Flows (z. B. Registrierung, Kaufprozess, Profilbearbeitung).
- Hinweise auf Stellen, an denen bewusst vom Standard abgewichen wurde.
- Abstimmung, welche Teile des Designsystems zuerst umgesetzt und als Code-Komponenten bereitgestellt werden.
Eine strukturierte Feedback-Kultur, wie sie etwa im Beitrag Design-Feedback im Webprojekt strukturieren beschrieben wird, hilft auch im Handoff-Prozess.
Umgang mit Änderungswünschen während der Umsetzung
Sobald der Code steht, fallen oft Details auf, die im Design anders gewünscht wären. Wichtig ist zu klären:
- Welche Änderungen sind Bugfixes (also Abweichungen vom vereinbarten Design)?
- Welche Änderungen sind neue Wünsche und müssen neu priorisiert werden?
- Wie werden Änderungen im Designtool markiert, damit Entwickler:innen sie schnell finden?
Transparente Priorisierung und saubere Versionierung der Design-Datei verhindern, dass sich Layout und Frontend wieder auseinanderentwickeln.
Design-Handoff kontinuierlich verbessern
Ein guter UI-Handoff ist kein einmaliger Kraftakt, sondern ein Prozess. Mit jedem Projekt lernt das Team dazu: Welche Infos haben gefehlt? Wo gab es Missverständnisse? Wie lassen sich Tokens, Komponenten und Dokumentation noch klarer gestalten?
Sinnvoll ist, nach jedem größeren Release ein kurzes Retro-Meeting zu machen und gemeinsam festzuhalten:
- Welche Teile des Handoff-Prozesses haben gut funktioniert?
- Wo kam es zu unnötigen Schleifen oder Verzögerungen?
- Welche Standards (z. B. Namenskonventionen, Spacing-System, Farbdefinitionen) sollten fürs nächste Projekt angepasst werden?
So entsteht Schritt für Schritt ein eigener Handoff-Standard, der ins Team passt und sowohl Designer:innen als auch Entwickler:innen entlastet.
