Gedanken und Eindrücke zu Claude Design
(samhenri.gold)- Mit der stärkeren Systematisierung von Design hat Figma komplexe Strukturen rund um eigene Einheiten wie Komponenten, Styles, Variablen und Props aufgebaut, wodurch eine Distanz zum eigentlichen Implementierungsmedium entstanden ist
- Figmaes proprietäres Format wurde in LLM-Trainingsdaten ganz natürlich ausgeklammert, und im Zeitalter der Agenten verlagert sich mit dem Aufstieg codebasierter Werkzeuge die Source of Truth für Design wieder in den Code
- Claude Design ist als ehrliches Medium, das HTML/JS direkt behandelt, ein Ansatz, der wie bei Figma keine verlustbehaftete Annäherung (
lossy approximation) an Code durchläuft, sondern direkt im tatsächlichen Implementierungsmedium arbeitet - Durch die Geschwisterbeziehung zu Claude Code besitzt es einen strukturellen Vorteil: Die Feedback-Schleife zwischen Design und Implementierung lässt sich in einem einzigen Gespräch zusammenführen
- Da sich der Markt für Design-Tools in codebasierte Werkzeuge und reine Explorationswerkzeuge aufspaltet, entsteht die Möglichkeit, dass Figma denselben Weg wie Sketch geht:
**Sketch moment**
Das Paradox von Figma-Standardisierung
- Mit dem Wachstum von Produktteams musste Design seine Existenz innerhalb von Engineering-Organisationen rechtfertigen und wurde dadurch in Richtung Systematisierung gedrängt
- Dafür erfand Figma eigene Primitive wie Komponenten, Styles, Variablen und Props; einige sind aus der Programmierung entlehnt, andere nicht, sodass eine Struktur entstand, die zu nichts sauber passt
- Guidelines ändern sich ständig, Migrationen häufen sich, und für Automatisierung ist man auf ein paar qualitativ schwache Plugins angewiesen
- Die Komplexität ist so stark gestiegen, dass sogar spezialisierte Design-Rollen entstanden sind, die nur dieses System verwalten
Die Verschiebung der Source of Truth
- Zwischen Figma und Code bestand immer eine Spannung darüber, was die eigentliche Source of Truth sein sollte
- Mit dem Sieg über Sketch vertrat Figma die Position, dass das eigene Tool zur kanonischen Instanz werden würde
- Doch dieser Sieg hatte versteckte Kosten: Das abgeschottete (
locked-down), größtenteils undokumentierte Format ist programmatisch schwer zu handhaben und wurde deshalb in LLM-Trainingsdaten ganz natürlich ausgeklammert - LLMs wurden mit Code trainiert, nicht mit Figma-Primitiven, deshalb konnten die Modelle Figmaes System nicht lernen
- Da Schreiben von Code auch für Designer einfacher wird und Agenten besser werden, scheint die Source of Truth natürlich wieder zum Code zurückzukehren
- Die komplexe Infrastruktur, die Figma in den letzten zehn Jahren aufgebaut hat, kann daneben nur überdimensioniert wirken
> „Wenn man Keramik herstellen will, warum malt man dann ein Aquarell von Keramik? Warum formt man nicht einfach den Ton?“
Die Komplexität von Figmaes eigenem Designsystem
- In der Praxis ist es extrem mühsam, Designänderungen, die direkt im Code vorgenommen wurden, zurück in Figma zu portieren (
back-porting) - Als Beispiel wird die Designsystem-Datei von Figma selbst gezeigt: Selbst das Ergebnis des wohl kompetentesten Designsystem-Teams ist in einem extrem komplexen Zustand
- 946 Farbvariablen sind in verschachtelten Gruppen wie "bg/desktopBackgrounded" organisiert, und für eine einzelne Variable existieren Werte für 8 verschiedene Modi wie Light, Dark und FigJam-Light
- Die Modal-Footer-Komponente hat 12 Varianten sowie Dropdowns mit Werten wie "DS Library Swap" und "QA Plugin" und zusätzlich 8 Props
- Der Effektstil einer Slider-Komponente existiert als separat benannter Stil für genau einen 0,5px-Drop-Shadow — weil das die einzige Möglichkeit ist, die Zuordnung zu CSS-Variablen zu dokumentieren
- Die Combo-Input-Komponente hat 16 Varianten, und Layer-Namen haben Formen wie "Default, Default, Close Button=False"
- Beim Debugging falsch dargestellter Farben ist eine mehrstufige Nachverfolgung nötig: Komponente prüfen → Variable prüfen → andere aliasierte Variable prüfen → Modus prüfen → Override auf Instanzebene prüfen → verschachtelte Komponente mit angewendetem Library-Swap prüfen
Figma Make vs. Claude Design
- Während sich die Source of Truth in den Code verlagert, steht Figma in einer merkwürdigen Position mit einem passiven System aus der Zeit vor Agenten (
pre-agentic) da - Die Design-Tools der Zukunft könnten sich in zwei klar unterscheidbare Formen aufspalten
- Der Wettbewerb um die Frage, die Figma 2016 beantwortete — „Welches Tool bringt meine Ideen als Designer am schnellsten nach draußen?“ — könnte von Neuem beginnen
- Figma Make ist ein Werkzeug für Menschen, die bereits mit dem Figma-System vertraut sind
- Es liest Figma-Styles, Komponentenbibliotheken und proprietäre Props (
Prop Props) ein und ist in dieser neuen Umgebung weiterhin das einzige Tool, das annimmt, die Designdatei sei die kanonische Instanz - Ein Tool für Menschen, die im System bleiben wollen oder bleiben müssen
- Es liest Figma-Styles, Komponentenbibliotheken und proprietäre Props (
- Claude Design ist die exakt gegenteilige Wette
- Es entspricht dem Prinzip „truth to materials“ aus der Arts-and-Crafts-Bewegung — der Idee, dass Dinge ehrlich in Bezug auf sich selbst und ihre Herstellungsweise sein sollten
- Figma ist das Gegenteil davon: eine freie „Vibe“-Hülle über einem extrem rigiden Schema — verglichen mit einer Persönlichkeit vom Typ A, die zwanghaft entspannt wirken will, während sie innerlich über verschachtelte Frames und getrennte Tokens schreit
- Claude Design ist rau, aber zumindest ehrlich darin, was es ist: durch und durch HTML und JS
Die strukturellen Stärken von Claude Design
- Der entscheidende strukturelle Vorteil ist, dass das Geschwisterprodukt von Claude Design Claude Code ist, das hervorragend mit Code umgehen kann
- Letztlich ist eine Struktur denkbar, in der direkt von Claude Design zu Claude Code oder umgekehrt übergeben werden kann
- Bereits im Onboarding von Claude Design gibt es eine Funktion zum Import von Repositories (
repo) - Die Feedback-Schleife zwischen Design und Implementierung — historisch immer eine Reibungsquelle — läuft in einem einzigen Gespräch zusammen
Die Möglichkeit anderer, codeunabhängiger Werkzeuge: reine Explorationsumgebungen
- Auf dem anderen Ast dieser Aufspaltung könnten Werkzeuge entstehen, die keinerlei Erwartung an Code haben
- Eine reine Explorationsumgebung, in der man Rechtecke platziert, Layer-Styles stapelt, frei mit Blend-Modi und Gradients arbeitet und nicht durch Systeme oder Prompt-Regeln eingeschränkt wird
- Das könnte eine App mit iPad- und Pencil-Unterstützung sein, in der man schnell Rechtecke skizziert, oder ein Bereich, in dem 37signals etwas Interessantes versuchen könnte
- In die entgegengesetzte Richtung könnte es wie Photoshop gehen: ein Tool, das ganz auf High-Fidelity-Compositing setzt und die Vorstellungskraft von den Grenzen von CSS-Effekten befreit
- Es wirkt seltsam, dass Figma während 90 % seiner Lebenszeit bei Layer-Effekten im Wesentlichen nur Drop-Shadow oder Blur angeboten hat
Figmaes „Sketch-Moment“
- Figmaes Sketch-Moment — also der Moment, in dem Figma verdrängt wird, so wie Sketch von Figma verdrängt wurde — rückt schnell näher
1 Kommentare
Hacker-News-Kommentare
Ich habe heute ein früher erstelltes Designsystem inklusive Logo, Branding und Schriftarten überprüft und nach nervig vielen weiteren Anpassungen gerade so ein Ergebnis erreicht, mit dem ich zufrieden war
Als ich dann auf die Nutzung schaute, hatte ich bereits 95 % meines wöchentlichen Claude-Design-Limits verbraucht
Das fühlte sich eher wie ein Spielzeug für Demos als wie ein echtes Produktivtool an
Es passte überhaupt nicht zu dem Stil, den wir wollten, aber bei ein paar Einschätzungen zu Content-Gruppierung und IA gab es Dinge, die ich in meine eigene Arbeit übernehmen konnte
Insgesamt war ich beeindruckt, aber später musste ich lachen, als ich auf Twitter die Erfolgsgeschichte eines anderen sah, weil sie fast identisch mit dem Mockup war, das ich bekommen hatte
Dieses Problem der Uniformität wird uns meiner Meinung nach wie bei von KI erzeugten Texten, Code und Bildern weiter begleiten
Meine Schwägerin betreibt eine kleine Bekleidungsfirma, und obwohl sie in den letzten sechs Jahren viel besser geworden ist, hatte sie anfangs große Mühe, Ideen in tatsächliche Ergebnisse zu übersetzen
Für solche Menschen ist jedes Tool, das die Einstiegshürde senkt, aus meiner Sicht einen Versuch wert
Trotzdem ist das Ganze gerade erst im Research Preview-Stadium, also wird sich das wohl noch ändern
Mit dem ersten Designsystem habe ich einen neuen Footer-Bereich für mein iPaaS-Startup gebaut, und von vier Varianten war die vierte ziemlich gut
Danach habe ich es mit Claude Code verbunden, noch etwas verfeinert, den Code generiert und direkt deployed. Falls es jemanden interessiert: auf der Unterseite von tediware.com sind links die „Origin story“ und rechts das Anmelde-Panel gemeint
Die Implementierung war nicht besonders komplex, aber die gelieferten Ideen und der Integrationsfluss waren so einfach, dass ich darin viel Potenzial sehe
Claude Design verwendet Opus 4.7 und ist damit teurer als frühere Modelle
Das Produkt ist erst seit zwei Tagen draußen und noch kein fertiges Endprodukt, und Anthropic verbessert solche Dinge normalerweise extrem schnell
Außerdem: Wenn man Claude schon lange nutzt, kennt es bereits meinen Geschmack und Stil; bei einem Wechsel zu einem anderen KI-Designtool müsste man wieder ganz von vorn anfangen
Einen ZIP-Export gab es allerdings, und ich habe die Datei in Googles Stitch geladen, aber die Kompatibilität war eher schlecht
Ich teile die Behauptung nicht wirklich, dass Claude Design die ganze Komplexität des Designs verschwinden lassen wird
Dass mit Claude per Vibe Coding gebaute Apps einfach aussehen, liegt in Wahrheit daran, dass der Produktumfang einfach ist
Es fühlt sich an, als würde man Fahrräder und Flugzeuge nach denselben Maßstäben vergleichen und dabei Einfachheit mit etwas anderem verwechseln
Wenn man dieselben Designsystem-Komponenten in Code und in Figma baut, kann Code dank Bedingungen und Kontrollfluss zwar kompakter sein
Aber Code ist weniger flexibel als direkt auf dem Bildschirm zu gestalten, und es ist schwieriger, kreative Freiheit zu erreichen
Letztlich erzeugen Menschen die Komplexität oft selbst, etwa indem sie vier Produkte mit acht Modi sowie Light- und Dark-Theme versehen
Claude kann die Wartung vielleicht etwas erleichtern, aber die Komplexität selbst wird dadurch meiner Ansicht nach nicht wesentlich verschwinden
Deshalb glaube ich, dass dieser Trend Figma ziemlich hart treffen wird
Ich denke, die Software, die das schafft, wird am Ende gewinnen
Ich wollte fragen, ob ich das richtig verstanden habe
Ich entwickle zwar seit meiner Kindheit, bin aber unsicher bei CSS, und mich interessiert, ob es tatsächlich viele Organisationen gibt, in denen Entwickler, sogar Frontend-Entwickler, mit Designern zusammenarbeiten, die nicht nur Logos oder Landingpage-Skizzen, sondern das komplette Produktdesign in so etwas wie Figma verwalten
Und ob das Ziel dann ist, dass diese Designer, ohne selbst Entwickler zu sein, eine Art Style-Datenbank pflegen und das Erscheinungsbild ohne Codeänderungen steuern, oder ob Frontend-Entwickler Figma meist gemeinsam mitbenutzen, aber die Trennung vom Code nicht mögen
Auch Kunden sehen sich das direkt an oder geben zumindest Branding-Folien frei, die auf diesen Figma-Ergebnissen basieren
Anschließend schaut sich das Frontend Figma an und baut es in CSS nach, aber die CSS-Kopierfunktion von Figma ist praktisch nur Inline-CSS und damit fast nie wirklich brauchbar, also wird fast immer eine bestmögliche Annäherung neu erstellt
Das Einheitensystem passt nicht, Beziehungen zwischen Eltern- und Kindelementen, CSS-Variablen oder Klassenhierarchien werden ebenfalls nicht abgebildet
Wenn mehrere Frontend-Entwickler Komponenten jeweils getrennt implementieren, entsteht auch noch Drift
Deshalb schafft man mit Storybook oft noch einen weiteren Frontend-Referenzpunkt und setzt es von dort in React oder NextJS um oder baut es als CMS-Komponenten erneut nach
Dann stellt sich die Frage, was überhaupt die echte Source of Truth ist, und in der Praxis ist es eher eine Kette mehrerer Referenzpunkte wie bei Stille Post
Sobald noch separate Promotion-Landingpages außerhalb des Hauptprojekts dazukommen, wird dasselbe Design in einem weiteren System noch einmal implementiert
Letztlich wird in der Handoff-Lücke zwischen Design und Code die Absicht der Designer beschädigt, oder Entwickler bekommen reale Probleme wie unterschiedliche Textlängen, veränderte Elementanzahlen, echtes Scrollverhalten und Anpassung an verschiedene Bildschirmgrößen erst spät auf den Tisch
Genau deshalb ist dieses kurze Meme-Video gleichzeitig lustig und nicht lustig: Es trifft diese Realität zu gut
Meistens coden Designer nicht und Entwickler designen nicht, und Menschen, die beides gut können, sind wirklich selten
Ehrlich gesagt ist das ein ziemlich schrecklicher Prozess, aber er fühlt sich trotzdem besser an als frühere Alternativen
Er automatisiert zwar den Großteil der langweiligen Arbeit, visuelles Design in Code zu übersetzen, ist aber schlechter als Tools, die direkt mit Code verbunden sind
Ich habe Claude Design noch nicht benutzt, aber für mich als jemanden, der sich in Code viel wohler fühlt als in den unzähligen GUI-Optionen von Figma, ist Code deutlich angenehmer
Vielleicht wegen meines ähnlichen Hintergrunds wie der Fragesteller stößt mich diese Perspektive instinktiv ab
Damit auch im Lauf der Zeit alle Ingenieure eine konsistente Umsetzung ohne Stilabweichungen liefern, braucht es ein gewisses Maß an zentralisierter Referenz
Ich reverse-engineere derzeit mit figma-kiwi-protocol das Figma-Protokoll, daher konnte ich mich sehr mit der Aussage identifizieren, dass „Figma die für das Agenten-Zeitalter nötigen Trainingsdaten selbst ausgeschlossen hat“
Das Binärformat von Figma wirkt so, als wollte es alles neu erfinden, und weil es Web-, Android-, iOS- und sonstige Designs zugleich abdecken muss, ist es am Ende zwar universell, bildet das Web aber nicht 1:1 ab
Und damit es für Agenten nützlich ist, müsste die Absicht klar sein, aber jeder, der schon einmal ein von UX-Designern erstelltes Figma umgesetzt hat, weiß, dass oft selbst für Menschen die Designintention nicht eindeutig ist
Was passiert mit Buttons, wenn Texte wie im Deutschen länger werden, was macht man, wenn beim CSS-Transfer plötzlich ein Umbruch auf zwei Zeilen entsteht, wie sieht es auf anderen Smartphones als dem iPhone aus, wodurch ersetzt man Gradient Borders, die in CSS nicht möglich sind, wie verhält es sich auf 4K-Bildschirmen – solche Fragen tauchen ständig auf
Mit Props oder Autolayout lässt sich manches beantworten, aber UX-Verantwortliche sind in der Realität nicht immer mythische Wesen, die Figma perfekt beherrschen
Deshalb hoffe ich, dass Tools mit HTML-basiertem Innenleben schnell aufholen, und idealerweise könnte man sogar die Prompts sehen, die Produktmanager den UX-Leuten gegeben haben
Der Text an sich war gut, und die letzten paar Absätze waren wirklich witzig
Besonders gefallen hat mir die Stelle, dass etwas nicht so tun sollte, als wäre es etwas anderes, sondern ehrlich zu seiner eigenen Identität stehen muss
Dabei kam mir der Gedanke, dass PenPot im Zeitalter der Agenten vielleicht ziemlich gut positioniert sein könnte
Anders als der fig-artige Canvas-Ansatz geht es dort stärker in Richtung markup-basiertes Design, und wenn einen genau diese Richtung interessiert, könnte das noch umso vielversprechender sein
Seit InVision dichtgemacht und in Richtung digitales Whiteboard geschwenkt ist, fühlte sich für mich dieser Markt für Design-Tools praktisch erledigt an
So schwierig scheint dieser Markt zu sein
Grundsätzlicher ist das Problem, dass Designsysteme langfristig unglaublich schwer sauber zu pflegen sind, vor allem weil sie tief mit Code und Komponentenbibliotheken verflochten sind, während Designer diese Ebene kaum berühren
Weder Claude Design noch Figma noch irgendein anderes Tool werden vermutlich die Storybook-Hölle rund um wiederverwendbare, gut aussehende Komponenten und Layouts grundlegend lösen
Es fühlt sich eher wie ein Problem an, das tiefer unten, also auf Komponentenebene, gelöst werden muss
Im Moment stecken wir noch in der Denkweise fest, für jedes neue Design Komponenten bereitzulegen, die man einfach einsteckt
Wenn man eine Komponente findet, die einem gefällt, speichert man ihre Definition in Markdown, und beim nächsten Design bittet man das Tool einfach, dieses Markdown zu lesen und die Komponente nach Bedarf zu verwenden
Ich glaube, daraus könnte ein viel flexiblerer und interessanterer Workflow entstehen
Sie muss skriptbar sein und zugleich direktes Zeichnen erlauben; wenn sich das Design ändert, muss sich der Frontend-Code sofort mitändern, und Änderungen am Code müssen sich auf demselben Niveau wieder im Design spiegeln
Die Endform wäre meiner Meinung nach ein Modell, in dem Designer und Frontend-Ingenieure ohne Handoff gemeinsam Urheber sind
Allerdings gibt es auch das Argument, dass künftig Bearbeiten, Extrahieren und Aufräumen fast kostenlos werden und solche Strukturierung deshalb weniger wichtig sein wird
Ich bin davon noch nicht völlig überzeugt, verstehe aber, warum man das sagt
Als jemand, der in den letzten Jahren selbst Design-Tools gebaut hat, habe ich das Gefühl, dass dieser Text sowohl die Design-Domäne als auch Figma als Unternehmen ziemlich grundlegend missversteht
Figma war von Anfang an ebenso sehr darauf ausgerichtet, ein erfolgreiches Unternehmen aufzubauen, wie darauf, ein erfolgreiches Produkt zu schaffen
Anfangs gab es ambitioniertere Richtungen, und dank Leuten wie Evan Wallace auch die Fähigkeit zur Umsetzung, aber letztlich konzentrierte man sich auf konkrete Produkte, die Geld einbringen, statt auf beeindruckende WebGL-Demos – und genau deshalb ist das heutige Geschäft daraus geworden
Dass es zum Beispiel keine 3D-Funktionen gibt, ist aus meiner Sicht eine Folge dieser Entscheidung
Figma war noch vor dem Design-Tool selbst ein Unternehmen, das Produkte baut, die Firmen tatsächlich einsetzen, und bis zum IPO war dieses Ziel im Wesentlichen bereits erreicht
Wie sich der Markt künftig entwickelt, weiß ich nicht, aber Seiten mit Kriegskasse können deutlich im Vorteil sein gegenüber bloß technisch spektakulären Demos
Und die im Artikel genannten Probleme sind Figma-Leuten wie überhaupt allen, die schon einmal Design-Tools gebaut haben, längst bekannt
Dass UI/UX ein Schnittpunkt von Design, Entwicklung und PM ist und näher an etwas wie Code als Source of Truth liegen sollte, versteht sich von selbst
Das Problem ist nur, dass man bei einer echten Umsetzung schnell weit über Design-Tools hinaus in Codierung, Datenverwaltung und Architektur-Tools hineingerät und daraus eine gewaltige Herausforderung wird
Bei KI bin ich selbst nicht sicher, aber die jüngsten SOTA-Modelle erscheinen mir so allgemein einsetzbar, dass ihr Grundmodell und dessen Schlussfolgerungsvermögen wichtiger sein könnten als spezialisierte Daten
UI-Design ist schließlich etwas, zu dem es bereits sehr viele öffentlich sichtbare Informationen gibt, die man aus dem Web ziehen kann
Ich habe in diesem Kampf kein besonderes Eigeninteresse und weiß auch nicht, ob die Analyse des Originalposts stimmt
Trotzdem empfinde ich bei der Erzählung „wegen eines proprietären Dateiformats zurückgefallen“ immer ein wenig Schadenfreude
Einige Punkte waren gut, aber insgesamt stimme ich nicht vollständig zu
Dass Sketch gegen Figma verloren hat, lag meiner Meinung nach an Design-Tooling und am Multiplayer-Erlebnis
So wie man physische Produkte vor der eigentlichen Fertigung erst entwirft, wird auch bei digitalen Produkten die Entwurfsphase selbst nicht verschwinden
Eher sollte Figma, statt alles gleichzeitig sein zu wollen, möglichst bald festlegen, was genau seine Identität ist
Wenn man erst eine Mac-App installieren und eine bestimmte Datei öffnen musste, wurden die Dateien mit der Zeit alt und der Zugang immer schlechter
Dazu gab es kürzlich auch einen HN-Thread zu Claude Design, der mit 732 Kommentaren (Stand April 2026) entsprechend große Resonanz ausgelöst hat