Hör auf, in Figma zu designen

Deine Figma-Datei ist ein statisches Foto eines Produkts, das nicht existiert. Bis der Engineer es ausliefert, ist sie schon falsch. Die Schriften rendern anders, die Breakpoints, die du ignoriert hast, tauchen auf, der Empty State, den du vergessen hast, erscheint, und der Hover, den du als Kommentar skizziert hast, wird von jemandem interpretiert, der nicht du ist. Die Lösung sind nicht bessere Figma-Plugins. Die Lösung ist, Figma nicht mehr als Designtool zu nutzen und stattdessen die Codebasis zu verwenden.

Das ist kein Figma-Verriss. Figma gewinnt weiterhin bei Systemarbeit, Markenexploration und FigJam-Diagrammen. Die These ist enger und härter. 2026 passiert Produktdesign im Code. v0, Cursor, Lovable und die Vercel-UI-Registry haben das Artboard als den Ort abgelöst, an dem Oberflächen tatsächlich gestaltet werden. Designer, die weiterhin pixelperfekte Figma-Frames liefern, die Engineers dann „umsetzen“, machen zwei Jobs mit halber Geschwindigkeit.

Was sich tatsächlich geändert hat

Figma wurde für eine Ära gebaut, in der die Produktion der Engpass war. 2018 brauchte ein Engineer drei Tage für eine funktionierende React-Komponente, und ein Designer schaffte im selben Zeitraum zwanzig Hi-Fi-Frames. Flache Artboards als Ergebnis zu liefern, war der rationale Zug. Das Artboard war der schnellste Teil der Pipeline.

Diese Rechnung hat sich 2026 umgedreht. v0 macht aus einem Satz in dreißig Sekunden eine funktionierende Komponente. Cursor bearbeitet ein echtes Repo mit einem echten Diff. Lovable stellt aus einem einzigen Prompt eine deploybare App hin. Das Artboard ist jetzt der langsamste Teil der Pipeline, nicht der schnellste, und die Lücke wächst jedes Quartal. Die tiefere Analyse der Verschiebung auf Artefakt-Ebene steht in Der Tod des Mockups. Dieser Text handelt vom Werkzeug, das das Artefakt erzeugt.

Der flache Frame ist nicht schlechter geworden. Die Werkbank ist besser geworden.

Wo Figma sich weiterhin lohnt

Sei ehrlich. Figma ist bei vier Aufgaben hervorragend, und wer das leugnet, sorgt dafür, dass der Rest des Arguments abgetan wird.

Figma gewinnt weiterhin bei der Exploration von Markenidentität, wo Logos, Schriftstudien und Farbsysteme leben, bevor es überhaupt eine Codebasis gibt. Es gewinnt bei Inventaren von Designsystemen, der einen Datei, die jeden Token, jede Variante und jeden Zustand auflistet, mit einem Multiplayer-Modell, das nichts anderes nachbaut. Es gewinnt bei FigJam-Diagrammen und Team-Alignment, beim Whiteboarding und Journey Mapping, wo die Oberfläche das Gespräch ist. Und es gewinnt weiterhin für Designer, die wirklich keinen Code lesen können, eine Rolle, die 2026 seltener ist, als die Branche behauptet, aber real.

Alles andere, jede Produktoberfläche, die bei echten Nutzern landet, gehört in den Code.

Die fünf Unterschiede

In Figma zu designen und im Code zu designen ist nicht derselbe Job in unterschiedlicher Geschwindigkeit. Es sind verschiedene Jobs.

Fidelity. Ein Figma-Frame nähert Typografie an, ignoriert Hover, fälscht Scrollen und rendert Schriften, die der Browser nicht genauso laden würde. Eine Code-Oberfläche nutzt die echte Schrift, die echte Button-Komponente, den echten Breakpoint, den echten Focus Ring. Die Lücke zwischen Annäherung und Realität war früher akzeptabel. In einem Produkt, in dem Lade-, Leer- und Langinhalt-Zustände die halbe Gestaltung ausmachen, ist sie es nicht mehr.

