📐 Die Figma Design System Checkliste: So gestalten Sie die perfekte Schnittstelle zwischen Design und Code

Es ist Montagmorgen, mein ProtonMail-Postfach piept, und der Kunde hat mir das neueste Figma Design System geschickt. Bei diesen Mails mache ich mir vorher extra einen Intenso-Kaffee, denn was ich vermutlich sehen werde, ist alles andere als ein fertiges System: eine einzige Primary-Farbe, zwei Buttons (gross und klein) und ein halbes Dutzend halbfertiger Basis-Komponenten. Keine Shades für Hover oder Active, keine Disabled-States, kein durchdachtes Error Handling – und Spacing-Regeln? Fehlanzeige. Diese Situation kennen Sie wahrscheinlich auch: Als Entwickler, der Figma-Designs in React-Komponenten umsetzt, erhalte ich oft „Design Systems", die eigentlich nur halbfertige Skizzen sind.

Manchmal ist nur eine Primary-Farbe definiert – doch welche Textfarbe soll ich damit verwenden? Häufig wird einfach angenommen, dass es Schwarz sein muss. Dabei ist Schwarz in der typografischen Lehre nicht einmal die empfohlene Farbe; stattdessen empfiehlt man einen Anthrazitton, der besser für das menschliche Auge ist. Manche Primärfarben sind bereits so dunkel, dass sie als Textfarbe eine invertierte Komplementärfarbe erfordern – also Weiss oder Weiss mit einem Hauch der Primärfarbe. Mit einer einzigen Farbe lässt sich keine ausdrucksstarke UX erzeugen. Was ist mit der Hover-Farbe? der Active-Farbe? Wie soll sich die Komponente im Focus-Zustand verhalten? Diese States sind nicht nur für Buttons relevant, sondern für sämtliche Inputs, Radio-Buttons, Checkboxes, Slider, Carousels und viele mehr.

Die Verantwortungs-Flucht: Ich erinnere mich an einen besonders denkwürdigen Fall: Statt eines klaren Design Systems landete bei mir ein Figma-File, das lapidar als „XYZ Brand Guideline“ deklariert war. Ein Verweis auf das unternehmenseigene Styleguide – als ob damit alle Fragen beantwortet wären. Doch die Vorgaben umfassten eher Themen wie die Vision, die Design-Prinzipien in Prosa, Tonfall und Begrifflichkeiten. Sie beschäftigen sich mit dem grossen Ganzen, nicht konkret mit den Design-Token, die für mich als Entwickler relevant sind. In diesem Moment wurde deutlich, wie viele Entscheidungsbefugnisse ins Leere laufen: Der Designer hatte keine klare Verantwortung, und im Projekt gab es keinen zweiten, der einspringen konnte. Ergebnis: endlose Meetings auf der Suche nach Zuständigkeiten, unzählige Nachfragen und verbrannte Entwickler-Stunden.

Dieser Konflikt ist symptomatisch für das generelle Dilemma zwischen Design und Entwicklung: Ohne eindeutige Rollenverteilung und verbindliche Übergaberegeln driftet das gesamte Projekt ins Niemandsland.

Der Entwickler als unfreiwilliger Designer: Ich musste erst die Design-Verantwortlichen identifizieren – in einem Umfeld, wo keiner diese Rolle wirklich übernehmen wollte. Wenn ich dann auf eigene Faust Vorschläge machte, kamen immer die Fragen: "Ist das denn abgesegnet?" Ich fühlte mich mit den Design-Entscheidungen allein gelassen. Letztendlich habe ich viele der Design-Entscheidungen selbst getroffen – im Geiste der Brand Guidelines. Das Ergebnis war gut, dem Team hat die Arbeit gefallen. Aber ich habe 30% meiner Zeit mit Design-Themen verbraten, die nicht meiner Kern-Kompetenz entsprechen. Wenn Entwickler Zeit mit Designaufgaben verbringen, die eigentlich in den Verantwortungsbereich von Designern gehören, geht wertvolle Fachkompetenz verloren und Projekte werden unnötig teuer und zeitaufwendig.

Inzwischen bin ich so vielen halbfertigen Figma Designs begegnet, dass ich mich auch auf der Design-Ebene als Professional bezeichnen könnte. Am Anfang bedeutete das oft Experimentieren und schauen, was gut aussieht – ohne Design-Fundamentals. Über die Jahre habe ich einiges zu Farbtheorie, Spacing-Regeln und Design-Grundlagen gelernt.

