Figma verlor innerhalb weniger Stunden nach dem Launch von Claude Design 7 % seines Börsenwerts. Die eigentliche Geschichte: Produktteams öffnen Figma längst nicht mehr als Erstes. Hier ist der Vergleich von Claude Design, Figma und Lovable über 15 Dimensionen, plus das Playbook, das Vorreiter von Nachzüglern trennt und Produktteams 2026 um 40-60 % schneller liefern lässt.

Claude Design vs. Figma vs. Lovable: Wie Produktteams 2026 wirklich schneller bauen

Am 17. April 2026 hat Anthropic Claude Design als Research Preview veröffentlicht. Innerhalb weniger Stunden fiel die Figma-Aktie um 7 %. Auch Adobe verlor. Diese Reaktion galt nicht einem neuen Zeichentool. Der Markt preiste eine Verschiebung ein, die Produktteams längst still und leise vollzogen hatten: Sie öffnen morgens nicht mehr zuerst Figma.

Die meisten Produktverantwortlichen halten das immer noch für einen Kampf der Tools. Ist es nicht. Es ist ein Timing-Problem. Wenn dein Team Customer-Discovery-Schleifen dreht, während Teams an der Spitze GitHub-Repo-Schleifen drehen, liegst du bereits sechs Monate zurück. Dieser Beitrag zeigt dir den Vergleich von Claude Design, Figma und Lovable über 15 Dimensionen und erklärt, warum Tempo heute aus der richtigen Technologiewette entsteht, nicht aus der richtigen Feature-Liste.

Die unbequeme Wahrheit: Revolutionäre Produkte entstehen aus Technologie, nicht aus Nutzerwünschen

Das wollen Produktverantwortliche nicht hören: Die revolutionärsten Produkte in deinem Stack sind nicht aus Kundeninterviews entstanden. Cursor, Lovable, Claude Code, ChatGPT: Keines davon begann mit „Welchen Job wollen Nutzer erledigen?“. Sie begannen mit „Diese neue Transformer-Architektur ermöglicht etwas, das vorher nicht möglich war.“

Nutzer haben nach keinem davon gefragt. Nutzer können nicht nach etwas fragen, von dem sie nicht wissen, dass es möglich ist. Das Customer-Discovery-Playbook geht davon aus, dass die Technologie fix ist und das Produkt die Variable. Wenn die Technologie die Variable ist, steht dieses Playbook kopf.

Zwischen einem technologischen Durchbruch und dem Moment, in dem Kunden formulieren können, was sie davon wollen, gibt es immer eine Verzögerung. Meist sind es sechs bis zwölf Monate. Genau diese Lücke ist der Sweet Spot. Unternehmen, die sich darin bewegen, definieren die Kategorie. Unternehmen, die warten, bis die Kundennachfrage greifbar wird, kommen in einen Markt, der schon jemand anderem gehört.

Lovable ist das schärfste Beispiel der letzten Zeit. Vier Wochen nach dem Launch lag der jährlich wiederkehrende Umsatz bei 4 Mio. $, und bis Monat zwei war Lovable auf Kurs zu 10 Mio. $. Keine Customer-Discovery-Umfrage der Welt hätte diese Roadmap hervorgebracht. Das Team hat auf eine LLM-Fähigkeit gesetzt und ein Produkt um das gebaut, was die Technologie möglich machte. Die Kundennachfrage kam später, und da gehörte Lovable schon der Standard.

Unternehmen an der Spitze behandeln jeden neuen Durchbruch genauso. Sie lesen die Paper, sie ziehen sich die Repos, sie spielen herum. Sie liefern einen internen Prototyp in derselben Woche, in der das Modell erscheint. Nachzügler fahren weiter das Discovery-Playbook. Das ist keine Kritik an Designern und Produktmanagern. Es ist eine strukturelle Beobachtung darüber, wie Disruption tatsächlich ankommt. Die Disziplin, die du für stabile Technologie-Phasen aufgebaut hast, bremst dich in disruptiven aus.

Der Wandel, den dein Produktteam schon vollzogen hat (ob du es bemerkt hast oder nicht)

Öffne den Browserverlauf deines Teams. Das erste Tool, das die meisten deiner Produktleute heute geöffnet haben, war nicht Figma. Es war Claude, Cursor oder ChatGPT. Das ist keine Prognose. Es ist eine Verhaltensänderung, die bereits passiert ist.

