design trendsApril 30, 202610 min read

Der Tod des Modells: Warum Design im Code 2026 gewonnen hat

Statische Mockups hatten eine lange Zeit Erfolg. Doch 2026 haben sie das Rennen verloren. KI wandelt Eingaben heute schneller in lauffähige Komponenten um, als ein Designer auch nur ein einfaches Figma-Gestell liefern kann. Argumente für das Designen im Code, der neue Technologie-Stack, der sich durchgesetzt hat, die damit verbundenen Kompromisse und die Rolle des Designs, die Bestand hat.

By Boone
XLinkedIn
death of the mockup

Das Mockup ist tot. Nicht als Skizze, nicht als Denkwerkzeug, nicht als Moodboard. Sondern als fertiges Produkt. Das flache Figma-Gerüst, das Designer 15 Jahre lang als finales Artefakt auslieferten, hat 2026 den Kürzeren gezogen – und zwar gegen eine sofort einsatzbereite Komponente, die ein Entwickler noch am selben Nachmittag implementieren kann.

Das ist keine gewagte These. KI verwandelt heute einen Absatz mit einer Absichtserklärung schneller in eine funktionierende React-Komponente, als die meisten Designer eine Überschrift in Figma einfügen können. Design-Tokens haben Artboards als maßgebliche Informationsquelle abgelöst. Studios, die 2026 immer noch Figma-Präsentationen als finale Ergebnisse verkaufen, verlieren Aufträge an Teams, die bereits Live-Code liefern, und die Preisdifferenz vergrößert sich quartalsweise.

Die Argumente für Design im Code, der sich durchgesetzte Stack, die ehrlichen Kompromisse und die Rolle, die bestehen bleibt.

Das Mockup ist tot, die Entwicklungsabteilung hat es überholt

Die Ära der Mockups als fertiges Produkt ist vorbei. Studios, die 2026 immer noch Figma-Präsentationen als finale Ergebnisse verkaufen, sind preislich nicht mehr konkurrenzfähig. Der Mockup-Workflow folgte 15 Jahre lang einer klaren Logik: Designer liefern flache Frames in Figma. Entwickler übersetzen die Frames in Code. Stakeholder genehmigen die Frames. Die Produktion holt später auf, manchmal nie. Diese Logik brach zusammen, als die Produktion nicht mehr der Flaschenhals war.

2026 ist der Flaschenhals die Beurteilung, nicht die Leistung. KI liefert die Produktionsschicht in Minuten. Der flache Figma-Frame ist nun der langsamste Teil der Pipeline, nicht mehr der schnellste – und die Kunden haben es bemerkt. Ein Team, das eine lauffähige Komponente an einem Nachmittag entwickelt, liefert sie aus und lernt vier Zyklen, bevor das Team, das ein hochauflösendes Mockup erstellt, es einmal ausliefert.

Das Mockup ist nicht gestorben, weil Designer schlechter geworden sind. Es ist gestorben, weil die Entwicklungsabteilung besser geworden ist.

Was sich 2026 tatsächlich geändert hat

Der Wandel betraf nicht ein einzelnes Tool, sondern einen ganzen Technologie-Stack, der gleichzeitig eine kritische Masse erreichte. Figma Make wandelte Figma Frames in ausspielfertige React um. Cursor mit shadcn ermöglichte die kostengünstige Herstellung designgetreuer Komponenten. v0, Bolt und Lovable schlossen den Kreislauf von der Eingabeaufforderung bis zum fertigen Produkt für vollständige Anwendungen. Claude Code führte einen echten Coding-Agenten in einem echten Repository ein, mit menschlicher Beteiligung an den Änderungen. Design-Tokens, formalisiert im W3C-Entwurf und von jedem ernstzunehmenden Team übernommen, wurden anstelle des Artboards zur maßgeblichen Informationsquelle.

Jedes dieser Tools existierte bereits vor 2026 in irgendeiner Form. Neu ist, dass sie alle im selben Zeitraum gereift sind. Das Ergebnis ist ein Workflow, in dem die laufende Anwendung das fertige Artefakt und das Artboard der Entwurf ist – und nicht umgekehrt.