Dennoch: Als Entwickler kann ich einen grösseren Wert kreieren, als ich das als Design Lead könnte. Und genau da liegt das Problem. Was bleibt einem Entwickler übrig, wenn die Design-Expertise fehlt? Dem Designer hinterherzurennen, obwohl klar ist, dass auch er keine Antworten hat? Eigenmächtig Design Tokens zu erfinden – nur um später wieder in endlosen Abstimmungsrunden zu landen?
Der Kern des Übels sind nicht fehlende Fähigkeiten der Designer, sondern falsche Prioritäten, zu enge Zeitpläne und mangelndes Verständnis für die Bedeutung eines vollständig ausgearbeiteten Figma Design Systems. Diese Kluft zwischen Design und Entwicklung kostet Unternehmen täglich wertvolle Arbeitsstunden, führt zu inkonsistenten Interfaces und frustriert alle Beteiligten.

Diese Herausforderungen sind längst keine Einzelfälle mehr, sondern eher die Norm - sei es bei kleinen Mittelständlern oder etablierten Grosskonzernen in der Schweiz und in Deutschland. Doch was benötigen wir Entwickler konkret, um eine qualitative hochwertige Komponenten-Bibliothek aufzubauen?

Design Tokens - die gemeinsame Sprache von Designer und Entwickler

Eine gemeinsame Sprache? Für Designer bedeutet das, Design Token im Figma Dokument zu verankern. Für Entwickler bedeutet das, diese Design Tokens zu extrahieren und kompatibel mit dem eingesetzten CSS Framework zu machen. CSS hat sich in den letzen Jahren stetig weiterentwickelt von BEM (Block-Element-Modifier), SCSS, CSS Modules, über CSS-in-JS Lösungen wie styled-components, hin zum aktuell unangefochtenen Platzhirsch TailwindCSS.

Warum TailwindCSS die Oberhand gewonnen hat: TailwindCSS bietet eine systematische Herangehensweise mit vorgefertigten Utility-Klassen, die direkt mit Design Tokens korrespondieren. Statt eigene Abstraktionen zu erfinden, arbeitet man mit einem bewährten System aus Spacing-Skalen (space-1 bis space-96), Farbpaletten (primary-50 bis primary-950) und Typography-Hierarchien (text-xs bis text-9xl). Das reduziert nicht nur die Komplexität, sondern schafft auch eine einheitliche Sprache zwischen Design und Development – genau das, was wir für eine reibungslose Zusammenarbeit brauchen. TailwindCSS liefert zudem die effektivste Lösung in puncto Bundle-Size: Durch die integrierte Purge-Funktion werden ungenutzte Utility-Klassen automatisch entfernt, sodass nur das im finalen Build landet, was tatsächlich verwendet wird.

TailwindCSS hat die Interaktion zwischen Designer und Entwickler in den letzten Jahren massgeblich geprägt und verändert. Adam Wathan erkannte früh, dass Design Systeme auf der Entwicklerseite konkrete, strukturierte Design Tokens benötigen die leicht zu implementieren waren.

Design Tokens sind in 2025 lediglich noch CSS Variablen.

Welche wir zur Umsetzung eines Design Systems alle brauchen schauen wir uns jetzt im Detail an.

Farben

Das wichtigste sind Farben. Dabei reicht es nicht nur einen einzigen Farbton zu haben. Wir brauchen mindestens eine Farbpalette die auf einem Grundton beruht. Ein vorbildliches Figma Design müsste diese Farbpalette für die Primärfarbe zwingend enthalten. Wieso ist die Farbpalette wichtig? Sie bringt Tiefe und Leben in das Design. Sie simuliert Bewegung und Interaktion. Da die Farben aber alle verwandt sind und mathematisch auf Basis des Grundtons berechnet wurden, fühlt es sich nicht an als wären "mehrere" Farben am Werk.

--color-primary-50: #f3f6fb;
--color-primary-100: #e5e8f4;
--color-primary-200: #d0d8ed;
--color-primary-300: #b0bfe0;
--color-primary-400: #8a9dd0;
--color-primary-500: #6f80c2;
--color-primary-600: #5c68b4;
--color-primary-700: #5159a4;
--color-primary-800: #464a87;
--color-primary-900: #3a3e69;
--color-primary-950: #282943;

Wenn ich nur einen Farbton vom Kunden erhalte, dann erstelle ich mir die Palette selbst mit Hilfe des TailwindCSS Color Generator. Es lässt sich damit sehr gut visualisieren, wie das Farbschema in einer konkreten Anwendung wirkt.

Ich würde immer eine Sekundär-Farbpalette ebenfalls empfehlen. Ein guter Designer weiss, welche Sekundär-Farbton nach der Farblehre die Primärfarbe gut ergänzt.