Geschwindigkeit. Der Figma-Loop ist: Frame bearbeiten, Engineer kommentieren, warten, Build prüfen, wieder kommentieren, wieder warten. Der Code-Loop ist: bearbeiten, neu laden, sehen. Der erste läuft in Tagen, der zweite in Sekunden. Die Iterationsgeschwindigkeit entscheidet, wie viele Ideen das Team vor dem Launch testen kann.

Kollaborationsmodell. Figma-Kommentare und PR-Kommentare sind unterschiedliche Oberflächen. Figma-Kommentare gehen von Designer an Stakeholder und von Designer an Engineer als Spezifikation. PR-Kommentare sind Designer und Engineer als Peers an einem einzigen Artefakt. Das zweite Modell fahren Design-Engineering-Teams, und es ist strukturell schneller.

Das Handoff verschwindet. Das Handoff ist der teuerste Moment in der traditionellen Pipeline. Im Code zu designen löscht es. Es gibt keinen Übersetzungsschritt, weil das Design die Implementierung ist.

Edge Cases zeigen sich sofort. Leer, Laden, langer Inhalt, Mobile, Fehler, langsames Netzwerk. In Figma existieren sie, wenn der Designer daran gedacht hat, sie zu zeichnen. Im Code existieren sie, ob der Designer daran gedacht hat oder nicht, weil die Komponente sie handhaben muss, um zu rendern. Code erzwingt Ehrlichkeit.

v0, Cursor, Lovable und Vercel UI sind die neue Designoberfläche

Die neue Designumgebung ist nicht ein Tool, sondern ein Stack, der gleichzeitig kritische Masse erreicht. Jedes dieser Tools übernimmt eine Schicht dessen, was Figma früher allein erledigte.

v0 von Vercel macht aus einem Prompt in etwa dreißig Sekunden eine funktionierende React- und Tailwind-Komponente. Das Ergebnis forken, per Prompt oder von Hand iterieren, in die Codebasis ausliefern. Das Fork-and-Iterate-Modell ersetzt das Duplizieren und Anpassen aus Figma, nur dass das Duplikat echter Code ist.

Cursor ist die Designoberfläche für Produktdesigner, die Code lesen können. Das echte Repo öffnen, das echte Rendering sehen, eine Komponente per Prompt oder von Hand bearbeiten und die Änderung in derselben Minute im Browser sehen.

Lovable ist die Oberfläche für Gründer und Solo-Designer. Ein Prompt, eine funktionierende Web-App, dann am laufenden Ding iterieren. Der schnellste Weg von der Absicht zu einer Live-URL, ganz ohne Figma-Datei.

Vercel UI und die shadcn-Registry sind das Komponentenregal. Eine echte Komponente ziehen, in der Codebasis anpassen, ausliefern. shadcn liefert Komponenten als Code, der dir gehört, was bedeutet, dass das Designsystem auf derselben Oberfläche editierbar ist wie das Design.

Die Tools unterscheiden sich in der Form, teilen aber dieselbe Idee. Die laufende Oberfläche ist das Artefakt. Das Artboard ist ein Entwurf, falls es überhaupt existiert. Für das tiefere Praxismuster siehe Vibe Coding für Designer und Claude Code für Designer.

Wie Linear, Stripe und Anthropic tatsächlich arbeiten

Die Teams, die 2026 die beste Produkt-UI ausliefern, teilen eine Workflow-Form, und keines von ihnen liefert Figma als finales Ergebnis.

Linear behandelt die Codebasis als Single Source of Truth. Das Design-Engineering-Team bringt Designs als Pull Requests gegen die laufende App ein, nicht als Figma-Frames. Das Designsystem von Stripe wird aus Code gebaut und ausgeliefert. Figma existiert als Dokumentation stromabwärts vom Code, nicht als Quelle stromaufwärts. Das System zu ändern heißt, den Code zu ändern. Anthropic designt Claude-Produktoberflächen inline, in React-Komponenten und Claude Artifacts, wobei Designer bei jedem Release die echte App lesen und bearbeiten.

Das Muster wiederholt sich in jedem Produktteam, das mit Premium-Tempo ausliefert. Tokens stromaufwärts, Code als Canvas, KI als Produktionsschicht, Designer im Diff. Die Pipeline aus flachen Frames ist bei keinem von ihnen die Arbeitsweise, und die Rechnung hat den Rest der Branche eingeholt.