Voxelreihe aus vier schweren Monolithen in Korallenbernstein-Creme-Cyan mit einwortigen, geätzten Beschriftungen FIGMA CURSOR V0 CLAUDE auf dunklem Studioboden mit korallenfarbenem Dunst
Voxelreihe aus vier schweren Monolithen in Korallenbernstein-Creme-Cyan mit einwortigen, geätzten Beschriftungen FIGMA CURSOR V0 CLAUDE auf dunklem Studioboden mit korallenfarbenem Dunst

Figma Make machte Figma zu einem Code-Generator.

Figma Make schloss die Lücke zwischen Zeichenfläche und Codebasis, indem es React Komponenten direkt aus Frames generierte. Frames waren nicht mehr das eigentliche Ergebnis, sobald Figma sie selbst zu einem Entwurf machte. Designer, die Make verwenden, übergeben der Entwicklung keinen Frame, sondern eine funktionierende Komponente, die ein Sprint-Team mit geringfügigen Anpassungen ins Repository einfügen kann.

Make ist nicht perfekt. Generierter Code benötigt weiterhin die Prüfung durch erfahrene Entwickler, die Token-Zuordnung ist in älteren Dateien noch unvollständig, und komplexe interaktive Logik erfordert weiterhin manuelle Bearbeitung. All das ist jedoch irrelevant für die Frage, ob ein statischer Frame im Jahr 2026 das Ergebnis sein wird. Die Antwort lautet: Nein. Figma hat dies selbst entschieden.

In Kombination mit dem Entwicklermodus und den Figma MCP-Funktionen verkürzte sich der gesamte Workflow von Figma bis zur lauffähigen App von einer mehrtägigen Übergabe auf einen einzigen Tag.

Cursor und shadcn ermöglichen kostengünstigen, designkonformen Code

Cursor mit shadcn vereinfacht die Entwicklung barrierefreier, markenkonformer Komponenten erheblich – genau das, was der Mockup-Workflow zuvor rechtfertigte. Ein Designer, der eine designkonforme Produktionskomponente benötigte, verbrachte früher eine Woche damit, Abstände, Schriftarten, Farben und Zustände zu annotieren und sie an die Entwicklung zu übergeben. Cursor und shadcn erstellen diese Komponente bedarfsgerecht, mit tokenbasierten Varianten, die standardmäßig barrierefrei zugänglich sind, in nur 15 Minuten.

Die Kombination ist entscheidend. Cursor bearbeitet ein echtes Repository mit echten Änderungen. shadcn liefert Komponenten als eigenen Code, nicht als abhängiges Paket. Tailwind-Tokens lassen sich nahtlos in beides integrieren. Das Ergebnis ist designgetreuer Produktionscode, allerdings auf Kosten eines Figma-Frameworks, wodurch der häufigste Grund für die Entwicklung von Figma entfiel.

v0, Bolt und Lovable schlossen den Kreislauf von der Anfrage bis zum Produkt

v0 von Vercel, Bolt von StackBlitz und Lovable schlossen den Kreislauf von der Anfrage bis zur lauffähigen, bereitstellbaren App innerhalb weniger Minuten. Keines dieser Tools ist perfekt. Alle drei sind jedoch schneller als die Erstellung eines hochauflösenden Prototyps derselben Oberfläche.

v0 überzeugt mit designgetreuer Komponentenebene, da es shadcn und Tailwind nativ unterstützt. Bolt überzeugt mit Full-Stack-Browser-Prototypen, da es in derselben Sitzung ein Backend bereitstellt. Lovable überzeugt mit dem Gründer-MVP, da es für Nicht-Entwickler konzipiert wurde, die Produkte ohne Entwicklungsabteilung auf den Markt bringen möchten. Alle drei Tools verwandeln die Intention in eine Arbeitsumgebung – und zwar so schnell, wie Kunden es von einem Moodboard erwarten.

Wenn Kunden sehen, dass eine funktionierende App in der Zeit entsteht, die früher für ein Moodboard benötigt wurde, verliert das Moodboard seine Berechtigung.

Zentraler Voxelrücken in Korallenrot mit Pfeilen, die zu kleinen Zeichenflächenkomponenten und App-Platten auf dunklem Studioboden mit korallenfarbenem Dunst abzweigen
Zentraler Voxelrücken in Korallenrot mit Pfeilen, die zu kleinen Zeichenflächenkomponenten und App-Platten auf dunklem Studioboden mit korallenfarbenem Dunst abzweigen

