Ein Entwickler schreibt Ihnen an einem Dienstagmorgen um 8:00 Uhr. Er hat gerade vier Stunden damit verbracht, ein Modal zu codieren – nur um festzustellen, dass er es auf Basis einer Entwurfsseite namens „Exploration_v3_temp“ statt der freigegebenen Version gebaut hat.
Das passiert, wenn wir das Handoff wie eine Räumungsklage behandeln. Wir packen unsere Entwürfe zusammen, werfen sie über den Zaun und hoffen, dass das Entwicklerteam schon irgendwie damit klarkommt. Bei Northwind Studio haben wir früh gelernt, dass eine unordentliche Figma-Datei wie eine offene Rechnung ist, die irgendwann beglichen werden muss. Wenn sich Ihre Entwickler davor scheuen, Ihre Links zu öffnen, ist es an der Zeit, die Art und Weise zu ändern, wie Sie Ihre Dateien aufbauen und übergeben.
Das Handoff ist ein Gespräch, keine reine Übergabe
Ein Design einfach über die Mauer zu werfen und anzunehmen, die Arbeit sei getan, ist ein Rezept für fehlerhafte Layouts und frustrierte E-Mails. Ein gutes Handoff entsteht nicht in einem einzigen Meeting am Ende eines Sprints. Es entsteht, wenn Design und Entwicklung vom ersten Tag an eine gemeinsame Sprache sprechen.
Wenn wir ein Projekt starten, holen wir die Entwickler in die Datei, noch bevor wir High-Fidelity-Mockups haben. Wir möchten, dass sie die Wireframes sehen – um die Layout-Logik zu hinterfragen und potenzielle technische Hürden frühzeitig zu erkennen. Diese kontinuierliche Partnerschaft sorgt dafür, dass die Entwickler bei der offiziellen Übergabe bereits genau wissen, wie die Anwendung funktionieren soll. Sie haben bereits Feedback zu den komplexeren Interaktionen gegeben und wissen genau, wo sie die finale Version finden.
Strukturieren Sie Ihre Figma-Dateien für menschliche Augen
Ein Entwickler sollte in der Lage sein, Ihre Figma-Datei zu öffnen und innerhalb von fünf Sekunden den Status jedes einzelnen Screens zu verstehen. Wenn geraten werden muss, welcher Frame bereit für die Entwicklung und welcher ein halbgahrer Entwurf ist, funktioniert das System nicht.
Wir organisieren unsere Figma-Seitenleiste mit klaren, vorhersehbaren Seitenstrukturen. Wir nutzen Emojis als visuelle Wegweiser, um aktive Arbeit von freigegebenen Spezifikationen zu trennen.
Hier ist ein realistisches Beispiel dafür, wie wir eine typische Projektdatei strukturieren:
--- 🟢 BEREIT FÜR DEV ---💻 Desktop - Dashboard📱 Mobil - Dashboard--- 🟡 IN ARBEIT ---🧪 Layout-Entwürfe🎨 Marken-Assets & Moodboards--- 🔴 ARCHIV ---📦 Alte Iterationen
Innerhalb der „Bereit für Dev“-Seiten ordnen wir die Frames von links nach rechts und von oben nach unten an, dem User Flow folgend. Wir nutzen auch das Sektions-Tool von Figma, um zusammengehörige Screens zu gruppieren, und versehen die gesamte Sektion mit dem Status-Badge „Ready for development“. Dieser einfache visuelle Hinweis signalisiert dem Entwickler, dass diese Designs final und bereit für die Umsetzung sind.
Benennen Sie Komponenten wie ein Entwickler, nicht wie ein Künstler
Wenn Ihre Figma-Datei voller Ebenen mit Namen wie „Gruppe 412“, „Rechteck 12“ oder „Button-Neu-Final-v2“ ist, verlangen Sie von den Entwicklern eine Übersetzungsarbeit, die nicht ihre Aufgabe sein sollte. Ihre Designkomponenten sollten die Struktur des tatsächlichen Codes widerspiegeln.
Anstatt Elemente danach zu benennen, wie sie aussehen, benennen Sie sie danach, was sie tun und wo sie hingehören. Nutzen Sie systematische, durch Schrägstriche getrennte Namenskonventionen, die zu modernen Frontend-Frameworks passen.
Nennen Sie eine Button-Variante beispielsweise nicht Red-Button-Large. Nutzen Sie stattdessen ein strukturiertes System:
Button / Primary / Danger / Large
Wenn Sie eine strukturierte Benennung und die Komponenteneigenschaften von Figma nutzen, sprechen Sie dieselbe Sprache wie das Entwicklerteam. Wenn ein Entwickler eine Komponente inspiziert, sieht er Eigenschaften, die direkt mit seinen React- oder Vue-Props übereinstimmen. Das verhindert Rätselraten und sorgt für ein konsistentes UI im Design-File und in der Live-Anwendung.
Wissen, was man nicht auf den Pixel genau ausrichten muss
Statische Designs sind eine Illusion. Eine Website ist kein Poster – sie dehnt sich, schrumpft und passt sich an den Viewport des Nutzers, die Browsereinstellungen und die Schriftpräferenzen an. Wenn Sie Stunden damit verbringen, einzelne Pixelwerte auf einem statischen 1440px-Frame zu optimieren, verschwenden Sie Zeit mit Details, die in der Realität ohnehin anders aussehen werden.
Konzentrieren Sie sich lieber darauf, die Regeln des Systems zu definieren, anstatt statische Frames pixelgenau auszurichten.
- Nutzen Sie Auto-Layout für alles: Zeichnen Sie keine manuellen Boxen für Buttons oder Karten. Nutzen Sie das Auto-Layout von Figma, um Padding, Abstände und Ausrichtung zu definieren. Wenn sich die Beschriftung eines Buttons von „Senden“ zu „Konto erstellen“ ändert, sollte der Button automatisch mitwachsen.
- Definieren Sie Constraints und Resizing-Regeln: Zeigen Sie den Entwicklern, wie sich Elemente verhalten sollen, wenn sich die Bildschirmgröße ändert. Soll eine Karte den Container ausfüllen oder eine feste Breite behalten?
- Dokumentieren Sie die Grenzfälle: Was passiert mit einem Textblock, wenn der Text drei Zeilen länger ist als erwartet? Wird er mit Auslassungspunkten abgeschnitten oder schiebt er den Inhalt darunter nach unten? Designer sollten das Verhalten des Systems gestalten, nicht nur den Idealzustand.
Sprechen Sie dieselbe Sprache mit Design-Tokens
Die häufigste Ursache für Reibungen zwischen Design und Entwicklung ist die Verwendung willkürlicher Werte. Wenn ein Screen einen #F3F4F6-Hintergrund nutzt und ein anderer #F9FAFB, nur weil ein Designer die Pipette benutzt hat, wird der Code schnell unübersichtlich und inkonsistent.
Design-Tokens lösen dieses Problem, indem sie rohe Hex-Codes, Schriftgrößen und Pixelwerte durch benannte Variablen ersetzen. Anstatt einem Entwickler zu sagen, er soll #3B82F6 für einen Link verwenden, sagen Sie ihm, er soll den Token color-brand-primary nutzen.
Unsere Design-Systeme enthalten entwicklungsbereite Tokens direkt in den Dateien. So wird sichergestellt, dass Variablen in Figma direkt mit den CSS-Variablen in Ihrem Code übereinstimmen. Dieser Ansatz garantiert: Wenn Sie jemals die Primärfarbe Ihrer Marke aktualisieren müssen, ändern Sie sie in einer zentralen Token-Datei. Die Aktualisierung überträgt sich ohne manuelle Code-Anpassungen auf die Design-Bibliothek und die Live-Website.
Klare Grenzen und Feedbackschleifen etablieren
Selbst mit einer perfekten Dateistruktur und einem robusten Token-System werden in der Entwicklungsphase Fragen auftauchen. Sie benötigen einen klaren Prozess für Feedback und späte Änderungen, ohne Chaos im Code zu verursachen.
Wir führen eine strikte „Freeze“-Regel ein, sobald ein Design in den Bereich „Bereit für Dev“ verschoben wurde. Wenn ein Kunde während der Entwicklung eine Änderung wünscht, bearbeiten wir nicht direkt den aktiven Frame. Stattdessen duplizieren wir den Frame in unseren Bereich „In Arbeit“, nehmen die Anpassungen vor und besprechen die Änderungen zuerst mit dem Entwickler. Nach der Freigabe tauschen wir die Frames aus und dokumentieren die Änderung in einem Versionsprotokoll oder einem einfachen Figma-Kommentar.
Die Nutzung des Dev-Mode von Figma hilft Entwicklern zudem, Layouts zu inspizieren, Abstände zu messen und CSS-Code zu kopieren, ohne versehentlich Ebenen zu verschieben oder Schriftstärken zu ändern. Indem Sie diese Grenzen respektieren, schützen Sie den Fokus der Entwickler und stellen sicher, dass das Endprodukt genau wie das freigegebene Design aussieht.
Wir glauben, dass sich großartige Design-Systeme dadurch auszeichnen, wie gut sie gebaut sind – nicht nur dadurch, wie gut sie in einer Präsentation aussehen. Wenn Sie die Design-Prozesse Ihres Teams optimieren und ein konsistentes visuelles System aufbauen möchten, das Ihr Entwicklerteam gerne nutzt, helfen wir Ihnen gerne dabei, die Strukturen, Tokens und Workflows dafür einzurichten.
FAQs
Wie geht man mit responsiven Design-Spezifikationen um, ohne jede Bildschirmgröße zu gestalten?
Sie müssen nicht für jeden Viewport designen. Gestalten Sie stattdessen die minimalen und maximalen Breakpoints, nutzen Sie das Auto-Layout von Figma, um zu zeigen, wie sich Elemente dehnen oder schrumpfen, und dokumentieren Sie das Umbruchverhalten für mittlere Bildschirmgrößen.
Wie markiert man ein Design in Figma am besten als „bereit für die Entwicklung“?
Nutzen Sie eine eigene Sektion oder Seite „Bereit für Dev“ in Ihrer Figma-Datei und markieren Sie die freigegebenen Frames mit den integrierten Status-Badges von Figma. Lassen Sie Entwickler niemals auf einer Seite arbeiten, die aktive Entwürfe oder Experimente enthält.
Sollten Designer codieren lernen, um den Handoff-Prozess zu verbessern?
Designer müssen keinen produktionsreifen Code schreiben, aber sie sollten verstehen, wie der Browser funktioniert. Die Grundlagen des CSS-Box-Modells, Flexbox und Grid zu kennen, hilft Ihnen, Layouts zu entwerfen, die technisch machbar und einfach umzusetzen sind.
Wie dokumentiert man Mikrointeraktionen und Animationen für Entwickler?
Nutzen Sie Figma-Prototypen, um den Ablauf zu zeigen, aber ergänzen Sie diese durch schriftliche Spezifikationen oder einfache Bildschirmaufnahmen. Dokumentieren Sie die genauen Timing-Kurven, Verzögerungen und Trigger-Zustände, damit Entwickler die Animationswerte nicht erraten müssen.