Paper.design ist noch kein Figma-Killer — aber ich sehe schon, wie es einer wird

Ich sage das nicht leichtfertig, weil ich seit über zehn Jahren Figma-Nutzer bin und meine gesamte Design-System-Arbeit darauf aufgebaut habe: Wenn paper.design in dem Tempo weiterentwickelt wird, in dem es sich gerade bewegt, kündige ich mein Figma-Abo. Nicht in fünf Jahren. Eher in ein bis zwei.

Das ist noch keine Tatsachenbehauptung über den heutigen Stand — paper.design ist heute kein Figma-Ersatz, an mehreren Stellen fehlt schlicht die Reife. Aber es ist die erste Design-Tool-Wette seit Jahren, bei der ich das Gefühl habe, auf der richtigen Seite der Geschichte zu stehen, wenn ich jetzt anfange, damit zu arbeiten, statt erst zu warten, bis alle anderen es tun.

Was paper.design eigentlich anders macht

Der naheliegende Reflex ist, paper.design als “Figma-Klon mit anderem Branding” abzutun. Das greift zu kurz und verpasst den eigentlichen Architektur-Unterschied. Figma rendert seine Canvas mit einer eigenen, proprietären Rendering-Engine — ursprünglich in C++ geschrieben, über WebAssembly in den Browser gebracht. Das war 2016 eine geniale technische Entscheidung, weil kein Browser damals eine performante genug Vektor-Canvas nativ bot. Aber sie hat einen bleibenden Nebeneffekt: Was in Figma gezeichnet wird, ist niemals echtes CSS. Es ist eine Figma-interne Repräsentation, die erst beim Export — oder von Tools wie Dev Mode — in CSS übersetzt werden muss. Diese Übersetzung ist eine Interpretation, keine 1:1-Abbildung, und genau da beginnt jeder Handover-Frust, den ich in 15 Jahren Design-System-Arbeit erlebt habe: Ein Blend-Mode, ein color-mix(), ein calc()-Ausdruck, den Figma nicht kennt, geht in der Übersetzung verloren oder wird zu einer Annäherung.

Paper geht den entgegengesetzten Weg: Die Canvas ist die Codebasis. Was du auf dem Canvas zeichnest, ist HTML und CSS — echtes, browserinterpretiertes CSS, nicht eine Figma-Analogie davon. Laut eigener Roadmap-Kommunikation können Elemente calc(), color-mix() und echte Blend-Modes nutzen — nicht weil Paper diese Features nachgebaut hat, sondern weil der Browser sie sowieso schon kann und Paper einfach nicht dazwischenfunkt. Das ist der Unterschied zwischen “Design-Tool, das CSS möglichst gut simuliert” und “Design-Tool, das tatsächlich CSS ist, nur mit einer visuellen Bedienoberfläche davor”.

Der Wert, der heute schon da ist: Paper Snapshot

Die Chrome-Extension “Paper Snapshot” ist der Teil, wegen dem ich paper.design überhaupt ernst nehme, obwohl der Rest noch unfertig ist. Der Workflow ist so simpel, dass er fast banal wirkt, bis man merkt, was technisch dahintersteckt: Extension per Icon oder Shortcut (Shift+Cmd+P) aktivieren, mit den Pfeiltasten das gewünschte Element auf einer echten, live laufenden Website anvisieren, mit Enter oder Klick “snapshotten” — und mit Cmd+V direkt in eine Paper-Datei einfügen, egal ob Web- oder Desktop-App.

Was dabei passiert, ist kein Screenshot. Es ist eine echte HTML/CSS-Erfassung des Elements, so wie der Browser es tatsächlich gerendert hat — inklusive der berechneten Werte, nicht der Autoren-Absicht. Für mich als jemanden, der in einem früheren Artikel schon geschrieben hat, warum ich nie wieder ohne Browser-DevTools arbeiten will, ist das die logische Fortsetzung dieses Gedankens: Statt in den DevTools zu inspizieren und die Werte manuell in ein Design-Tool zu übertragen, nimmt Paper Snapshot mir genau diesen Übersetzungsschritt ab. Ich sehe eine Komponente auf einer Live-Site — einem Konkurrenzprodukt, einer alten Version der eigenen Site, einem Inspirations-Screenshot, der eigentlich eine echte Seite ist —, greife sie mit echten Werten ab und habe sie sofort editierbar in meinem Canvas.