Claude Code ermöglichte die Echtzeit-Zusammenarbeit an einer laufenden App.

Claude Code bot Designern und Entwicklern mit einem realen Repository eine gemeinsame Arbeitsfläche – das Live-Produkt, nicht nur eine Simulation. Das Prinzip ist einfach: Designer arbeiten mit Claude Code an der laufenden App zusammen, bearbeiten eine Komponente und testen die Änderung innerhalb derselben Minute im Browser. Der Entwickler prüft die Änderungen und liefert die App aus.

Dieser Kollaborationszyklus kommt dem Designen auf einem Whiteboard so nah wie kein anderer seit der Einführung von CSS. Nur dass das Whiteboard die Produktions-App ist, die Markierung eine echte Komponentenänderung und der Radierer ein Git-Diff. Der Mockup-Workflow kann mit einem so effizienten Zyklus nicht mithalten.

Wenn Sie die Funktionsweise dieser Schleife in einer realen Codebasis genauer verstehen möchten, sehen Sie sich Vibe-Codierung für Designer und Vergleich von KI-Code-Editoren an.

Design-Tokens werden zur maßgeblichen Informationsquelle

Tokens, nicht Artboards, sind ab 2026 die maßgebliche Informationsquelle. Diese Änderung hat den Großteil des Workflows von Figma als finales Lieferergebnis überflüssig gemacht. Wenn Farbe, Abstände, Typografie, Radius, Bewegung und Höhe in einer Token-Datei gespeichert sind, die sowohl vom Designtool als auch von der Codebasis gelesen wird, ist das Artboard eine Darstellung der Tokens, keine Definition derselben.

Die W3C-Spezifikation für Design-Tokens, das Style Dictionary, die Tailwind-Theme-Dateien und die Token-Plug-ins in Figma basieren alle auf demselben Prinzip: Tokens im Upstream, alle Oberflächen im Downstream. Ein Team, das so arbeitet, bearbeitet die Token-Datei, überwacht Figma und die laufende Anwendung und liefert das Produkt aus. In diesem Workflow gibt es kein flaches Artboard, das als finales Lieferprodukt versendet werden sollte, da die Token-Datei bereits ein solches ist.

Dies ist der Punkt, den die meisten Studios, die immer noch Figma-Decks verkaufen, nicht verinnerlicht haben, und deshalb sinken ihre Preise. Informationen zum Upgrade finden Sie unter Designübergabe von Figma an dev.

Wo Mockups auch 2026 noch relevant sind

Mockups sind nach wie vor in vier Bereichen unverzichtbar. Das Gegenteil zu behaupten, ist unehrlich und führt dazu, dass der Rest dieser Argumentation hinfällig wird.

Erstens: Frühe Ideenfindung. Ein flaches Figma-Frame in der Divergenzphase ist schneller, als einen Code-Editor für eine halbstündige „Was wäre, wenn es so aussehen würde?“-Runde zu starten. Zweitens: Markenskizzen. Logoentwicklung, Identitätsforschung, Typografiestudien, Farbsysteme vor der Implementierung – all das gehört nach wie vor auf ein flaches Artboard oder in Illustrator, bevor eine Token-Datei existiert. Drittens: Reine visuelle Erkundung ohne Stack. Neue Produktkategorien, stimmungsorientierte Konzepte, Dinge ohne Codebasis. Viertens: Kundenpräsentation von Markenentscheidungen, bei denen nicht die Oberfläche, sondern das System das Ergebnis ist.

Alles andere – jeder Bildschirm, der an einen echten Nutzer ausgeliefert wird, jede Komponente in einem Produkt, jede indexierte Seite – gehört 2026 in den Code.

Voxelfluss von drei Oberflächen – Token-Monitor und Produktplatte – verbunden durch dünne Korallenlinien auf dunklem Studioboden mit Korallennebel
Voxelfluss von drei Oberflächen – Token-Monitor und Produktplatte – verbunden durch dünne Korallenlinien auf dunklem Studioboden mit Korallennebel

Die neue Rolle: Designer als Live-Kompositionseditoren