Die Daten bestätigen das. Laut Figmas eigenen Zahlen nutzen 50 % der Kunden mit mehr als 100.000 $ Jahresumsatz Figma Make wöchentlich, und 75 % der Kunden ab 10.000 $ haben wöchentlich AI-Credits verbraucht, bevor Figma diese überhaupt monetarisiert hat. Praxisberichte zeigen Produktteams, die „täglich Features liefern, ohne Figma, Linear oder klassische Spezifikationen“. Studien von BuildBetter sagen voraus: „Vibe Coding wird bis Ende 2026 der Standard-Workflow für Produktteams unter 20 Personen.“

Teams, die einen stimmigen AI-Stack aus mehreren Tools einsetzen, berichten von 40 bis 60 % schnellerer Feature-Auslieferung im Vergleich zu Teams, die ein einzelnes AI-Tool isoliert nutzen. Das ist keine Kennzahl für Tool-Effizienz. Das ist eine Kennzahl für Produktgeschwindigkeit, genau die Art, die Investoren in der Due Diligence interessiert.

Es gibt eine Kehrseite. Entwickler verbringen inzwischen 11,4 Stunden pro Woche damit, AI-generierten Code zu reviewen, und nur 9,8 Stunden damit, neuen Code zu schreiben. 2024 war das Verhältnis umgekehrt. Der Engpass hat sich verschoben. Aus „mehr schreiben“ wurde „besser beurteilen“. Produktverantwortliche, die ihre Review-, QA- und Release-Prozesse nicht um diese Umkehr herum neu gebaut haben, verlieren das Tempo, das sie gerade eingekauft haben. Die 40-60 % holst du nicht, indem du AI-Tools auf alte Workflows draufpackst. Du holst sie, indem du den Workflow um das herum neu baust, was AI günstig gemacht hat.

Claude Design vs. Figma vs. Lovable: der Vergleich über 15 Dimensionen

Das ist der Teil, den die meisten Vergleichsartikel lieblos abhandeln. Wir nicht. Unten findest du die objektive Aufschlüsselung. Jede Zeile stützt sich auf die Produktdokumentation, Praxis-Reviews und die Preisseiten mit Stand April 2026. Keine Herstellerbrille. Bonanza hat mit allen drei Tools geliefert.

Zwei ehrliche Erkenntnisse. Erstens: Über die ganze Tabelle hinweg gibt es keinen eindeutigen Sieger. Die richtige Antwort hängt davon ab, was du diese Woche erreichen willst. Zweitens: Die drei Tools sind keine Ersatzprodukte, sie ergänzen sich. Figma für das System, Claude Design für die Schleife vom Prompt zum Prototyp innerhalb dieses Systems, Lovable für den Moment, in dem du eine Live-App vor Nutzern brauchst.

Die Übergabe von Claude Design an Claude Code, über die zu wenig gesprochen wird

Die Vergleichstabelle bügelt glatt, was eigentlich das folgenreichste Feature des gesamten Anthropic-Launches ist: die Übergabe von Claude Design an Claude Code. Betrachte das als eigene Perspektive, denn es verändert die Workflow-Rechnung für Produktteams auf eine Weise, mit der Figma und Lovable heute nicht mithalten können.

So läuft es ab. Du beschreibst in Claude Design, was du willst. Es generiert interaktives HTML und SVG. Du verfeinerst per Chat, Slidern und Inline-Kommentaren. Wenn du bereit zum Bauen bist, exportiert Claude Design ein strukturiertes Implementierungs-Bundle, keinen Screenshot mit Jira-Ticket. Claude Code übernimmt es mit vollem Wissen über das Design System, die Brand Tokens und die Komponentenentscheidungen. Und liefert Produktionscode in derselben Session.

Damit schließt sich die Schleife, die Praktiker seit einem Jahrzehnt „die Mautstelle zwischen Design und Code“ nennen. Jedes Design System existiert, weil es diese Mautstelle gibt. Designer dokumentieren Entscheidungen, damit Entwickler sie im Code neu abbilden können. Wenn eine einzige Toolchain die Entscheidung einmal festhält und überall anwendet, verschwindet der Großteil der Zeremonie.