Fünf Fragen, bevor du im Code designst

Nicht jeder Designer sollte Figma morgen fallen lassen. Der ehrliche Test sind fünf Fragen. Wenn drei oder mehr Antworten Ja lauten, ist Design im Code die richtige Oberfläche für das nächste Projekt.

1. Lieferst du die Arbeit aus oder gibst du sie ab? Wenn du auslieferst, gewinnt Code. Wenn du abgibst, gewinnt Code trotzdem, aber der kulturelle Sprung ist größer.
2. Kannst du die Codebasis lesen? Nicht Produktions-React von Grund auf schreiben, nur Komponenten lesen, Props verstehen, einen Design Token erkennen und Werte ändern, ohne den Build zu brechen.
3. Ist das Design eine statische Spezifikation oder eine interaktive Oberfläche? Eine Spezifikation gehört in Figma. Eine Oberfläche mit Hover, Fokus, Scroll, Motion und Edge States gehört in den Code.
4. Hat das Team ein Designsystem, das es erweitern kann? Eine echte Komponentenbibliothek, selbst eine shadcn-Basis, macht Code-First-Design um zwei Größenordnungen schneller als Figma.
5. Ist die Iterationsgeschwindigkeit dein Engpass? Wenn du Sprints an den Handoff-Zyklus verlierst, beseitigt Code-First den Engpass. Wenn du Sprints an Markenstrategie verlierst, bringt Code-First nichts. Löse das richtige Problem.

Ein Team, das vier von fünf trifft, lebt im Code. Ein Team, das zwei von fünf trifft, sollte die Arbeit trotzdem zwischen Figma und Code aufteilen, mit leichter Tendenz zum Code bei jedem neuen Projekt.

Anti-Patterns, die du fallen lassen solltest

Vier Muster töten mehr ausgelieferte Produkt-UI als jede Toolwahl. Wenn ein Team eines davon praktiziert, zählt der Workflow-Wechsel mehr als der Tool-Wechsel.

Die Dev-Mode-als-Handoff-Fantasie. Der Designer liefert eine Figma-Datei voller roter Linien. Der Engineer „nutzt den Dev Mode“, um zu übersetzen. Beide tun so, als wäre die Übersetzung treu. Das ist sie nie. Dev Mode ist nützlich, aber es ist dieselbe Handoff-Fantasie in neuer Verpackung. Die echte Lösung ist, dass Engineer und Designer dasselbe Artefakt bearbeiten, und genau das ermöglichen Code-Oberflächen. Für die Verbindungsschicht siehe den Figma-MCP-Guide.

Das pixelperfekte Mock, das echte Schriften und Breakpoints ignoriert. Ein Frame bei 1440px mit Lorem Ipsum und einer Schrift, die die Produktions-App gar nicht lädt. Das Mock sieht pixelperfekt aus, das ausgelieferte Produkt sieht völlig anders aus, und alle haben die Lüge abgenickt.

Das Designsystem, das in Figma lebt und stillschweigend vom Code abdriftet. Die Figma-Bibliothek sagt, der Button hat 12px Padding. Der Code sagt 14px. Niemand hat eines von beidem aktualisiert. Nach sechs Monaten ist die Figma-Datei Fiktion. Eine Source of Truth, im Code, mit Figma als nachgelagertem Render.

Das sechsmonatige Redesign, das als PDF ausgeliefert wird. Ein Flaggschiff-Redesign, geliefert als hundertseitiger Figma-Export, der Geschäftsführung präsentiert und für „Phase zwei“ an die Entwicklung übergeben. Phase zwei findet nicht statt, weil das Unternehmen die Strategie zweimal gewechselt hat, bis die Entwicklung den Umbau eingeschätzt hat. Das Redesign, das nicht ausgeliefert wird, hat nie existiert.

Das Code-First-Design-Audit

Bevor das nächste Projekt startet, mach das Audit. Sieben Fragen, zehn Minuten, klare Antworten.