Der Designer von 2026 ist ein Live-Kompositionseditor einer laufenden Anwendung, kein Produzent von Flatfiles. Die Arbeit wird anhand der ausgelieferten Oberfläche bewertet, nicht anhand der Zeichenfläche. Das Ergebnis ist eine bereitgestellte Komponente, kein Frame.

Diese Rolle ist anspruchsvoller, nicht weniger. Ein Live-Kompositionseditor liest Code, bearbeitet Tokens, liefert einen echten Diff und ist für die laufende Oberfläche verantwortlich. Sie ist auch besser bezahlt, da die Arbeit in Produktionsgeschwindigkeit abläuft und der Wert in der Beurteilung liegt, nicht in der Anzahl der Varianten. Die erfahrenen Entwickler, die diesen Wandel vollziehen, verlangen Premium-Honorare, da sie eine funktionierende App liefern und nicht nur eine Präsentation, die ein Junior hätte erstellen können.

Wenn Sie eine Produkt-UI im Code für den 2026-Stack benötigen, wenden Sie sich an Brainy einstellen. AppBrainy bietet umfassendes Produkt-Engineering mit Designern im Diff. ClaudeBrainy liefert die Skill-Packs und Prompt-Bibliotheken, die KI in die Produktionsschicht einer echten Codebasis verwandeln.

So funktionieren Linear, Vercel, Anthropic und Anysphere

Die Teams, die 2026 die beste Produkt-UI entwickeln, haben einen ähnlichen Workflow: Tokens werden im Upstream-Projekt bereitgestellt. Code dient als Arbeitsfläche. KI bildet die Produktionsschicht. Designer arbeiten im Diff.

Das Designteam von Linear betrachtet die Codebasis als zentrale Datenquelle. Tokens und Komponenten befinden sich im Repository, und Designer erstellen Pull Requests für die laufende App. Ihre Änderungsprotokolle und Feature-Seiten sind keine Figma-Exporte, sondern das Produkt selbst. Vercel verwendet dieselbe Struktur auf seiner Homepage und den v0-Oberflächen. Designer arbeiten direkt mit der bereitgestellten App zusammen und nutzen v0, um innerhalb von Minuten neue Mustervarianten zu erstellen. Das Produktteam von Anthropic entwickelt Claude-Produktoberflächen, wobei Designer den eigentlichen App-Code lesen und bearbeiten, oft mit Claude Code selbst als Produktionsassistent. Anysphere, das Cursor-Team, nutzt seine eigene Software: Designer arbeiten innerhalb von Cursor an der Cursor-Codebasis – der stärkste Beweis dafür, dass der Workflow real ist.

Die Struktur ist konsistent. Keines dieser Teams liefert Figma als finales Produkt aus. Alle behandeln das Artboard als Denkwerkzeug und die Benutzeroberfläche als Artefakt.

Die warnende Geschichte: Studios, die 2026 immer noch Figma-Präsentationen anbieten

Studios, die 2026 immer noch Figma-Präsentationen als finale Ergebnisse präsentieren, verlieren Aufträge an Teams, die bereits Live-Code liefern. Die Preisdifferenz vergrößert sich quartalsweise, und der Grund dafür ist nicht ästhetischer, sondern struktureller Natur.

Ein Studio, das 40.000 für eine Figma-Präsentation verlangt, konkurriert mit einem Team, das 50.000 für dieselbe Präsentation als fertigen Code anbietet. Der Kunde erhält für ein Quartal mehr das gleiche visuelle Ergebnis plus eine bereitgestellte App, ein Token-System und ein funktionierendes Designsystem. Die Rechnung ist ernüchternd. Das Studio, das ausschließlich Figma anbietet, verliert den Auftrag. Wiederholt sich das über ein Jahr, muss das Studio seine Preise anpassen oder seine Strategie ändern. Die meisten ändern ihre Strategie erst spät.

Dies ist keine Vorhersage. Es ist Realität bei den Buchungen auf Calendly. Studios, die das Figma-Ergebnis immer noch als fertiges Produkt betrachten, bringen ihren Kunden bei, sich an einen anderen Anbieter zu wenden.

FAQ

Ist das Mockup wirklich tot?

