Figma oder direkt im Code?

Web-Design wurde lange in Photoshop gemacht, später in Sketch, heute in Figma. Parallel dazu hat sich ein zweiter Weg etabliert: Design entsteht direkt im Browser, im echten Code, mit echten Inhalten. Beide Wege führen zu funktionierenden Ergebnissen — aber sie unterscheiden sich erheblich in Geschwindigkeit, Detailtiefe und Folgekosten.

Dieser Artikel ordnet beide Ansätze pragmatisch ein und gibt eine Empfehlung, wann welcher Weg sich lohnt.

Figma ist nicht ohne Grund der heutige Standard im Design-Bereich. Die Vorteile im Überblick:

• Visuelle Abstimmung mit vielen Beteiligten. Wenn Marketing, Geschäftsführung, externe Berater und Entwickler gemeinsam auf ein Design schauen, ist Figma das gemeinsame Sprachrohr.
• Schnelles Iterieren auf Layout-Ebene. Verschiebungen, Variantenbildung, Stilexperimente lassen sich in einem Mockup zügiger durchspielen als in echtem Code.
• Klar definierte Übergabe an Entwicklung. Wenn Design und Entwicklung unterschiedliche Personen oder Teams sind, schafft Figma eine eindeutige Vertragsbasis: „Das ist das Soll-Bild."
• Komponenten- und Variantenkonzept. Komplexe Design-Systeme mit vielen Zuständen und Varianten lassen sich in Figma sauber strukturieren und versionieren.
• Schnelle Stakeholder-Freigabe. Ein Mockup kann in einer Stunde vorgestellt werden — auch wenn der Code dahinter Tage brauchen würde.

Für große Teams und Projekte mit klarer Rollentrennung ist Figma daher meist die richtige Wahl.

Bei kleineren Projekten und Teams — und besonders dort, wo Design und Entwicklung ohnehin in einer Hand liegen — hat das direkte Arbeiten im Browser deutliche Vorteile:

• Realistische Darstellung von Anfang an. Was im Browser entsteht, sieht später nicht ähnlich so aus, sondern genauso. Browser-Quirks, Schrift-Rendering, Pixel-Schärfe, mobile Eigenheiten — alles ist von der ersten Sekunde an Realität.
• Echte Inhalte statt Lorem ipsum. Texte, Bilder und Datenmengen verhalten sich erst im echten Layout, wie sie sich später verhalten werden. Lange Überschriften, leere Zustände, fehlende Bilder — all das sieht man im Code sofort.
• Keine Übergabeverluste. Was im Mockup harmonisch wirkt, scheitert im Code oft an Edge Cases, Performance oder technischer Machbarkeit. Wer im Browser entwirft, verhindert diese Lücke vollständig.
• Schneller bei der Endumsetzung. Was als Design entstanden ist, ist gleichzeitig schon der Anfang der Realisierung. Das spart erhebliche Zeit zwischen Entwurf und Live-Stand.
• Konsistenz mit dem späteren System. Komponenten entstehen direkt als wiederverwendbarer Code — kein „später nochmal sauber bauen".
• Echte Interaktion. Hover-States, Animationen, Übergänge, Scroll-Verhalten lassen sich nicht im Mockup beurteilen. Im Browser sind sie von Anfang an spürbar.

Figma passt vermutlich, wenn...

• viele Stakeholder involviert sind und ein gemeinsames visuelles Sprachrohr gebraucht wird.
• Design und Entwicklung getrennte Personen oder Teams sind.
• ein großes Design-System mit vielen Varianten und Zuständen sauber strukturiert werden muss.
• mehrere alternative Layouts für eine Stakeholder-Entscheidung visualisiert werden sollen.
• die Freigabe-Kette lang ist und Sicherheit über Zwischenstände wichtig ist.

Direkt im Code passt vermutlich, wenn...

• Design und Entwicklung aus einer Hand kommen.
• Geschwindigkeit und realistische Darstellung wichtiger sind als visuelle Vorabstimmung.
• Inhalte, Daten und Edge Cases früh sichtbar werden sollen.
• das Projekt sich an konkreten Komponenten statt an abstrakten Layout-Ideen orientiert.
• ein bestehendes Design-System schon im Code lebt und erweitert werden soll.

In vielen Projekten ist eine Mischung sinnvoll: Schnelle Skizzen oder Hauptseiten als Mockup, der Rest direkt im Code. So profitieren Sie von Figmas Stärken zur Abstimmung — und vermeiden den Zeitverlust, den eine vollständige Mockup-Phase mit sich bringt.

Drei Punkte, die in dieser Diskussion regelmäßig untergehen:

• Figma-Designs sind keine Realität. Ein Mockup zeigt einen Idealzustand. Sobald echte Inhalte auftreten — lange Produktnamen, leere Zustände, viele Items in einer Liste — kann das Erscheinungsbild deutlich abweichen. Wer das nicht einplant, baut Layouts, die sich im Alltag nicht halten.
• Designtools können Performance nicht beurteilen. Eine Animation, die in Figma elegant wirkt, kann im Browser ruckeln. Ein Hero-Bild, das beeindruckend aussieht, kann die Ladezeit verdoppeln. Diese Effekte sieht man erst in der Realität.
• „Design im Code" verlangt Code-Disziplin. Wenn Design direkt im Browser entsteht, müssen Komponenten, Tokens und Styles von Anfang an sauber strukturiert sein. Sonst entsteht ein Design-Chaos, das später schwerer zu pflegen ist als ein klares Mockup-System.

Wenn Design und Programmierung in einer Hand liegen, ist das Arbeiten direkt im Code meist der schnellere und realistischere Weg. Typischer Ablauf: kurze Skizzen oder Stichpunkte zur Klärung der Richtung, dann ein erster klickbarer Stand im Browser. Daran lässt sich konkret diskutieren — viel besser als an einem statischen Bild.

Wenn ein Projekt viele Beteiligte hat oder klar abgegrenzte Freigabeschritte verlangt, kann Figma ergänzend zum Einsatz kommen — gezielt für die Schlüsselseiten, nicht für jede Detailansicht. So bleibt Geschwindigkeit erhalten, ohne dass die Stakeholder-Abstimmung leidet.

Was sich für Ihr Projekt eignet, hängt von Größe, Beteiligten und Zeitplan ab. In den meisten Fällen reicht ein kurzes Erstgespräch, um die richtige Mischung zu finden.