Das klingt nach einem netten Convenience-Feature. Es ist mehr als das, wenn man bedenkt, wie viel Design-Arbeit in der Praxis aus “Wie hat die Konkurrenz das gelöst” oder “Wie hat unser eigenes Produkt das früher gemacht” besteht. Die Extension hat laut Chrome Web Store aktuell rund 20.000 Nutzer — für ein noch junges Tool ein Signal, dass der Nutzen real ist, nicht nur ein Marketing-Gag.

Das Agent-Argument: Design als beschreibbare Oberfläche für KI

Der zweite große Unterschied zu Figma ist strukturell, nicht kosmetisch: paper.design positioniert sich explizit als Canvas für Teams, die mit KI-Agenten arbeiten. Es gibt Integrationen in IDEs und CLI-Tools — VS Code, Cursor, Zed, Terminal — sowie Anbindungen an Agenten wie Claude, GitHub Copilot und Windsurf, über MCP (Model Context Protocol). Ein Agent kann laut Produktbeschreibung Design-Tokens, Styles und Komponenten zwischen Canvas und Repository synchronisieren — in beide Richtungen.

Das ist ein fundamental anderes Verhältnis zu KI als das, was Figma aktuell anbietet. Figma hat mit “First Draft” und diversen KI-Plugins nachgezogen, aber die Grundarchitektur bleibt: Figma ist die Quelle, Code ist die Übersetzung, die von dort ausgeht. Bei Paper ist die Canvas selbst eine Repräsentation, die ein Agent genauso versteht wie ein Mensch, weil sie in derselben Sprache — HTML/CSS — vorliegt wie das, worauf der Agent im Repository ohnehin schon arbeitet. Es gibt keinen Übersetzungsschritt zwischen “was der Agent im Code sieht” und “was der Agent im Design sieht”. Für meine eigene Arbeitsweise — ich nutze Claude Code und Gemini CLI inzwischen wie einen Pair-Programming-Partner, nicht wie ein Orakel, das ich mit fertigen Anforderungen füttere — ist das kein Nice-to-have. Es ist die Voraussetzung dafür, dass ein Agent überhaupt sinnvoll zwischen Design-Absicht und Code-Realität vermitteln kann, ohne ständig zu raten, was mit einem Blend-Mode “eigentlich gemeint war”.

Paper geht dabei noch einen Schritt weiter, den ich in keinem anderen Tool in dieser Form gesehen habe: Statt mit Platzhalter-Text zu arbeiten, kann die Canvas echte Inhalte aus APIs, Datenbanken oder Cloud-Tools ziehen. Man bearbeitet echte Daten direkt auf dem Canvas und schreibt Änderungen zurück in die Codebasis. Lorem Ipsum als Design-Praxis stirbt damit nicht aus Prinzip, sondern weil es schlicht keinen Grund mehr gibt, es zu benutzen, wenn echte Inhalte genauso einfach verfügbar sind.

Die Lücke, die wirklich wehtut: Design Tokens fehlen nativ

Und jetzt zum Teil, der mich seit Wochen frustriert, während ich paper.design für alles andere lobe: Es gibt aktuell keine Möglichkeit, Design Tokens direkt in der App über eine UI anzulegen. Farb-Variablen, Spacing-Skalen, semantische Tokens — all das, was ich in meinem letzten Artikel als die eigentliche Infrastruktur-Schicht eines Design Systems beschrieben habe — lässt sich in Paper aktuell nur über den Umweg eines KI-Agenten erzeugen. Ich formuliere einen Prompt, der Agent generiert CSS Custom Properties, die dann irgendwo in meiner Datei landen. Es gibt keinen dedizierten Token-Editor, keine visuelle Variablen-Verwaltung wie bei Figma Variables, keine Modes für Light/Dark, die ich klickend anlegen kann.