1. Was ist das Ergebnis, ein Frame oder eine ausgelieferte Oberfläche? Wenn ausgeliefert, ist das Ergebnis Code. Hör auf, so zu tun, als wäre der Frame das Produkt.
2. Wem gehört die laufende App, und ist der Designer im Diff? Wenn der Designer nicht im Diff ist, behebe das, bevor du Tools wechselst.
3. Wo leben die Tokens? Wenn die Antwort Figma lautet, zieh sie um. Die Token-Datei sollte die Source of Truth sein, die Figma liest, nicht umgekehrt. Der Beitrag zum KI-Design-Workflow beschreibt den Upgrade-Pfad.
4. Wie lang ist der Iterationszyklus in Stunden? Wenn es mehr als vier Stunden von der Änderung bis zur ausgelieferten Änderung sind, ist der Workflow das Problem, nicht das Design.
5. Welche Oberflächen werden noch auf flachen Artboards designt, und welche sind in den Code gewandert? Kartiere die Aufteilung. Sie sollte bei jeder neuen Initiative zum Code tendieren.
6. Auf welche Plugins verlässt sich das Team, um Handoff-Treue vorzutäuschen? Wenn die Antwort „viele“ lautet, sieh dir die Figma-Plugins, die es wert sind, behalten zu werden an und streich den Rest.
7. Was liefert das Team nächstes Quartal aus, das beweist, dass der Workflow funktioniert? Keine Folie, sondern eine deployte Oberfläche. Wenn die Antwort schwammig ist, hat sich der Workflow noch nicht wirklich geändert.

Ein Workflow, der das Audit übersteht, liefert Produkt. Ein Workflow, der es nicht übersteht, liefert Decks. Der Unterschied potenziert sich jedes Quartal, und Geschwindigkeit ist die Marke, wenn alle anderen Variablen ungefähr gleich sind.

FAQ

Ist Figma tot?

Nein. Figma ist nicht tot, und die These lautet nicht „Figma ist tot“. Figma ist hervorragend für Markenidentitätsarbeit, Designsystem-Inventare, FigJam-Diagramme und Stakeholder-Präsentationen. Die These ist enger. Figma ist nicht mehr der Ort, an dem Produktdesign passiert, weil die Codebasis schneller und originalgetreuer ist und dasselbe Artefakt ausliefert, das der Nutzer anfasst.

Was ist mit Designern, die keinen Code lesen können?

Dieser Designer sollte lernen, Code zu lesen, nicht ihn zu schreiben. Komponenten lesen, Tokens erkennen, Werte ändern und einen Diff prüfen ist eine Ein-Wochen-Fähigkeit, kein Karrierewechsel. KI übernimmt 2026 die Schwerarbeit beim Produktionscode. Der Designer bringt Komposition, Urteilsvermögen und Geschmack auf die laufende Oberfläche, was wertvoller wird, nicht weniger, wenn die Produktionsschicht billig ist.

Sollte ein kleines Team wirklich komplett auf Figma verzichten?

Nicht komplett. Ein kleines Team sollte Figma weiterhin für Markenexploration, Systeminventare und Team-Alignment nutzen. Die Verschiebung betrifft Produktoberflächen, wo v0, Cursor, Lovable oder die shadcn-Registry ein Artboard in jeder Metrik schlagen. Die ehrliche Aufteilung ist Marke und Systeme in Figma, Produktoberflächen im Code, und bei neuen Initiativen neigt sich die Waage zum Code.

Geh auf die richtige Seite des Workflows

Die Ära von Figma als Designtool war fünfzehn Jahre lang richtig und ist vorbei. Die Codebasis ist 2026 die Designumgebung, und die Teams, die Produkt-UI im Code ausliefern, verlangen mehr, lernen schneller und gewinnen Briefings, die früher den Figma-Deck-Studios gehörten.

Wenn du eine Produkt-UI im Code ausgeliefert haben willst, mit Designern im Diff statt einem Figma-Deck, das über die Mauer geworfen wird, beauftrage Brainy. Brainy liefert Marke, Product Engineering und den KI-Workflow als ein Projekt, nicht als drei. Die Studios, die die Figma-Datei weiterhin als finales Ergebnis bepreisen, werden nächstes Quartal nicht mehr im Briefing sein. Sei im Briefing.