Lies den offiziellen Launch-Beitrag von Anthropic, und du siehst genau diese Einordnung. Lies Lalindras Review nach einem Tag mit Claude Design oder die 15-Minuten-Analyse von Ocasio Consulting, und du siehst Praktiker, die zum selben Schluss kommen: Das Tool, das deine Codebasis liest, dein System extrahiert und ein Bundle direkt an einen Coding Agent übergibt, konkurriert nicht mit Figma. Es lässt die Kategorie in sich zusammenfallen, an deren Spitze Figma steht.

Die praktische Konsequenz für Produktverantwortliche: Wenn dein Team Claude Code bereits nutzt, ist Claude Design kein neuer Tool-Kauf, sondern die fehlende mittlere Schicht. Wenn dein Team Claude Code nicht nutzt, bewertest du die falsche Schleife. Es zählt die Schleife, nicht der Canvas.

Wie sich Claude Design in einen echten Build-Prozess einfügt, von der Recherche bis zur geprüften Änderung, ist Thema von Move from idea to evidence, Core 3 unseres kostenlosen Claude-Code-Kurses.

Wofür jedes Tool wirklich am besten ist

Hör auf zu fragen, welches Tool besser ist. Frag stattdessen, welches Tool welchen Job to be done in deiner Produktorganisation gewinnt. Unsere Einschätzung, nachdem wir mit allen drei geliefert haben:

Lovable gewinnt, wenn

• du bis Ende der Woche eine funktionierende App vor Kunden brauchst, kein Design
• du vor dem Product-Market-Fit stehst und das Ziel Validierung ist, nicht Feinschliff
• dein Team einen technischen Gründer und drei nicht-technische Operator hat, die Landingpages und interne Tools liefern müssen
• du einen Full-Stack-Prototyp willst, den du echten Nutzern geben kannst, um zu sehen, was sie damit machen

Claude Design gewinnt, wenn

• du bereits eine Codebasis mit Design System hast und neue Oberflächen brauchst, die es respektieren
• du Marketing-Assets, Slides und One-Pager willst, die aussehen, als kämen sie aus deinem Brand-Team
• dein Team Claude Code nutzt und du die Schleife von Design zu Build in einer Umgebung schließen willst
• du Konzepte erkundest und bis Donnerstag zehn Richtungen brauchst

Figma gewinnt weiterhin, wenn

• du ein Design System über 50+ Designer und 500+ Komponenten skalierst
• der Enterprise-Einkauf SOC 2, SSO und Audit-Logs verlangt, die Tools in der Research Preview nicht bieten
• du Echtzeit-Zusammenarbeit an einer einzigen Datei brauchst
• dein Workflow von Plugins, Dev-Mode-Specs oder dem Figma-Plugin-Marktplatz abhängt

Über diesen Wandel haben wir schon in „Ist Lovable der neue Herausforderer von Figma im UX Design?“ geschrieben und das Urteil in „Figma Make vs. Lovable“ aktualisiert. Die Rangliste der Tools ändert sich jedes Quartal. Die zugrunde liegende Frage bleibt dieselbe: Welche Wette bringt dein Team diese Woche schneller ans Liefern?

Die Nachzügler-Falle: Von der Idee zum Prototyp in Tagen ist Pflicht

Diesen Test machen wir mit Produktteams, die wir beraten. Such dir zufällig ein Teammitglied aus. Frag, wann es zuletzt ein Open-Source-Repo gezogen, daraus etwas nachgebaut und eine Variante in den eigenen Stack geliefert hat. Wenn die Antwort „Mach ich eigentlich nicht“ lautet, hat das Team ein Nachzügler-Problem.

Es geht nicht darum, alle zu Entwicklern zu machen. Es geht um die Haltung gegenüber neuer Technologie. Teams an der Spitze behandeln das neueste Release so, wie Köche neue Zutaten behandeln. Sie probieren es, sie schmecken ab, sie packen es bis Freitag in einen Prototyp. Nachzügler-Teams schreiben Bewertungsmemos, setzen Gremien-Reviews an und starten Research-Sprints, um herauszufinden, ob Nutzer das überhaupt wollen.

Bis das Memo unterschrieben ist, hat das Team an der Spitze das Produkt längst gelauncht und ist bei Version drei.