Das Mockup ist als finales Ergebnis für die Benutzeroberfläche eines ausgelieferten Produkts im Jahr 2026 überholt. Es ist nach wie vor ein nützliches Werkzeug für die frühe Ideenfindung, eine Skizzenfläche für die Markenentwicklung und eine Plattform für verschiedene Ideen. Die Veränderung liegt im Inhalt des Ergebnisses, nicht in der Frage, ob Mockups überhaupt noch eine Rolle spielen.

Was bedeutet Designen im Code?

Designen im Code bedeutet, dass der Designer Änderungen in eine echte Codebasis einarbeitet, nicht auf einer statischen Zeichenfläche. Er bearbeitet Tokens, bearbeitet Komponenten, führt die Anwendung aus, überprüft die Unterschiede und stellt sie bereit. Das Ergebnis ist die laufende Oberfläche, nicht das Grundgerüst.

Müssen Designer Programmierkenntnisse erwerben?

Designer müssen Code lesen, Tokens bearbeiten, einen Entwicklungsserver ausführen und Unterschiede überprüfen können. Sie müssen produktionsreifen React nicht von Grund auf neu schreiben. KI übernimmt die komplexe Codeentwicklung. Die Aufgabe des Designers beschränkt sich auf Komposition, Urteilsvermögen, Geschmack und die Gestaltungsoberfläche.

Ist Figma Geschichte?

Figma ist noch nicht Geschichte. Figma Make, Dev Mode und Figma MCP machen Figma zum Einstiegspunkt des neuen Workflows, nicht zum Endpunkt. Das Artboard ist ein Entwurf, der Code das fertige Produkt, und Figma steht am Anfang der Pipeline.

Wie sieht es mit Markenarbeit und Corporate Identity aus?

Marken- und Corporate Identity-Design basieren weiterhin auf Flat-Design-Tools. Logos, Typografie, Farbsysteme, Corporate-Identity-Skizzen – all das gehört in Figma, Illustrator oder in ein Skizzenbuch, bevor überhaupt Code existiert. Der Wandel betrifft die Produkt-UI, nicht das Markendesign.

Wie gelingt dieser Wandel am schnellsten?

Drei Schritte: Lernen Sie shadcn und Tailwind-Tokens. Entwickeln Sie gemeinsam mit Cursor oder Claude Code in einem realen Repository. Veröffentlichen Sie in diesem Quartal eine Komponente als bereitgestellten Pull Request. Der dritte Schritt ist entscheidend.

Sichern Sie sich die Vorteile des Wandels

Der Mockup-Workflow hatte seine Blütezeit. 2026 hat er das Rennen gegen eine lauffähige App verloren, und die Teams, die Produkt-UI im Code bereitstellen, erzielen höhere Preise, lernen schneller und gewinnen Aufträge, die früher den Figma-Studios gehörten.

Drei Schritte, um die Vorteile des Wandels zu nutzen: Erstens, Tokens in den Upstream-Prozess integrieren. Farbe, Typ, Abstand, Radius, Bewegung, Höhe. Eine Datei, beide Tools lesen sie, keine Zeichenfläche ist dafür zuständig. Zweitens: Führen Sie shadcn oder ein vergleichbares Tool in einem echten Repository aus, verwenden Sie Cursor oder Claude Code und liefern Sie in diesem Quartal eine Komponente als bereitgestellten Pull Request. Drittens: Ändern Sie die Anforderungen. Verkaufen Sie keine Figma-Präsentationen mehr als Abschlussprüfung. Verkaufen Sie stattdessen fertige Komponenten, bereitgestellte Apps und lauffähige Oberflächen.

Wenn Sie eine Produkt-UI im Code für den 2026er-Stack benötigen, verwenden Sie Brainy einstellen. AppBrainy bietet vollständige Produktentwicklung mit Designern im Diff. ClaudeBrainy liefert die Skill-Packs und Prompt-Bibliotheken, die KI in die Produktionsschicht einer echten Codebasis verwandeln. Studios, die immer noch Figma-Präsentationen als Abschlussprüfung anbieten, werden im nächsten Quartal nicht mehr berücksichtigt. Seien Sie dabei!

If you want a product UI shipped in code on the 2026 stack, AppBrainy ships full product engineering with designers in the diff, and ClaudeBrainy ships the Skill packs and prompt libraries that turn AI into the production layer of a real codebase.

Get Started