Webdesign und Engineering — kein Widerspruch
Warum die Trennung zwischen Designer und Developer das Hauptproblem ist, das die meisten Websites mittelmäßig macht.
In den meisten Studios sitzen Designer und Entwickler in getrennten Räumen. Sie sprechen unterschiedliche Sprachen. Der Designer denkt in Komposition, Hierarchie, Atmosphäre. Der Entwickler denkt in Performance, Strukturen, Kanten-Fällen. In jeder Übergabe verliert die Arbeit etwas — kleine Anpassungen, Kompromisse, “das geht so nicht” und “das war so nicht gemeint”.
Ich glaube, das ist der Hauptgrund, warum die meisten Websites sich anfühlen wie sie sich anfühlen.
Wo es bricht
Eine Animation, die im Figma-Prototype 80% gut aussieht, kommt im Code als 60%-Version raus. Eine Typografie-Idee, die ein präziser Designer baut, wird im Build mit der falschen Schriftgröße oder dem falschen Zeilenabstand umgesetzt. Ein Hover-State, der eigentlich subtil sein sollte, wird laut, weil der Standard-Easing-Wert verwendet wurde.
Das sind keine großen Fehler. Das sind tausend kleine. Sie summieren sich.
Was passiert, wenn ein Mensch beides macht
Wenn ich am Morgen ein Detail im Designsystem ändere, sehe ich es am Mittag im Build. Wenn der Build sich anders verhält als erwartet, weiß ich sofort warum — weil ich auch das CSS geschrieben habe. Wenn der Animation der letzte Schliff fehlt, kann ich an der GSAP-Timeline drehen, ohne erst eine Stunde lang einem anderen Menschen erklären zu müssen, was ich meine.
Es geht schneller. Aber wichtiger: das Endergebnis ist näher dran an der ursprünglichen Idee.
Das ist kein Skill-Argument
Ich behaupte nicht, dass ich ein besserer Designer bin als jemand, der nur designt. Oder ein besserer Entwickler als jemand, der nur entwickelt. Das wäre falsch.
Was ich glaube: für eine Website unter einem bestimmten Komplexitäts-Schwellwert — sagen wir, eine Studio-Website, eine Marken-Site, ein Portfolio mit zehn bis fünfzig Seiten — ist die Person, die beides halbwegs gut macht, näher am guten Ergebnis als zwei Spezialisten in einem Übergabe-Verhältnis.
Über diesem Schwellwert wird es anders. Aber dort baue ich sowieso nicht.
Was das praktisch bedeutet
In meinem Workflow ist Figma kein Übergabe-Dokument. Es ist eine Skizze. Die echten Entscheidungen passieren im Browser, im Code, mit echtem Inhalt. Eine Komposition kann auf einem Figma-Frame stimmen und im echten Browser nicht funktionieren — wegen der Schrift-Rendering-Unterschiede, wegen der Ladereihenfolge, wegen Browser-Defaults.
Also designe ich im Browser. Nicht ausschließlich. Aber spätestens ab Phase zwei.
Das ist nicht jedermanns Sache. Es ist meine.