Ein typisches Problem im Webprojekt: Das Layout sieht in Figma fertig aus, aber in der Umsetzung fehlen plötzlich Abstände, Zustände oder die richtigen Dateien. Dann beginnt ein Ping-Pong aus Screenshots, Nachfragen und „Meintest du so?“. Gute Übergaben vermeiden das nicht durch mehr Dokumente, sondern durch klare Struktur direkt im Designfile.
Die folgenden Schritte helfen dabei, eine Übergabe so aufzubauen, dass sie für Entwicklung, QA (Qualitätssicherung) und spätere Pflege verständlich bleibt – auch wenn Wochen später jemand Neues ins Projekt kommt.
Wann eine Übergabe wirklich „fertig“ ist
Typische Lücken, die später teuer werden
In der Praxis entstehen die meisten Missverständnisse nicht bei großen Komponenten, sondern bei Details: Ist der Abstand zwischen Icon und Text 8 oder 12? Welche Schriftvariante gilt im Hover? Darf ein Button umbrechen? Solche Fragen kosten Zeit, weil sie während der Umsetzung geklärt werden müssen.
Eine belastbare Übergabe enthält deshalb nicht nur Screens, sondern auch Regeln: für Zustände (normal, hover, disabled), für Inhalte (Kurztext vs. Langtext) und für Layoutverhalten (z. B. was passiert, wenn eine Karte höher wird als die daneben).
Eine Definition, die im Team funktioniert
Hilfreich ist eine einfache Team-Definition: Übergabe ist dann fertig, wenn jede UI-Entscheidung im File auffindbar ist, ohne zusätzliche Meetings. Dazu gehört auch, dass Benennungen konsistent sind und Screens eindeutig zugeordnet werden können (z. B. „Checkout – Schritt 2 – Fehlerzustand“ statt „Screen final final“).
Wer Designentscheidungen vorab strukturiert, reduziert Rückfragen. Passend dazu hilft ein kurzer Abgleich mit Design Review im Webdesign – Feedback, das wirklich hilft, um typische Unklarheiten vor dem Handoff zu finden.
Datei-Struktur in Figma: Seiten, Frames, Namen
Seitenaufbau, der ohne Erklärung verstanden wird
Ein übersichtliches Figma-File braucht eine klare Seitenlogik. Bewährt ist eine Trennung nach Zweck: z. B. „Flows“, „Screens“, „Components“, „Archive“. Wichtig ist: Nicht zu viele Seiten, aber genug, damit niemand zwischen Entwürfen suchen muss.
In „Screens“ liegen nur die freigegebenen Frames. Entwürfe, Varianten und explorative Ideen wandern in „Archive“. So bleibt der aktuelle Stand eindeutig.
Benennungen, die auch in Tickets funktionieren
Frame-Namen sollten in Issue-Tracker, QA-Check und Entwicklerkommunikation funktionieren. Praktisch ist ein Muster wie: Bereich – Ansicht – Zustand. Beispiel: „Account – Login – Error“ oder „Shop – PDP – Sticky CTA“.
Bei Komponenten lohnt es sich, Varianten sauber zu benennen (z. B. „Button / Primary / Default“). So lassen sich Spezifikationen schneller lesen und in Code-Strukturen spiegeln. Wer bereits mit Varianten arbeitet, kann ergänzend die Logik aus UI-Design-System in Figma aufbauen – Komponenten mit Plan nutzen.
Was Entwickler:innen wirklich brauchen: Maße, Verhalten, Zustände
Abstände und Größen: weniger raten, mehr Regeln
Maße sind dann hilfreich, wenn sie nicht als Einzelfälle auftauchen, sondern als System. Statt „hier 13 px“ ist „Abstände folgen einem festen Raster“ deutlich robuster. In der Praxis bedeutet das: wiederkehrende Spacing-Werte, konsistente Innenabstände in Karten, und eine klare Regel, wann Elemente wachsen dürfen.
Besonders wichtig: Layouts müssen auch mit echten Inhalten funktionieren. Ein Button-Text kann länger sein, Überschriften können umbrechen. Deshalb sollten kritische Stellen im Designfile mit realistischen Beispieltexten geprüft werden.
Interaktionen und States sichtbar machen
Web-UIs bestehen nicht nur aus dem Normalzustand. Für eine saubere Umsetzung sollten die wichtigsten Zustände im File vorhanden sein: Hover, Focus (Fokus per Tastatur), Active, Disabled, Loading, Fehlerzustände und leere Zustände. Das muss nicht als animierter Prototyp passieren – oft reichen separate Frames oder Komponenten-Varianten.
Gerade bei Formularen reduziert ein klarer Fehlerzustand Diskussionen in der Entwicklung. Wer Formulare überarbeitet, findet ergänzende Muster in Formular-UX optimieren – Validierung, Fehler, Barrierefreiheit.
Assets exportieren: wann PNG, wann SVG, wann gar nicht
Icons und Illustrationen: Vektor ist oft die bessere Wahl
Für UI-Icons ist SVG häufig ideal, weil es scharf skaliert und meist klein bleibt. Trotzdem sollte nicht jedes SVG ungeprüft exportiert werden: Zu komplexe Pfade oder eingebettete Effekte können in manchen Workflows Probleme machen. Dann ist ein vereinfachtes SVG oder ein alternatives Icon sinnvoll.
Bei Illustrationen gilt: Wenn sie stilistisch zum Brand gehören und wiederverwendet werden, lohnt sich ein gepflegter SVG-Export. Wer dabei konsistent bleiben will, kann sich an SVG-Illustrationen fürs Webdesign – Stil, Export, Pflege orientieren.
Bilder: Crops und Fokus vor dem Export festlegen
Bei Bildern entstehen viele Fehler durch unklare Zuschnitte: Auf Desktop passt das Motiv, auf Mobile ist das Gesicht abgeschnitten. Deshalb sollten Crops im Designfile bewusst gesetzt werden (z. B. mit festen Bildrahmen) und kritische Motive mit Fokus markiert werden. Das verhindert, dass in der Umsetzung „irgendein Crop“ entsteht.
Wenn die Bildbearbeitung Teil der Übergabe ist, hilft eine klare Bildlogik (Format, Fokus, Verhältnis). Vertiefend dazu passt UI-Bilder richtig zuschneiden – Crops, Fokus und Formate.
Wann kein Export nötig ist
Viele UI-Elemente müssen gar nicht als Asset exportiert werden: einfache Shapes, Flächen, Linien oder Schatten lassen sich meist besser in CSS umsetzen. Eine gute Übergabe zeigt dann nicht „Hier ist ein PNG“, sondern dokumentiert die Eigenschaft: Farbe, Radius, Schatten, Border. Das spart Ladezeit und bleibt flexibler bei responsiven Anpassungen.
| Element | Besser als Asset | Besser als Code |
|---|---|---|
| UI-Icon | SVG, wenn simpel und wiederverwendbar | Icon-Font/Inline-SVG per Code, wenn im System verankert |
| Foto/Keyvisual | Optimiertes Bildformat (z. B. WebP in der Umsetzung) | — |
| Hintergrundfläche, Radius, Schatten | Nur bei komplexen Grafiken | CSS (flexibler, meist leichter) |
| Illustration | SVG, wenn Stil konsistent und Pfade sauber | CSS nur bei sehr einfachen Formen |
Kommentare, Doku und Entscheidungen direkt im File
Kommentare: weniger Chat, mehr Kontext
Kommentare in Figma sind am stärksten, wenn sie Entscheidungen festhalten: „Dieser CTA bleibt immer sichtbar“, „Bei Fehler: Feld rot + Text darunter“, „Auf Mobile wird die rechte Spalte unter die linke geschoben“. Unhelpful sind Kommentare, die nur „bitte bauen“ sagen.
Wichtig ist außerdem, Kommentare nach dem Klären aufzulösen. Offene Threads wirken sonst wie offene Baustellen und verunsichern bei der Umsetzung.
Mini-Doku statt langer Textwüste
Eine kurze Dokumentationsfläche im File reicht oft aus: eine Seite oder ein Frame, der die wichtigsten Regeln zusammenfasst. Dort stehen keine Romane, sondern konkrete Aussagen wie: Abstände folgen dem Spacing-System, Buttons haben definierte Zustände, Icons kommen aus dem Set X, Bilder werden als responsive Quellen eingebunden.
Kurzer Ablauf, der in Projekten zuverlässig funktioniert
Diese Schrittfolge hat sich bewährt, weil sie schnell ist und die häufigsten Rückfragen verhindert:
- „Screens“-Seite bereinigen: nur freigegebene Frames, eindeutig benannt.
- Komponenten prüfen: Varianten für wichtige Zustände ergänzen, Dubletten löschen.
- Design Handoff vorbereiten: kritische Maße, Verhalten und Inhalte sichtbar machen (nicht verstecken).
- Assets bündeln: Icons/Illustrationen als SVG nur, wenn nötig; Bilder mit klaren Crops.
- Export-Settings kontrollieren: Skalierungen, Dateinamen, Hintergrund (transparent/nicht transparent).
- Kommentare finalisieren: Entscheidungen dokumentieren, offene Threads auflösen.
- Kurzer Übergabe-Call: offene Punkte in 15 Minuten klären, danach „freeze“ (keine stillen Änderungen).
Fehler, die immer wieder passieren (und wie sie sich vermeiden lassen)
„Final“ ohne Version: was ist wirklich live?
Wenn mehrere „final“-Frames existieren, fehlt eine klare Quelle der Wahrheit. Besser: ein einziger „Ready“-Bereich plus ein Archiv. Änderungen nach der Übergabe sollten sichtbar versioniert werden (z. B. neuer Frame oder klarer Änderungsvermerk).
Uneinheitliche Komponenten durch Copy & Paste
Wenn Buttons, Inputs oder Cards mehrfach kopiert und manuell verändert werden, entstehen kleine Unterschiede: andere Radien, andere Abstände, leicht andere Farben. Das fällt oft erst spät auf. Abhilfe: konsequent mit Komponenten arbeiten und Varianten nutzen, statt Einzelteile zu duplizieren.
Zu viele Screens, zu wenig Regeln
Mehr Screens lösen nicht automatisch Unklarheiten. Oft hilft stattdessen ein klarer Satz pro Komponente: „Diese Karte ist klickbar“, „Dieses Icon ist nur dekorativ“, „Diese Liste hat eine maximale Breite“. Das reduziert Interpretationsspielraum.
Eine kleine Entscheidungshilfe für typische Handoff-Fragen
- Wenn ein Element auf vielen Seiten identisch ist: als Komponenten lösen und zentral pflegen.
- Wenn ein Detail nur im Normalzustand existiert: Zustände ergänzen oder klar dokumentieren.
- Wenn ein grafischer Effekt leicht in CSS nachbaubar ist: kein Asset exportieren, Eigenschaften angeben.
- Wenn ein Bildmotiv auf Mobile kritisch ist: Crop im Frame festlegen und Fokus klären.
- Wenn etwas „nice to have“ ist: Priorität als Kommentar notieren, damit es nicht als Muss umgesetzt wird.
Wer zusätzlich verhindern will, dass kleine UI-Probleme erst nach dem Launch auffallen, kann vor der Übergabe noch einen kurzen Qualitätscheck einplanen. Als Ergänzung passt Webdesign-Fehler finden: UI-Checks vor dem Launch.
Figma Specs sind am Ende kein Selbstzweck, sondern ein Übersetzungswerkzeug: vom Design zu verlässlicher Umsetzung. Eine klare Struktur, wenige, gute Assets und gut platzierte Entscheidungen sparen mehr Zeit als jede zusätzliche Detaildiskussion.