Das ist kein Nebenschauplatz. Es ist laut Paper’s eigener Roadmap (“Themes and tokens”) explizit als “Coming Soon” markiert — das Team weiß also selbst, dass hier eine zentrale Lücke klafft, genauso wie “Components with slots” und “Icon packs, shadcn, component kits” noch als geplant, nicht als vorhanden gelistet sind. Was bereits in Arbeit ist: “Use your code components” und eine native Tailwind-CSS-Integration. Das passt ins Bild — Paper baut zuerst die Code-Brücke, dann erst die visuelle Governance-Schicht darüber. Aus Priorisierungssicht nachvollziehbar. Aus meiner Praxis-Perspektive als jemand, der täglich mit Tokens arbeitet, aktuell trotzdem der Punkt, der mich zurück zu Figma Variables schickt, sobald ich eine echte Farbskala mit Light/Dark-Modes definieren muss.

Der KI-Umweg funktioniert, ist aber genau das Gegenteil von dem, was ich in meinem Artikel über Tokens als Infrastruktur beschrieben habe: Tokens sollten die trägste, am wenigsten volatile Schicht eines Systems sein — ein Agent, der bei jedem Prompt potenziell leicht andere Werte generiert, wenn ich die Anfrage etwas anders formuliere, ist das Gegenteil von Stabilität. Ich will Tokens deterministisch anlegen, nicht stochastisch approximieren lassen.

Was das für meinen eigenen Workflow konkret ändert

Ich habe in den letzten Wochen versucht, einen kleinen, ungefährlichen Teil meiner Arbeit testweise nach Paper zu verlagern: erste Layout-Explorationen für Landingpage-Sektionen, bevor irgendetwas produktionsreif werden muss. Der Unterschied zu Figma war sofort spürbar, aber nicht dort, wo ich ihn erwartet hätte. Ich dachte, der Vorteil läge im Export am Ende des Prozesses — tatsächlich lag er am Anfang. Weil die Canvas echtes CSS ist, kann ich in Paper mit tatsächlichen Werten arbeiten, die mein Produktions-Stylesheet später auch verwendet: clamp() für fluid Typografie, echte grid-template-columns-Definitionen, Media Queries, die ich testen kann, indem ich das Browserfenster verkleinere — nicht ein Figma-Frame mit fester Breite, das so tut, als wäre es responsive.

Das verändert die Art, wie ich über Layout nachdenke, in einem Ausmaß, das ich unterschätzt hatte. In Figma entwerfe ich typischerweise für drei bis vier feste Breakpoints und hoffe, dass die Zwischenräume vernünftig aussehen. In Paper entwerfe ich einmal, ziehe das Fenster durch den gesamten Bereich, und sehe sofort, wo clamp()-Werte nachjustiert werden müssen — weil es keinen Unterschied zwischen “Design-Ansicht” und “echtem Rendering” gibt. Das ist im Kern derselbe Denkfehler, den ich schon bei Pixel-Perfect-Handovers beschrieben habe: Ein Interface, das nur bei exakt den getesteten Breiten gut aussieht, ist keine robuste Design-Entscheidung, sondern eine Zufallsdemo. Paper macht diesen blinden Fleck sichtbar, weil es unmöglich ist, ihn zu verstecken — die Canvas rendert nur das, was der Browser tatsächlich tut.

Der ehrliche Vergleich: Wo Figma noch uneinholbar vorne liegt

Damit dieser Artikel keine einseitige Verliebtheit wird: Figma hat einen Reifegrad, den kein junges Tool in ein, zwei Jahren einholt, egal wie gut die Architektur ist. Das Plugin-Ökosystem ist riesig — Tausende Community-Plugins für alles von Datenvisualisierung bis Barrierefreiheits-Checks. Die Multiplayer-Infrastruktur ist nach Jahren Härtung praktisch unzerstörbar, selbst bei hundert gleichzeitigen Editoren in einer riesigen Datei. Prototyping mit komplexen State-Übergängen, Smart-Animate, Variablen-gebundenen Interaktionen — das hat Figma über Jahre verfeinert, während Paper hier noch am Anfang steht. Und Enterprise-Features wie Branching, detailliertes Permission-Management über Organisationen hinweg, Audit-Logs — das sind Dinge, die große Unternehmen brauchen und die ein junges Tool erst noch beweisen muss, bevor IT-Abteilungen es freigeben.