Von der Idee zum funktionierenden Prototyp in Tagen war früher ein Nice-to-have. 2026 ist es die Grundlinie. Claude Design bringt dich an einem Nachmittag dorthin, wenn du es richtig einsetzt. Lovable schafft es in 90 Minuten. Die Tools haben die Lücke geschlossen. Die einzige verbleibende Variable ist, ob dein Team die Haltung hat, sie so zu nutzen.

Der Check für Produktverantwortliche ist einfach. Experimentiert dein Team pro Woche mit mindestens einem neuen Modell, Framework oder Repo? Landen diese Experimente innerhalb eines Monats in gelieferten Features? Wenn nicht, sind nicht die Tools in deinem Stack das Problem. Sondern der Arbeitsrhythmus. Unser Design-Evolution-Playbook zeigt, wie du diesen Rhythmus umbaust, ohne bestehende Workflows zu sprengen.

Ein Vorbehalt, der genannt werden muss. Schnell auf Technologie zu setzen heißt auch, bereit zu sein, diese Wetten schnell wieder auslaufen zu lassen. Zwei Drittel der Tools, die du dieses Jahr einführst, werden innerhalb von achtzehn Monaten durch etwas Besseres ersetzt. Die Disziplin liegt im Rhythmus der Einführung, nicht darin, beim ersten Versuch das richtige Tool zu wählen. Teams, die sich mit einer Fünfjahres-Roadmap auf ein Produkt in der Research Preview festlegen, werden das Gegenteil von Tempo erleben. Teams, die jedes Quartal neue Wetten durchspielen und nur behalten, was sich aufsummiert, ziehen davon.

Das Integrations-Playbook für Produktverantwortliche

Du ersetzt Figma nicht in diesem Quartal. Das wäre ein Fehler. Du setzt die anderen beiden für bestimmte Jobs ein und misst, ob die Arbeit schneller wird. Hier ist das Sechs-Schritte-Playbook, das wir mit Kunden fahren:

1. Benenne den Engpass. Wähle die eine Schleife in deinem Produktprozess, in der Zeit versickert. Meist ist es vom Prototyp zum Nutzertest, vom Marketing-Asset zum Launch oder von der Spezifikation zur gebauten Komponente. Führ keine Tools ein. Führ sie gezielt für einen Engpass ein.
2. Gib den Engpass für 30 Tage an ein Tool. Lovable für die MVP-Schleife. Claude Design für markenkonsistente Marketing-Oberflächen. Nicht mischen. Ein Experiment mit einer einzigen Variable.
3. Miss die Schleifenzeit. Vorher und nachher. „Feature-Spezifikation abgenommen bis Prototyp live“ ist eine gute Ersatzkennzahl. Wenn sie nicht um mindestens 40 % sinkt, liegt das Problem nicht am Tool.
4. Behalte Figma als System of Record. Das Design System, die Komponentenbibliothek, die Übergabe-Specs, die Einkauf und Enterprise-Reviewer verlangen. Migrier nicht, was Figma gut kann.
5. Bau den Review-Prozess neu. Denk dran: Entwickler verbringen inzwischen 11,4 Stunden pro Woche damit, AI-Output zu reviewen. Gestalte den Review-Rhythmus bewusst. Benenne verantwortliche Reviewer. Setz QA-Gates schon in der Prototyp-Phase, nicht erst beim Pull Request.
6. Überprüf den Stack jedes Quartal. Schreib auf, was du eingeführt hast, was du gestrichen hast und warum. Zwei Drittel des diesjährigen Stacks überleben das nächste Jahr nicht. Behandle es als Portfoliomanagement, nicht als Kaufentscheidung.

Noch etwas. Kauf nicht am ersten Tag den kompletten Stack für das ganze Team. Wähle zwei Produktteams, fahr das Playbook ein Quartal lang und veröffentliche die Ergebnisse intern. Die Einführung im Rest der Organisation wird leichter, wenn deine eigenen Daten die Geschichte erzählen und nicht das Pitch-Deck eines Anbieters.

Was sich in den nächsten 12 Monaten ändert

Drei Prognosen, auf die wir einen Retainer verwetten würden.

Erstens: Claude Design bekommt bis Q4 2026 Multiplayer. Die Lücke ist zu offensichtlich und das Umsatzpotenzial zu groß. Wenn es kommt, schrumpft Figmas Burggraben bei der Echtzeit-Zusammenarbeit deutlich, und das Argument „Figma für Teamarbeit“ wird schwächer.

