Design-Engineering-Übergaben jenseits von Figma-Kommentaren
Warum Figma-Kommentare allein die Übergabelücke im Design-Engineering nicht schließen können – und was für kleine Teams wirklich funktioniert.
By Ellis Keane · 2026-04-06
Das beste Design-Engineering-Übergabewerkzeug ist eines, das Ingenieure nie öffnen
Je mehr Designer in die Perfektionierung ihrer Figma-Übergabe investieren – Auto-Layout, Design-Tokens, Dev-Mode-Annotierungen, Komponentendokumentation –, desto schlechter wird die tatsächliche Design-Engineering-Übergabe oft. Nicht weil die Design-Arbeit schlecht ist – sie ist meistens brillant –, sondern weil all diese Mühe in einem Tool steckt, das Ingenieure widerwillig öffnen, schnell überfliegen und dann schließen, um das zu bauen, was sie gesehen zu haben glauben.
Ich war auf beiden Seiten davon. Ich begann als Designer (naja, „Designer" – ich baute Pfandleiher-Websites in New Hampshire, also seien wir großzügig mit dem Titel) und schreibe jetzt den Großteil des Engineering-Codes für Sugarbug. Das Problem bei der Design-Engineering-Übergabe ist kein Tool-Problem – es ist ein Workflow-Problem. Die Informationen sind vorhanden, sie befinden sich nur zum falschen Zeitpunkt am falschen Ort.
Eine typische Design-Engineering-Übergabe sieht etwa so aus: Ein Designer verbringt drei Tage damit, einen Figma-Frame zu polieren, fügt zwölf Kommentare hinzu, die Abstands-Entscheidungen und Edge-Cases erklären, markiert den Ingenieur und wartet dann. Der Ingenieur öffnet Figma, schaut etwa neunzig Sekunden auf den Frame, denkt „okay, hab's" und schließt den Tab. Dann baut er etwas, das zu 80 % korrekt und zu 20 % falsch ist – auf eine Weise, die eine weitere Woche Hin-und-Her benötigt, um sie zu lösen. Die zwölf Kommentare? Davon wurden vielleicht vier gelesen.
Eine Design-Engineering-Übergabe ist keine Datei, die man über eine Mauer wirft. Es ist Kontext, der dort leben muss, wo der Ingenieur arbeitet – im Issue, im PR, im Code –, nicht in einem Design-Tool, das er nur einmal besucht.
Warum Figma-Kommentare die falsche Form für Übergaben sind
Ich nutze Figma täglich und mag es wirklich (was an diesem Punkt wahrscheinlich ein Persönlichkeitsfehler ist). Aber Figma-Kommentare sind für die Zusammenarbeit zwischen Designern optimiert – nicht für die Design-Engineering-Übergabe – und dieser Unterschied ist wichtiger, als die meisten Teams erkennen.
Der grundlegende Mismatch ist dieser: Figma-Kommentare sind räumlich an Frames und Komponenten verankert. Sie existieren innerhalb einer Design-Datei. Aber Ingenieure arbeiten nicht in Design-Dateien – sie arbeiten in Linear-Issues, GitHub-PRs und ihrer IDE. Wenn ein Designer einen Kommentar auf einem Frame hinterlässt, der besagt „Dieses Dropdown soll bei mobilen Viewports unter 640px eingeklappt werden", steckt diese Information jetzt in Figma. Sie wird nicht zur Aufgabe. Sie erscheint nicht im Workflow des Ingenieurs. Sie existiert in einem Paralleluniversum, das der Ingenieur sich merken muss zu besuchen, und (hier ist der Teil, der tatsächlich wichtig ist) Figma zu öffnen ist nicht Teil des natürlichen Arbeitsrhythmus eines Ingenieurs – so wie das Prüfen von Linear oder das Reviewen von PRs es ist.
Das Ergebnis ist vorhersehbar: Kritische Design-Entscheidungen gehen verloren – nicht weil jemand unachtsam ist, sondern weil die Information im falschen Tool steckt. Es ist wie ein Post-it auf dem Schreibtisch von jemandem zu hinterlassen, der von zu Hause aus arbeitet.
Wo Designer Kontext hinterlassen
- Figma-Kommentare – Räumlich, an Frames verankert
- Figma Dev-Mode-Annotierungen – Detailliert, erfordern aber das Öffnen von Figma
- Slack-Threads – Gesprächig, nach einer Woche nicht mehr durchsuchbar
- Design-System-Dokumentation – Umfassend, aber selten mitten im Sprint konsultiert
Wo Ingenieure tatsächlich nachschauen
- Linear-Issue-Beschreibung – Das Erste, was sie vor dem Start lesen
- GitHub-PR-Beschreibung – Referenz während der Implementierung
- Code-Kommentare – Beim Review entdeckt
- IDE – Wo sie 90 % ihrer Zeit verbringen
Was tatsächlich funktioniert (von jemandem, der beides macht)
Im vergangenen Jahr beim Aufbau von Sugarbug war ich Designer und (meistens) Ingenieur, was bedeutet, dass ich die ungewöhnliche Erfahrung gemacht habe, an mich selbst zu übergeben und trotzdem Kontext zu verlieren. Wenn ich mich nicht an meine eigenen Design-Entscheidungen von letzten Dienstag erinnern kann, wird ein separater Ingenieur unmöglich alles aus einem Figma-Kommentar-Thread mitnehmen.
Hier ist, was für den Design-Engineering-Übergabeprozess unseres Teams tatsächlich funktioniert hat – und nichts davon beinhaltet, bessere Figma-Kommentare zu schreiben.
1. Schreiben Sie die Design-Entscheidung in das Issue, nicht in die Design-Datei
Bevor ein Ingenieur mit dem Bauen beginnt, muss der Design-Kontext im Linear-Issue leben (oder was auch immer Ihr Team verwendet). Kein Link zur Figma-Datei mit „Designs ansehen" – das ist eine Ausrede, und jeder weiß es. Das Issue sollte Folgendes enthalten:
- Was: Einen Screenshot oder exportierten Frame (kein Figma-Link – ein PNG, das der Ingenieur sehen kann, ohne ein weiteres Tool zu öffnen)
- Warum: Die Begründung hinter den wesentlichen Entscheidungen. „Wir haben uns für ein Slide-over-Panel statt ein Modal entschieden, weil der Nutzer beim Bearbeiten die Liste referenzieren muss" – ein Satz, der drei Runden „Warum kein Modal?" erspart
- Edge-Cases: Was passiert auf Mobilgeräten? Was passiert bei langem Text? Was passiert, wenn keine Daten vorhanden sind? Wenn Sie darüber nachgedacht haben, schreiben Sie es auf. Wenn nicht, sagen Sie es (ehrlich gesagt ist „Ich hab den Leerzustand noch nicht herausgefunden" nützlicher als Schweigen)
2. Design-Reviews finden im Issue statt, nicht in Figma
Wenn ich Design-Feedback während der Implementierung bekomme, möchte ich es im Linear-Issue-Thread – nicht als Figma-Kommentar, den ich vielleicht zwei Tage lang nicht sehe. Das Issue ist meine einzige Wahrheitsquelle für die Arbeit – wenn Feedback dort steht, sehe ich es beim nächsten Prüfen des Issues, was mehrmals täglich passiert. Wenn es in Figma steht, sehe ich es, wann immer ich diese Datei öffne – was vielleicht nie ist.
Das bedeutet nicht, dass Figma-Kommentare nie verwendet werden sollten. Sie sind großartig für die Designer-zu-Designer-Zusammenarbeit, zum Annotieren spezifischer visueller Details und für Gespräche über das Design selbst. Aber sobald Feedback bedeutet „der Ingenieur muss etwas ändern", muss es in den Engineering-Workflow übergehen.
stat: "Die meisten" headline: "Figma-Kommentare blieben über 48 Stunden ungesehen, als wir uns für Übergaben auf sie verließen" source: "Erfahrung unseres Teams über 3 Monate informelles Tracking"
3. Schließen Sie die Lücke mit Screenshots, nicht mit Annahmen
Die günstigste Form der Validierung einer Design-Engineering-Übergabe ist ein Screenshot. Wenn ein Ingenieur mit der Implementierung einer Komponente fertig ist, fügt er einen Screenshot in den PR oder das Issue ein und markiert den Designer. „Stimmt das so überein?" dauert zehn Sekunden und fängt die 20 % Abweichung ab, bevor es ausgeliefert wird. Kein Meeting, kein Figma-Vergleichsritual – nur ein PNG und eine Frage.
Wir haben damit begonnen, das für jeden UI-PR zu tun, und die Anzahl der „Das stimmt nicht mit dem Design überein"-Gespräche sank auf nahezu null. Die verbleibenden Gespräche sind echte Edge-Cases, die das Design nicht abgedeckt hat – das ist in Ordnung. Das ist die Art von Sache, die besprochen werden sollte, nicht das grundlegende „Sie haben 16px Padding statt 12px verwendet"-Zeug.
4. Lassen Sie Kontext automatisch zwischen Tools fließen
Hier werde ich Sugarbug erwähnen, weil wir es buchstäblich gebaut haben, um dieses spezifische Problem zu lösen. Unser Designer hinterlässt einen Kommentar in Figma über eine Abstandsänderung. Sugarbug nimmt diesen Kommentar auf, verknüpft ihn mit dem relevanten Linear-Issue und GitHub-PR, und der Ingenieur sieht ihn in seinem Workflow, ohne Figma zu öffnen. Die Design-Engineering-Übergabe hört auf, ein manuelles Kopier-Einfüge-Ritual zu sein, und wird zu etwas, das einfach passiert.
Aber wenn Sie Sugarbug nicht verwenden (und die meisten von Ihnen tun das nicht – wir sind noch vor dem Launch), ist die manuelle Version: Weisen Sie jemanden als „Übergabe-Brücke" zu, der täglich Figma-Kommentare prüft und relevantes Feedback in Linear-Issues kopiert. Es ist mühsam, aber es funktioniert, und es ist unendlich besser, als zu hoffen, dass Ingenieure daran denken, Figma zu prüfen.
Wenn ich mich nicht an meine eigenen Design-Entscheidungen von letzten Dienstag erinnern kann, wird ein separater Ingenieur unmöglich alles aus einem Figma-Kommentar-Thread mitnehmen. attribution: Chris Calo
Ihre Design-Engineering-Übergabe-Checkliste
Wenn Sie nur eine Sache aus diesem Artikel mitnehmen, dann diese: Die Lösung sind nicht bessere Tools (naja, nicht hauptsächlich – obwohl ich eines baue, also nehmen Sie das mit Vorbehalt). Die Lösung besteht darin, Normen dafür zu etablieren, wo Design-Entscheidungen leben, und sicherzustellen, dass dieses „Wo" innerhalb des natürlichen Workflows des Ingenieurs liegt.
- [ ] Exportieren Sie wesentliche Frames als PNGs in das Linear-Issue (nicht nur als Figma-Link)
- [ ] Schreiben Sie das „Warum" für jede wesentliche Design-Entscheidung in die Issue-Beschreibung
- [ ] Listen Sie bekannte Edge-Cases auf (Mobil, Leerzustände, langer Text) – oder markieren Sie explizit, was Sie noch nicht gelöst haben
- [ ] Verschieben Sie Implementierungs-Feedback von Figma-Kommentaren in den Issue-Thread
- [ ] Verlangen Sie einen Screenshot in jedem UI-PR vor der Design-Freigabe
- [ ] Weisen Sie eine „Übergabe-Brücke"-Person zu, wenn Sie kein Tooling haben, um Figma und Linear automatisch zu verbinden
Häufig gestellte Fragen
Q: Warum scheitern Figma-Kommentare als Design-Engineering-Übergabewerkzeug? A: Figma-Kommentare befinden sich in der Design-Datei, losgelöst vom Engineering-Workflow. Ingenieure arbeiten in Linear, GitHub und ihrer IDE – nicht in Figma. Ein Kommentar auf einem Frame wird nicht zur Aufgabe, es sei denn, jemand kopiert ihn manuell, und genau dieser manuelle Schritt ist, wo die Design-Engineering-Übergabe scheitert. Es ist kein Menschen-Problem, es ist ein Tool-Grenz-Problem.
Q: Verbindet Sugarbug Figma-Kommentare automatisch mit Linear-Issues? A: Ja – das ist eines der spezifischen Probleme, für deren Lösung wir es gebaut haben. Sugarbug liest Figma-Kommentare aus und verknüpft sie mit relevanten Linear-Issues und GitHub-PRs, sodass Design-Feedback im Workflow des Ingenieurs erscheint, ohne dass jemand zwischen Tools kopieren muss. Wir verwenden es selbst täglich, und der Unterschied ist (ehrlich gesagt) etwas peinlich angesichts der Einfachheit der Idee.
Q: Was ist der beste Design-Engineering-Übergabeprozess für kleine Teams? A: Schreiben Sie die Design-Entscheidung in das Linear-Issue, bevor der Ingenieur mit dem Bauen beginnt. Fügen Sie die Begründung ein, nicht nur das Visuelle. Wenn beim Entwickeln Edge-Cases auftauchen, besprechen Sie diese im Issue-Thread – nicht in einem Figma-Kommentar, den der Ingenieur erst suchen muss. Der einfachste Prozess ist oft der haltbarste.
Q: Wie geht man mit Design-Änderungen um, nachdem das Engineering begonnen hat? A: Behandeln Sie sie wie Scope-Änderungen: Dokumentieren Sie die Änderung im Issue mit einem klaren Vorher-und-Nachher, erläutern Sie die Begründung und lassen Sie den Ingenieur die Implementierungskosten einschätzen, bevor er sich festlegt. Die schlimmsten Übergabefehler passieren, wenn Design-Änderungen als beiläufige Figma-Kommentare zu bereits fertig gebauter Arbeit eintreffen – so entstehen verärgerte Ingenieure und frustrierte Designer.
Erhalten Sie Signalintelligenz direkt in Ihren Posteingang.