Wer heute ein Team von zwanzig Designern in einem regulierten Konzern führt, hat keinen guten Grund, morgen auf paper.design umzusteigen. Das wäre eine unverantwortliche Wette auf ein Tool, dessen zentrale Governance-Features noch als “Coming Soon” markiert sind. Aber genau das ist der Punkt: Ich rede hier nicht über Konzern-Migrationen. Ich rede über die Frage, wohin sich die Grundarchitektur von Design-Tools in den nächsten Jahren bewegt — und da zeigt die Nutzerliste, die Paper öffentlich nennt (Vercel, Perplexity, PostHog), etwas Interessantes: Das sind Unternehmen, die selbst an vorderster Front von Developer-Tools arbeiten und die sich bewusst für ein Tool entscheiden, das Design und Code strukturell verschmilzt, statt sie zu trennen und wieder zu verbinden.

Warum das mehr ist als ein weiteres “Figma-Alternative”-Tool

Es gab in den letzten Jahren diverse Anläufe, Figma anzugreifen — Framer, Sketch-Nachfolger, diverse Browser-native Editoren. Die meisten sind an derselben Stelle gescheitert: Sie haben versucht, Figma auf Feature-Ebene zu kopieren, nur mit anderer Oberfläche oder anderem Preismodell. Paper macht das nicht. Es greift die Grundannahme an, dass ein Design-Tool eine eigene Repräsentation von Interfaces braucht, die getrennt vom Code existiert und mühsam synchron gehalten werden muss. Diese Grundannahme war 2016 eine technische Notwendigkeit. 2026, mit CSS calc(), color-mix(), Container Queries und leistungsfähigen Browser-Rendering-Engines, ist sie das nicht mehr. Paper ist im Kern die Wette, dass die Trennung von Design-Repräsentation und Code-Repräsentation ein historischer Kompromiss war, kein dauerhaftes Architekturprinzip.

Ob diese Wette aufgeht, hängt fast vollständig davon ab, ob das kleine Team hinter Paper (Lost Coast Labs) die Geschwindigkeit halten kann, mit der es aktuell Roadmap-Punkte abarbeitet. Ein Design-Token-System, das nativ in der UI funktioniert, ist dabei keine Nebensache — es ist die Eintrittskarte für jedes Team, das ernsthaft ein Design System betreiben will, nicht nur einzelne Screens zeichnen.

Was das für Entscheidungen über Tooling-Budgets bedeutet

Für Product Leadership, das über Design-Tooling-Budgets entscheidet, ist die relevante Frage nicht “Sollen wir heute wechseln?” — die Antwort ist in den meisten Fällen klar Nein. Die relevante Frage ist: Wo evaluiert man das nächste Jahr Ressourcen für Piloten? Ein kleines internes Team, das schon heute mit Paper Snapshot Live-Referenzen einsammelt und erste Komponenten in der Codebasis mit einem Agenten synchronisiert, sammelt genau die praktische Erfahrung, die in zwei Jahren den Unterschied macht zwischen “wir haben früh verstanden, wohin sich Design-Tools bewegen” und “wir haben eine kostspielige Migration nachgeholt, die andere längst hinter sich hatten”. Der konkrete Hebel: Wenn Design-Änderungen direkt als Code vorliegen, statt erst durch einen Dev-Mode-Übersetzungsschritt zu müssen, verkürzt sich die Zeit zwischen Design-Freigabe und Production-Deploy messbar — kein Handover-Meeting, kein “Das hat der Entwickler anders interpretiert”. Das ist kein Argument für einen sofortigen Tool-Wechsel, sondern für ein bewusst kleines, risikoarmes Pilotprojekt, solange die Lizenzkosten dafür noch überschaubar sind.

Ich werde mein Figma-Abo diese Woche nicht kündigen. Aber ich beobachte die Paper-Roadmap inzwischen genauer als jede Figma-Release-Note — und sobald “Themes and tokens” von “Coming Soon” auf “Shipped” springt, werde ich ernsthaft testen, wie viel von meinem Design-System-Alltag sich dort abbilden lässt, bevor der Rest des Marktes das auch tut.