Zweitens: Figma konsolidiert. Der Schwenk auf 8 Produkte, den Figma nach dem Launch von Claude Design angekündigt hat, ist ein klassischer Verteidigungszug. Einige dieser Wetten werden eingestellt. Das Kernprodukt wird AI-nativer, vermutlich über eine tiefere Integration mit Figma Make und dem MCP Server. Rechne damit, dass Figma Mitte 2027 ein anderes Produkt ist.

Drittens: Eine neue Kategorie entsteht. Nicht „AI-Designtool“. Eher eine „Produkt-Betriebsumgebung“, in der Canvas, Code, Kundendaten und Deployment-Pipeline in einer einzigen, von Agents gesteuerten Schleife leben. Lovable ist auf diesem Weg schon weiter, als den meisten Beobachtern klar ist. Claude Design ist das fehlende Mittelstück. Wer beides am schnellsten zusammennäht, dominiert die nächsten fünf Jahre.

Wenn du tiefer einsteigen willst, wohin das führt: Den zugrunde liegenden Wandel haben wir in „Jenseits von Lovable: Die wahre Zukunft der Designtools“ beschrieben.

FAQ

Sollten Produktmanager zuerst Claude Design oder Lovable lernen?

Lern zuerst Lovable, wenn du schnell ein funktionierendes Produkt zu Nutzern bringen musst. Lern zuerst Claude Design, wenn du bereits eine Codebasis und ein Markensystem hast, das du erweitern willst. Die meisten Produktmanager profitieren davon, mit jedem Tool zwei Nachmittage zu verbringen, bevor sie sich für ihr Alltagswerkzeug entscheiden.

Ist Claude Design ein Ersatz für Figma?

Nicht 2026. Figma führt weiterhin bei Multiplayer-Zusammenarbeit, Design Systems im großen Maßstab, Plugin-Ökosystem und Übergaben auf Enterprise-Niveau. Claude Design ersetzt bestimmte Jobs innerhalb des Figma-Workflows: markenkonsistentes Prototyping, die Erstellung von Marketing-Assets und die Übergabe von Design zu Code. Betrachte es als Ergänzung, nicht als Migration.

Wie groß ist der echte Kostenunterschied zwischen den drei Tools?

Figma Professional startet bei 15 $ pro Editor und Monat und steigt im Enterprise-Tarif auf 75 $ pro Platz. Lovable Pro kostet pauschal 50 $/Monat für das gesamte Projekt. Claude Design ist in Pro (20 $/Monat) enthalten, aber Praktiker berichten, dass sie schon nach zwei echten Design-Sessions den Max-Tarif (100 $ oder 200 $/Monat) brauchen. Bei einem Produktteam mit 10 Personen dreht sich die Kostenrangfolge, je nachdem, wie intensiv ihr Claude Design nutzt.

Kann ein Team ohne Designer mit diesen Tools wirklich liefern?

Ja, mit Einschränkungen. Lovable verzeiht Nicht-Designern am meisten, weil es Designentscheidungen in seine Templates einbaut. Claude Design ist stark, wenn das Team ein Markensystem als Anker hat. Figma ohne Design-Expertise führt meist zu inkonsistenten Ergebnissen. Teams ohne Designer, die wir beraten haben, arbeiten am besten, wenn sie Lovable mit Claude Design kombinieren und einen Senior Designer einen Tag pro Woche für Reviews einplanen.

Wie verhindern wir, dass die Token-Kosten von Claude Design explodieren?

Hol die intensiven Iterierer in den Max-Tarif, bevor sie sich beschweren. Legt eine Team-Regel fest: Brainstorming bleibt im Chat, ernsthafte Design-Sessions finden in festen Blöcken statt. Speichert stabile Snapshots des Design Systems, damit nicht jede Session sie erneut aus der Codebasis extrahiert. Bis Anthropic Preise auf Teamebene einführt, ist Max realistisch die Untergrenze für jedes Team, das wöchentlich liefert.

Du willst dein Produktteam aus der Nachzügler-Spur holen? Bonanza bietet einen 2-Week Design Sprint, der eine Produktidee mit dem AI-nativen Stack aus diesem Beitrag vom Whiteboard zum funktionierenden Prototyp bringt. Buch ein Kennenlerngespräch, und wir gehen mit dir durch, ob das der richtige Schritt für deine Roadmap ist.