--color-secondary-50: #f3faf3;
--color-secondary-100: #e5f4e4;
--color-secondary-200: #cae8ca;
--color-secondary-300: #a0d5a1;
--color-secondary-400: #6eba70;
--color-secondary-500: #4fa851;
--color-secondary-600: #38813a;
--color-secondary-700: #2f6631;
--color-secondary-800: #29522b;
--color-secondary-900: #234425;
--color-secondary-950: #0f2411;

Dark Theme: Das Figma Design würde auf Basis dieser Farbpaletten die Komponenten visualisieren. Ein modernes und vollständiges Figma Design würde sich auch mit der Frage beschäftigen wie im Dark Theme die Komplementärfarben der jeweiligen Farbpalette zum Einsatz kommen würden. Das bedeutet: Ein text-secondary-700 dark:text-secondary-50 übersetzt sich elegant in die Anweisung „Verwende einen kräftigen Sekundärfarbton für das helle Theme und einen sehr hellen, fast weissen Ton mit einem Hauch Sekundärfarbe für das dunkle Theme" – präzise, unmissverständlich und für beide Seiten sofort nachvollziehbar.

Layout

Unter Layouts verstehe ich insbesondere Breakpoints, Spacing und BorderRadius. Breakpoints ist ein Synonym für das Responsive Design. Es entscheidet wie eine Komponente sich bei unterschiedlich viel Bildschirmbreite verhält. Eine Komponente auf dem Mobiltelefon wird anders dargestellt wie eine Komponente auf einem grossen Bloomberg Terminal. Jedes Unternehmen entscheidet für sich welche Nutzergruppen für sie wichtig sind und welche und wie viele Breakpoints sie unterstützen wollen. Hier ist ein Beispiel wie eine grosse Versicherung in der Schweiz das handhabt:

--breakpoint-xs: 480px;
--breakpoint-sm: 640px;
--breakpoint-md: 768px;
--breakpoint-lg: 1024px;
--breakpoint-xl: 1280px;
--breakpoint-2xl: 1440px;
--breakpoint-3xl: 1536px;
--breakpoint-4xl: 1920px;

Der Border-Radius beschäftigt sich mit der Frage wie viel Rundung an den Ecken der jeweiligen Komponenten (Button, Card, Accordion, etc.) aufgetragen wird. Manche setzen diesen Wert auf 0px (gar kein Border-Radius), und andere wieder herum tragen dick auf. Meiner Meinung nach hat der Border-Radius ein sehr starken Einfluss auf die Brand-Identität des Unternehmens. Im letzten Projekt hatte ich 2 CSS Variablen für den Border-Radius bestimmt. Das --radius-theme wurde eigentlich überall verwendet. Aber bei der Switch Komponente wollte man von dieser Regel abweichen. Ein modernes Figma Design System muss solche Wünsche berücksichtigen können, genauso wie es TailwindCSS in der Lage ist dies zu tun.

--radius-theme: 0px;
--radius-switch: 2px;

Der letzte wichtige Punkt beim Thema Layout ist das Spacing. Hier kann man sagen, dass TailwindCSS den Nagel auf den Kopf getroffen hat. Die Default Einstellungen von TailwindCSS im Bezug auf Abstände sind so gut und universell einsetzbar, dass ich in den letzten 5 Jahren seitdem ich das Framework verwende noch für keinen Kunden bisher von der Norm abweichen musste. Es gab ein Fall, bei dem ein Kunde bei einer Anwendung mit vielen Form-Elementen einheitlich eine Sondergrösse einführen wollte. Unter jedem Form-Element sollte gleich viel Abstand etabliert werden. Guess what, TailwindCSS hat eine Lösung dafür:

--spacing-field: 1.25rem;

Typographie

Die dritte grosse Pfeiler eines vollständigen Design Systems beschäftigt sich mit der Typographie. Wir unterscheiden zwischen System Font und Accent Font, wobei letzteres optional ist. Genau so wie Ihre Handschrift, sagt die Font einiges über den Charakter des Unternehmens. Es spielt eine zentrale Rolle beim Aufbau einer eigenen Identität. Doch wer meint, es geht nur darum diese 2 Fonts zu wählen, der irrt. Die Schriftgrösse und die Line-Height sind wichtige Elemente die das Look und Feel der Seite beeinflussen. Laut TailwindCSS haben sich 11 unterschiedliche Schriftgrössen etabliert. Doch anders wie beim Thema Spacing sind Schriftgrösse und Line-Height fundamentale Brand Identity Elemente. Ein gutes Figma Design muss mir die verwendeten Grössen einschliesslich der jeweiligen Line-Height kommunizieren. In Design Token Sprache bedeutet das Folgendes:

