Ich designe jetzt häufiger mit Claude als mit Figma
(blog.janestreet.com)- Statt Spezifikationsdokumente zu schreiben und Figma-Mockups zu erstellen, Wechsel zu einem Design-Workflow, bei dem Ideen aus dem Kopf direkt als funktionsfähige Prototyp-Features umgesetzt werden
- Früher skeptisch gegenüber LLMs wie Copilot, Cursor und Gemini, doch nach dem Einstieg bei Jane Street wurde klar, dass AI-Unterstützung unverzichtbar ist
- Claude erlaubt kostenlose, unbegrenzte Iteration, sodass selbst nach 50 Änderungen ohne Widerstand Submit-Button, Shortcuts und Formulierungen im Detail verbessert werden können
- Auch Designer können wie Engineers selbst einen funktionierenden Proof of Concept (POC) bauen, damit andere ihn direkt ausprobieren und bewerten können
- Das führt zu einem neuen Kollaborationsmodell, das Nebenarbeit in Zwischenschritten eliminiert und alle Anstrengung auf das eigentliche Ergebnis konzentriert
Vom Zweifel an LLMs zur Wende
- Lange Zeit skeptisch gegenüber LLMs und bei jeder Nutzung von den Ergebnissen enttäuscht
- Im letzten Jahr versucht, ein selbst entwickeltes Spiel mit Copilot und Cursor zu verändern, aber beide konnten keine funktionierende Änderung erzeugen
- Im vorherigen Job mit Gemini Produktbriefing-Gliederungen und Wireframes erstellt, aber alles verworfen
- Alle Bereiche, in denen LLMs ausprobiert wurden, waren Dinge, die bereits gut beherrscht wurden, und die Ergebnisse waren schlechter als bei direkter eigener Arbeit
- Nach dem Einstieg bei Jane Street im vergangenen Sommer wurde deutlich, dass AI-Unterstützung unverzichtbar ist
- Weil es viele neue und noch ungewohnte Bereiche gibt, etwa OCaml und Bonsai
- Die größte Überraschung war, dass sich gerade der Bereich veränderte, der am besten beherrscht wurde: der Design-Workflow
Prototyp-zentrierter Workflow
- Statt Spezifikationsdokumenten, Figma-Mockups, Vorschlägen und Implementierungsreviews mit Entwicklern werden Prototyp-Features, die genau die beabsichtigte Funktion ausführen, direkt selbst gebaut
-
Tatsächlicher Arbeitsablauf
- Das Problem und den Vorschlag schriftlich festhalten
- Den Editor öffnen und Build, Server und Claude starten, wobei die geschriebene Beschreibung als Prompt dient
- Zuerst die Grundfunktion zum Laufen bringen, um die Machbarkeit zu belegen
- So oft iterieren, wie gewünscht
- Änderungen in die Entwicklungsumgebung pushen und Feedback von Nutzern einholen
- Ein Feature einreichen, das dem beabsichtigten Aussehen und Verhalten entspricht (entspricht in diesem Unternehmen einem Pull Request)
- Ein Prototyp direkt in der realen Codebasis war Mockups und Dokumenten in fast jeder Hinsicht überlegen
Beispiel: Prototyp für JSQL-Eingabe
- Kürzlich ein Prototyp erstellt, der der JSQL-Eingabe LLM-Prompting hinzufügt
- JSQL ist ein internes SQL-Dialekt, das in Tools für verschiedene Nutzergruppen verwendet wird
- Es funktionierte tatsächlich, und wurde mehrere Tage lang genutzt, getestet und im Alltag begleitet
- Claude erlaubt kostenlose, unbegrenzte Iteration und stört sich nicht daran, wenn man zum 50. Mal seine Meinung ändert oder kleine Anpassungen verlangt
- Submit-Button verfeinern, Tastaturkürzel hinzufügen, Formulierungen ändern, Prompts anpassen, generative Bestätigungsnachrichten ergänzen
- Verbesserungen, die im vorherigen Job Tage bis Wochen an Engineering- und Design-Pingpong erfordert hätten oder gar nicht passiert wären
- Alle Anstrengungen fließen in die Verbesserung des tatsächlichen Ergebnisses, nicht in Nebenarbeiten wie das Erstellen von Figma-Komponenten oder Dokumentformatierung
Wie sich dieser Workflow etabliert hat
- Es hat Zeit gebraucht, um zu dieser Arbeitsweise zu gelangen
- In der Anfangszeit nach dem Einstieg wurde AI nur für kleine Aufgaben wie kleine UX-Mängel beheben genutzt
- Für größere Ideen wurden weiterhin Figma und Dokumente verwendet, und Versuche mit Claude scheiterten
- In den vergangenen zwei Monaten gab es deutlich seltener den Griff zu Figma
- Durch die Kombination aus besseren Modellen, eigener Übung und sinnvoll gewähltem Umfang funktioniert AI jetzt auch bei größeren Aufgaben
- Neben JSQL-Prompts entstanden viele Prototypen für nutzerseitige Änderungen, Datenmodelle und Bibliotheksänderungen, einige davon mit mehr als 2000 Zeilen Diff
- Teilweise wird in Figma entworfen und anschließend ein interaktiver Prototyp umgesetzt, manche neuen Apps überspringen Figma aber komplett und iterieren das visuelle Design von Anfang an mit Claude
Mehr Handlungsmacht für Designer
- Engineers können bei einer Idee selbst einen funktionierenden Proof of Concept bauen, Designer mussten bisher andere überzeugen
- Bei Ideen wie direktes LLM-Prompting innerhalb der JSQL-Eingabe ist zu Beginn nicht einmal klar, ob sie technisch machbar sind; jemanden mit einem Prototyp zu beauftragen, könnte Zeitverschwendung sein
- Es könnte auch ein Vorschlag sein, der die Bedürfnisse der Nutzer am Ende nicht klar erfüllt
- Wenn die Idee mit Claude tatsächlich umgesetzt wird, können andere sie viel leichter selbst ausprobieren und bewerten
Herausforderungen bei der Review-Praxis
- Der Nachteil ist, dass Reviewer ein fertiges Feature erhalten
- Die Frage ist, ob sie dann nur noch den Code prüfen, ohne Einfluss auf das Feature selbst zu haben
- Ähnlich wie im Design, wenn man von einem PM einen detaillierten Wireframe erhält und nur noch gebeten wird, ihn „hübsch zu machen“
- Vorschläge sollen so klar und vollständig wie möglich sein, aber gleichzeitig sollen Engineering-Kollegen wie bei einem Figma-Mockup gemeinsam im Designraum iterieren
-
Aktuelle Lösung
- Das Feature wird anders betrachtet, und in die Beschreibung kommt eine kurze Einordnung
- Der Prototyp ist ein lebendes Vorschlagsdokument, der Code ist Wegwerfcode, und die Aufgabe der Reviewer ist es, Feedback zu Design und User Experience zu geben
- Am Ende übernehmen Reviewer die Idee und implementieren sie in einem separaten Feature, wobei sie sich auf den Prototyp beziehen, aber den Produktionscode selbst verantworten
- Was sinnvoll ist und sich gut anfühlt, wird noch ausgelotet
Bedenken und vertraute Spannungen
- Beim Designen mit Claude besteht die Sorge, aus flexiblem und kreativem Denken herauszufallen und in einem iterativen Denken steckenzubleiben, das auf Ergebnisse beschränkt ist, von denen man glaubt, dass Claude sie erzeugen kann
- Für ausgereifte Tools mit inkrementellen Änderungen mag das in Ordnung sein, bei Neuem könnten Ideen verloren gehen
- Das ist eine vertraute Spannung und knüpft an die Debatte von 2011 an: Sollen Designer Code schreiben?
- Kritiker argumentierten, dass große Änderungen an Ideen schwerer werden, sobald man mit dem Programmieren beginnt
- Da aber sowohl der Bau von Websites als auch das Programmieren Spaß machten, wurde weiter Code geschrieben
- Mit der Verbreitung von Frontend-Frameworks wie React und der steigenden Komplexität der Entwicklung fiel die Entscheidung zugunsten von Spezialisierung
- Persönliche Projekte werden weiterhin mit React gebaut, was bei der Kommunikation mit Entwicklern hilft
- Der Großteil der Arbeitszeit floss in Figma und Dokumente
- Ohne LLMs wäre man bei Jane Street wahrscheinlich noch tiefer in Figma versunken
- Mit JavaScript gab es etwas Erfahrung, aber OCaml und Bonsai waren völlig neu, sodass sich technischer Beitrag unerreichbar angefühlt hätte
- Stattdessen wird nun wieder am tatsächlichen Ergebnis gebaut, und die Rückkehr zu diesem Medium fühlt sich großartig an und vermittelt mehr Freiheit, alles Mögliche auszuprobieren
1 Kommentare
Hacker-News-Kommentare
Die Business-Seite bringt Anforderungen oft schon in Form einer von ihnen ausgedachten Lösung mit, und meistens ist das etwas wie eine Rube-Goldberg-Maschine, sodass man sie erst im Gespräch rückwärts analysieren muss, um bei den eigentlichen Anforderungen anzukommen
Künftig werden sie wohl schon eine „fertige“ und „funktionierende“ Lösung mitbringen und noch weniger offen dafür sein, sich Design und Architektur im Ganzen anzusehen
Es wird dann wohl heißen: „Man kann es doch einfach so bauen. Es ist fast fertig, warum brauchen wir noch X Personentage?“
Der Nachteil ist, dass die Business-Seite nicht versteht, warum man diese App nicht einfach direkt in Produktion deployen kann
Der Druck in Richtung „Mit AI geht es doch schneller“ wird größer, und am Ende wird es wohl davon abhängen, ob die Organisationsdynamik gesund ist
Der Vorteil ist, dass die Idee deutlich gründlicher validiert wurde als bei einer Skizze auf einer Serviette
Claude wird bereits nach Randfällen und Designentscheidungen gefragt haben, und vermutlich wurde irgendwann ausdrücklich gesagt: „Darum kümmere dich nicht, nimm es einfach an“ oder „Nach ein paar Versuchen gefällt mir diese Interaktion nicht, mach es anders“
Im Moment ist der Druck „Was ist das Problem, deployt es einfach“ stark, dumm und demotivierend, also beinahe ein klarer Nettoverlust, aber wenn sich das einpendelt, könnte es für zukünftige Projekte auch ein Nettogewinn werden
Diese kleinen Anpassungen sind dann Dinge wie: Das Layout bricht auseinander, wenn der Browser nicht exakt 1920 px breit ist, Filter und Sortierung funktionieren gelegentlich nicht richtig, oder nach bestimmten Aktionen werden neue Werte in der App nicht korrekt aktualisiert
Unabhängig vom Problem glaubt die Business-Seite dann schon, sie habe 95 % der Arbeit erledigt, und nimmt vorab an, dass „ein erfahrener Entwickler das schnell beheben kann“
Die Leute gewöhnen sich an ihr vorhandenes Ergebnis und akzeptieren Veränderungen in einem neuen professionellen Mix nur schwerer
Es gibt PMs, CSMs und TAMs mit dem Gespür dafür, Kundenprobleme in gut nutzbare Produktfunktionen zu übersetzen, aber wenn man die Problemdefinition überspringt und eine andere Funktionsorganisation die Lösung bauen lässt, endet das meist in einer Katastrophe, die Engineering und andere Ressourcen massiv verschwendet
Wenn jemand schon mit einer Lösung ankommt, besteht ein hohes Risiko, dass man erst nach Monaten beim Bauen produktionsfähiger Software merkt, dass Kunden sie hassen, das eigentliche Problem nicht gelöst wird oder sogar neue Probleme entstehen
Nicht dort, wo ich jetzt arbeite, sondern an einer früheren Stelle, und es wurde trotz Datenverlust und Sicherheitsproblemen direkt in Produktion deployt
Soweit ich weiß, ist Jane Street Investor bei Anthropic, das sollte man also mit bedenken
Dazu kommt, dass im Juli 2025 Indiens Börsenaufsicht SEBI Jane Street vorwarf, über mehrere Gesellschaften hinweg Marktmanipulation betrieben zu haben, und ihnen den Marktzugang untersagte
Ein großer Geldtopf braucht wohl viele Dashboards
Der Designer scheint hier aber einen falschen Ansatz zu verfolgen und einer Art Ingenieurssehnsucht zu verfallen, bei der man den Prototyp so tief und realistisch wie möglich machen will
Aber das ist nicht der wichtigste Teil von Designarbeit
Am wichtigsten ist, dass das Richtige gebaut wird
Fragen wie „Warum brauchen wir ein JSQL-Eingabefeld? Was wollen wir eigentlich wirklich? Welche anderen Wege gibt es?“ lassen sich oft besser mit Skizzen auf Papier, Meetings, Beobachtung und Diskussion klären
Das ist besser, als sich zu früh auf ein bestimmtes Design zu verengen und dann in Diskussionen darüber abzurutschen, ob ein Button links oder rechts stehen soll oder wie sich ein LLM im Detail verhalten soll
Wobei sie natürlich genau das wollen könnten
Ich sehe das manchmal
LLMs können derzeit nicht über Iteration hinausblicken, deshalb muss ich selbst außerhalb des Rahmens denken und fragen: „Wie wäre es aus dieser Perspektive?“, damit plötzlich eine neue Designrichtung entsteht
Manchmal muss ich sogar ein Flussdiagramm bauen, damit das LLM über seine aktuelle Fortschrittsstufe hinaussehen kann
Bei der Aussage „Claude hat mir kostenlose, unbegrenzte Iteration gegeben, ohne sich daran zu stören, dass ich zum 50. Mal meine Meinung ändere oder um eine kleine Anpassung bitte“: Bezahlen sie Claude nicht?
Bei kleinen Designstudios ist es ähnlich, und oft wird nicht wie bei Entwicklern nach Stunden abgerechnet
Ich antwortete ehrlich, dass ich wirklich schlecht in Design bin und auch Probleme damit habe, aus Designsystemen etwas abzuleiten
Es ist für mich extrem schwer, einen Punkt zu erreichen, an dem etwas okay aussieht, und auf dem Weg dorthin mache ich es fast immer noch schlechter
Der Designer im Gespräch nahm das persönlich und ging mich darauf an
So etwas hatte ich schon früher
Designer mochten die ständigen Fragen dazu nicht, wie etwas aussehen soll, und wollten die Übergabe lieber als einmaligen Handover abschließen
Selbst in Marketing- und Werbeagenturen musste ich ständig darum kämpfen, Beispiele dafür zu bekommen, wie Dinge aussehen sollen, die nicht in der Design-Spezifikation standen
Das heißt nicht, dass ich recht hatte, aber für mich ist das eine große Achillesferse
Wenn ich also „kostenlos, unbegrenzte Iteration, stört sich nicht daran“ höre, denke ich eher an Zeit und Geduld als an Geld
Bolt, das ich fürs Prototyping nutze, wird nicht wütend
Es macht vielleicht nicht das beste Design, aber deutlich besser, als ich es könnte, und wenn ich fertig bin, kann ich einen echten Designer bitten, es besser zu machen
Bis dahin muss ich mir keine Sorgen machen, jemanden zu verärgern
Ich habe für das Frontend Claude Design verwendet.
Das Erscheinungsbild und die Anmutung der Ergebnisse sind durchaus gut genug, aber die Designs sehen oft ähnlich aus und folgen meist den abgedroschenen Mustern des modernen Webs.
Ich frage mich, ob jemand damit schon untypische kreative Versuche gemacht hat.
Bisher stecken ungefähr drei Wochen darin, und sie ist noch nicht fertig, aber man bekommt schon einen Eindruck.
So wie es in den letzten zehn Jahren SaaS-Boilerplates gab, gibt es auch LLM-Boilerplate, die aus dem Internet gelernt wurde.
Trotzdem ist immer noch alles möglich, wenn man genug Hand anlegt.
Interessant ist, dass es Anforderungen gut umsetzt, aber ohne Richtungsvorgabe sichere Entscheidungen trifft.
Wenn man die Ästhetik des Outputs sowie User Experience und Inhalte bewerten will, aber kaum Prompts zur Ästhetik gibt, bekommt man eben nur sichere Standardwerte.
Designs mit einem bootstrap-/tailwind-Klon-Gefühl kann es gut erzeugen, aber genau diesen Teil muss man bewusst vorantreiben.
Bei einfachen Webseiten habe ich begonnen, den ersten Iterationen den alleinigen Fokus auf den visuellen Stil zu geben.
Man muss nur konkret anweisen, dass es nicht standardmäßig aussehen soll, und Beispiele für den gewünschten Website-Stil geben.
Mit etwas Ringen wirkt es etwas kreativer, aber dafür ist Prompt-Arbeit nötig.
Es wurde mir von sehr angesehenen und erfahrenen Designern empfohlen; sie bauen Prototypen inzwischen fast vollständig in Claude und verfeinern sie in Figma, wenn ihnen das Ergebnis gefällt.
Wenn man ohne detaillierte Stil-Prompts einfach nach einer allgemeinen UI fragt, ist es selbstverständlich, dass eine allgemeine Gestaltung herauskommt.
Der Vorteil hier ist, dass Designer lernen zu coden.
Ich fand es schon immer seltsam, dass Designer Software gestalten, ohne zu wissen, wie Software gebaut wird.
Zur Einordnung: Ich bin selbst Designer.
Allerdings ist das Entwerfen im Code ein technikzentrierter Ansatz.
Wenn der Zweck von Design darin besteht, Ergebnisse im Sinne menschlicher Ziele zu formen, kann man auch sagen, dass es besser ist, nicht bei den strengen Regeln des Codes zu beginnen.
Nicht wegen schöner aussehender Ergebnisse, sondern weil es das Denken nach vorn treibt, ist Stift und Papier noch immer schwer zu schlagen.
Jetzt, wo man praktisch per Stimme coden kann, kehre ich wieder zum Vibe Coding und zum Bauen von Produkten zurück, und es ist wirklich großartig.
Mein Vorgesetzter versucht diese neue Situation noch zu begreifen, aber die alte Rollentrennung scheint allmählich zu sterben.
An der Schnittstelle zu sein, ist meiner Meinung nach gerade der beste Platz.
Es fühlt sich an, als hätte mein ganzes Leben mich auf diesen Moment vorbereitet.
Für Designer dürfte es eher wie Figma sein, bei dem man das Ergebnis sieht und Änderungen sprachlich statt in einem visuellen Editor vornimmt.
Meine Frau ist Produktmanagerin bei einem FAANG-Unternehmen, und ihr Team verlässt sich extrem darauf, mit AI Software-Stücke per Vibe Coding zu erstellen, die früher wohl in Word oder Excel gelandet wären.
Sie lernen kein Coden und schauen den Code keine einzige Sekunde an.
Der Ansatz „Der Prototyp ist ein lebendiges Vorschlagsdokument, der Code darf weggeworfen werden, und die Aufgabe der Reviewer ist es, Feedback zu Architektur und User Experience zu geben.
Am Ende übernimmt der Reviewer die Idee, implementiert sie als separates Feature, orientiert sich am Prototyp, besitzt den Produktionscode aber selbst“ löst für mich ein Problem, das ich bei jedem POC erlebt habe.
Das ist wirklich eine sehr gute Vorgehensweise.
Wenn es um ein konkretes Problem in einem konkreten Produkt geht, nennt man es leicht ein „Vorschlagsdokument“.
Aber es gibt immer noch unzählige Designer, die Figma nutzen, um Designsysteme über Produkte und Plattformen hinweg zu definieren und zu pflegen, und in diesem Fall ist Figma die Quelle der Wahrheit.
Unser Team arbeitet auch so, und ich bin Frontend-Ingenieur; ehrlich gesagt vermisse ich die alte Arbeitsweise sehr.
Weil geschriebene Spezifikationen durch funktionierende Prototypen ersetzt wurden, kommt jetzt die zusätzliche kognitive Last dazu, Code zu lesen und zu entscheiden, was die beabsichtigte Änderung ist und was nur zu verwerfendes Rauschen.
Ich muss generierte PRs übernehmen und entscheiden, ob ich die nötigen Änderungen darauf aufbaue oder alles von Grund auf neu mache, und beides erzeugt Reibung.
Es kam auch schon vor, dass massenhaft unbeabsichtigte Änderungen erzeugt wurden, ich Zeit investiert habe, sie durch Reimplementierung zu übertragen, und später dann ein „Ups, sorry, das wollten wir eigentlich gar nicht ändern“ kam.
Ich verstehe, dass das mehr Eigenständigkeit gibt, aber es nimmt mir auch einen Teil der Freude an meiner früheren Arbeit und macht daraus eher ein Ärgernis.
Design und Produktseite entwerfen und coden mit Claude Features oder Erlebnisse per Vibe, bauen schnell Prototypen und bringen sie mit minimalem Engineering-Aufwand vor Kunden, um Feedback einzuholen.
Das ist großartig.
Aber überraschenderweise hat es insgesamt kaum dabei geholfen, schneller auszuliefern.
Ich glaube, der Grund ist, dass in diesem Prozess Denkarbeit verloren gegangen ist.
Ein nicht geringer Teil des Denkens wurde jetzt an das Sprachmodell ausgelagert.
Es übermalt Lücken in den Prompts und füllt nicht spezifiziertes Verhalten mit Halluzinationen auf.
Früher hätten wir bei Dingen gestoppt wie: „Das passt nicht so richtig“, „Wie vermittle ich diese Idee?“ oder „Was passiert in diesem Fall?“ — jetzt verschwindet das, und solche Details werden auf später verschoben, wenn man es dann richtig baut.
Natürlich kann man den Prozess verbessern und darüber nachdenken, wie man diese neue Technik besser nutzt, aber ob es besser ist als früher, da bin ich mir nicht sicher.
Sie stirbt aus.
Jetzt machen Backend-Leute auch Frontend.
Das ist ein Irrtum.
Schaut man sich den vom Compiler erzeugten Assembler an? Nein.
Warum also schaut ihr euch diesen Code an?
Wir haben die Abstraktionsebene nach oben verschoben.
Ich nutze oft denselben Ansatz
Schon vor AI habe ich das manuell so gemacht
Zuerst habe ich mich nur mit dem Nutzer und Stift und Papier hingesetzt, danach schnell ein Frontend-POC oder eine Demo gebaut, den Nutzer damit herumprobieren lassen und dann so lange angepasst, bis es wie gewünscht funktionierte
Für mich war es oft ohnehin schneller, eine schnelle Frontend-Demo in Code statt in Produktionsqualität zu bauen, als in Figma präzise Interaktionen zu erstellen
Durch die vollständige Interaktivität konnte ich deutlich mehr Grenzfälle bei der User Experience erfassen
Dank Claude Code geht das Erstellen von Wegwerfprototypen jetzt schneller, aber der Unterschied ist nicht riesig
Da 80 % der Gesamtzeit darauf entfallen, mit dem Nutzer zu sprechen und darüber nachzudenken, wie es funktionieren soll, halbiert Claude im Vergleich zum schnellen Selbstbauen ungefähr nur die verbleibenden 20 %
Die erste Version ist schneller, aber wenn man es noch nicht vollständig verstanden hat, sind Iterationen langsamer
Edwin, schön zu sehen, dass du das gepostet hast
Ich erinnere mich, dass wir ungefähr 2012/2013 zusammen einen Hackathon gemacht haben
Die Fähigkeit, schneller zu einem funktionierenden Prototyp zu kommen, ist enorm bestärkend, auch wenn dabei die Versuchung besteht, unausgereifte Ideen direkt auszuliefern
Design- und User-Experience-Anforderungen profitieren stark davon, wenn man über Storyboards und Wireframes hinausgehen und den tatsächlichen Ablauf wirklich anfassen und erleben kann