Unsere Produktarbeit beginnt jetzt im Code. Figma kommt danach.

Wenn ich anderen Designer:innen erzähle, wie wir neue Produkte heute bauen, ernte ich jedes Mal denselben Blick. Halb neugierig, halb besorgt.

Den größten Teil meiner Laufbahn sah der Prozess immer gleich aus. Der Problemraum lebte in Miro. Dann kam eine leere Figma-Datei und wochenlanges Iterieren an visuellen Beispielen, bevor irgendetwas Echtes existierte. Die Entwickler stiegen ein, sobald die Designs abgenommen waren, und benutzen konnte man das Produkt zum ersten Mal nach Monaten.

Bei uns hat sich diese Reihenfolge umgedreht. Ich möchte erklären, warum, denn es geht nicht darum, weniger zu gestalten.

Das Denken lebt jetzt an einem Ort

Die größte Veränderung betrifft den Ort, an dem das Denken festgehalten wird. Ein neues Produkt beginnt in Cursor: Research, Kundenprofil und Feature-Planung liegen gemeinsam in einem Workspace. Wenn wir das Produktdokument dann nach Notion übertragen, damit der Kunde es lesen und kommentieren kann, hat das Modell, mit dem wir arbeiten, mehr Kontext zum Projekt als die meisten Mitgründer.

Genau dieser Kontext macht den nächsten Schritt möglich. Die erste Version des Produkts wächst direkt daraus heraus, als funktionierender Code. Echte Daten, echte Navigation, echte Edge Cases, im Browser oder auf dem Smartphone.

Figma kommt dazu, sobald es etwas Echtes gibt

Figma kommt ins Spiel, sobald es etwas gibt, woran man gestalten kann. Wir übertragen die Screens aus der Codebasis eins zu eins nach Figma, mit sauberem Auto Layout und benannten Ebenen. Dann machen wir dort die Designarbeit, die wir schon immer gemacht haben: Hierarchie, Typografie, Abstände und all die Details, durch die sich ein Produkt durchdacht anfühlt.

Der Unterschied: Wir verfeinern jetzt ein funktionierendes Produkt, statt eines zu erraten. Wir sehen, wie sich ein Flow mit echten Inhalten verhält, bevor wir ihn polieren. Probleme, die früher erst in der Entwicklung auftauchten, etwa ein Formular, das viel länger ist als gedacht, zeigen sich am ersten Tag.

Ich verbringe immer noch viel Zeit in Figma. Nur beginnt das Projekt dort nicht mehr.

Was sich dadurch für Kunden ändert

Der praktische Effekt ist Tempo ohne die übliche Einbuße bei der Qualität. Kunden sehen innerhalb weniger Tage etwas, das sie anklicken können, und das verändert das Gespräch komplett. Feedback zu einem funktionierenden Produkt ist konkret. Feedback zu einem statischen Mock-up ist größtenteils Vorstellungskraft.

• Entscheidungen fallen früher, weil alle auf dasselbe echte Produkt reagieren.
• Bei der Übergabe geht weniger verloren, weil Design und Code nie weit auseinanderliegen.
• Das Design System wächst aus Komponenten, die es im Code schon gibt, und bleibt so synchron mit dem, was live geht.
• Das Budget reicht weiter, weil weniger Runden dafür draufgehen, Screens neu zu zeichnen, die ohnehin nie funktioniert hätten.

Wo es nicht passt

Diese Reihenfolge passt nicht für alles. Eine Markenidentität beginnt weiterhin mit Skizzen und Exploration, und manche Produktfragen lassen sich mit einem schnellen Papierprototyp besser beantworten als mit Code. Bei einer Marketing-Website mit einer starken visuellen Idee starten wir oft im Design und bauen danach.

Für digitale Produkte ist Code first inzwischen aber unser Standard. Das funktioniert nur, weil dieselben erfahrenen Leute denken, bauen und gestalten. Verteilt man das auf getrennte Teams, geht der Kontext verloren, und man rät wieder.

Wenn Sie ein Produkt planen und sehen möchten, wie das in der Praxis aussieht: Auf unserer Seite zur App-Entwicklung zeigen wir den Prozess Schritt für Schritt.