--font-system: 'Manrope';
--font-accent: 'Pigarnos Neue';

--text-xs: 0.8rem;
--text-xs--line-height: 1rem;
--text-sm: 0.9rem;
--text-sm--line-height: 1.1rem;
--text-lg: 1.2rem;
--text-lg--line-height: 1.4rem;
--text-xl: 1.3rem;
--text-xl--line-height: 1.5rem;
--text-2xl: 1.4rem;
--text-2xl--line-height: 1.6rem;
--text-3xl: 1.6rem;
--text-3xl--line-height: 1.8rem;
--text-4xl: 1.8rem;
--text-4xl--line-height: 2rem;
--text-5xl: 2rem;
--text-5xl--line-height: 2.2rem;
--text-6xl: 2.2rem;
--text-6xl--line-height: 2.4rem;
--text-7xl: 2.4rem;
--text-7xl--line-height: 2.5rem;
--text-8xl: 2.5rem;
--text-8xl--line-height: 2.75rem;

Schattierung

Für das Thema Schattierung bietet TailwindCSS out of the box eine Reihe von nützlichen Utility-Klassen. Doch Schattierung kann sehr individuell sein mit vielen Parametern und daher bieten die von Haus aus bereit gestellten Klassen nicht immer das gewünschte Ergebnis. Auch hierfür hat TailwindCSS eine Lösung. Ein gutes Figma Design geht auf die Schattierung in den jeweiligen Umweltzuständen der Komponenten explizit ein. Hier ist ein Beispiel aus einem Kundenprojekt wie wir die Schattierungsvorgaben aus dem Figma Design in TailwindCSS portiert haben, und zwar mit Hilfe der @utility Funktion:

@utility shadow-inner-sm {
  box-shadow: inset 0 -1px 0 0 rgba(0, 0, 0, 0.2);
}

@utility shadow-inner-md {
  box-shadow: inset 0 -2px 0 0 rgba(0, 0, 0, 0.2);
}

@utility shadow-inner-lg {
  box-shadow: inset 0 -4px 0 0 rgba(0, 0, 0, 0.2);
}

Animation

Zu guter Letzt möchte ich auf das Thema Animationen eingehen. Sie spielen eine wichtige Rolle in modernen Design Systemen. Nach meiner persönlichen Präferenz gilt die Devise weniger ist mehr. Genau so viel Animation, dass sich etwas in Bewegung setzt, ohne dass die Nutzer diese Bewegung bewusst wahrnehmen. Es ist wichtig zu verstehen, dass es bei Animationen 2 verschiedene Arten existieren, einmal JavaScript-basiert und einmal basierend auf CSS. Es gilt dabei der Grundsatz, CSS Animation > JS Animation. Sollte es möglich sein eine Animation mittels CSS zu implementieren, ist diese der JS Variante zu bevorzugen. Hier ist ein Beispiel welche Animationen wir bei Kolaveri Labs verwenden und wie das ganze in Design Token Sprache aussehen würde:

--animate-scale-out: scale-out linear 1 forwards;
@keyframes scale-out {
  0% {
    transform: scaleX(1);
  }
  100% {
    transform: scaleX(0);
  }
}

--animate-slide-in-right: slide-in-right 300ms ease-in-out forwards;
@keyframes scale-in-right {
  0% {
    transform: translate3d(110%, 0, 0);
    visibility: visible;
  }
  100% {
    transform: translate3d(0, 0, 0);
  }
}

--animate-slide-out-right: slide-out-right 300ms ease-in-out forwards;
@keyframes scale-out-right {
  0% {
    transform: translate3d(0, 0, 0);
  }
  100% {
    visibility: hidden;
    transform: translate3d(110%, 0, 0);
  }
}

Fazit: Design Tokens sind der kleinste gemeinsame Nenner zwischen Design und Entwicklung

Wenn Sie die in diesem Beitrag vorgestellten Design Tokens direkt aus Ihrem Figma-File ableiten können, gehört Ihr System bereits zur obersten Liga – den besten 10% aller Design Systeme in der Schweiz.

Für mehr Inspiration schauen Sie sich unbedingt das Arco UI Kit und das Spotify Backstage Open Source Design System in der Figma Community an. Beide Vorlagen demonstrieren praxisnah, wie eine perfekte Brücke zwischen Design und Code aussieht – und liefern Ihnen wertvolle Impulse für Ihr eigenes System.