Ein Designsystem aus einer importierten Website in Figma aufbauen

Ein Import liefert dir Ebenen, kein Designsystem. Um von dem einen zum anderen zu kommen, prüfst du die Werte, die die Seite wiederholt, fasst nahezu gleiche Werte zu einer Skala zusammen und benennst den Rest als primitive und semantische Tokens in Figma. Dieses Tutorial setzt voraus, dass du die Seite bereits in Figma hast und dich mit Variablen auskennst. Stand Oktober 2026 musst du das meiste von Hand erledigen.

Die Schritte funktionieren für den Relaunch einer Website ohne Designdatei, für die Analyse der Seite eines Wettbewerbers oder für den Neubau einer Altseite. Das Ziel ist ein kleines System, das du wirklich pflegen kannst, kein vollständiges Inventar von allem, was auf der Seite zufällig vorkommt. Rechne bei einer typischen Marketingseite mit ein bis zwei Stunden, bei einer Produktoberfläche mit vielen Zuständen mit mehr. Plane die Zeit lieber großzügig ein, denn das Benennen kostet mehr Überlegung als das Zählen. Die Voraussetzung ist einfach: eine importierte Seite, geöffnet in Figma, mit aufgelösten Schriftarten und Bearbeitungsrechten für die Datei, in der die Variablen liegen werden.

Den Import prüfen, bevor du etwas benennst

Beginne damit, den Import aufzuräumen. Lösche versteckten Ballast und reduziere Ebenen, die nur wegen der Bauweise der Seite existieren. Wer Tokens auf Unordnung setzt, gibt dem Müll bloß einen ordentlichen Namen.

Sammle dann, was sich wiederholt. Du brauchst fünf Listen:

1. Füll- und Textfarben
2. Schriftgrößen, mit Gewicht und Zeilenhöhe
3. Abstandswerte (padding und gap)
4. Eckenradien
5. Schatten

Zähle, wie oft jeder Wert vorkommt, und notiere die Zahl direkt neben dem Wert. Ein Wert, der einmal auftaucht, ist ein Einzelfall und kein Token. Ein Wert, der zwölfmal auftaucht, ist ein Kandidat.

Eine Grenze, die man klar benennen sollte: Die UnHTML-Produktseite sagt nicht, dass CSS Custom Properties oder Design-Tokens der Quellseite nach Figma übernommen werden. Behandle den Import als Rohwerte und baue die Variablen selbst. Figmas eigene Webseiten-Erfassung ist anders, und darauf gehen wir gegen Ende ein.

Nahezu gleiche Werte zu einer Skala zusammenfassen

Echte Seiten sind unordentlich. Du findest vier Grautöne, die sich nur um wenige Punkte Helligkeit unterscheiden, und Padding-Werte wie 14px, 15px und 16px nebeneinander. Wähle pro Gruppe einen Wert und richte die übrigen daran aus. Nimm im Zweifel den Wert, der am häufigsten vorkommt, denn er verursacht die kleinste sichtbare Veränderung.

Führe eine Arbeitstabelle, damit die Entscheidungen sichtbar bleiben:

Jage nicht jedem Ausreißer hinterher. Wenn ein Wert nur ein- oder zweimal vorkommt und nicht in die Skala passt, lass ihn als lokale Abweichung stehen. Halte den ersten Durchgang kleiner, als die Prüfung nahelegt. So lässt er sich leichter begründen und leichter erweitern. Ein System mit zwanzig gut gewählten Tokens wird eher genutzt als eines mit zweihundert, von dem niemand weiß, welche davon gelten.

Erst primitive Tokens, dann semantische

Figmas Leitfaden zu Tokens trennt Tokens in Ebenen, und diese Trennung ist das Rückgrat des Systems.

Primitive definieren, was es gibt

Primitive Tokens listen jeden Wert im System auf, etwa jede Markenfarbe oder jede Abstandsstufe. Figma beschreibt sie als "for reference only" (nur zur Referenz), du wendest sie also nicht direkt in Entwürfen an. Benenne sie nach dem Wert, zum Beispiel gray/500 oder space/16.

Semantische sagen, wie man es verwendet

Semantische Tokens tragen die Absicht. In Figmas Beispiel zeigt surface/brand-contrast auf das Primitiv pink/400. Weil semantische Tokens Aliase der primitiven sind, aktualisiert eine Änderung am Basiswert alles, was davon abhängt. Nimm ausgeschriebene Wörter statt Abkürzungen und halte die Präfixe einheitlich, damit die Namen auch gültig bleiben, wenn das System wächst.

Komponenten-Tokens, nur bei Bedarf

Ein Komponenten-Token benennt, wo ein Wert gilt, in der Form button-primary-background-default. Ergänze sie, wenn eine Komponente von der gemeinsamen semantischen Ebene abweichen muss. Im ersten Durchgang kannst du sie überspringen.

Variablen für Werte, Styles für Zusammengesetztes

Figma-Variablen und Styles erledigen unterschiedliche Aufgaben. Die meisten Teams nutzen beide. Variablen unterstützen Aliase, mehrere Modi für Themes, Geltungsbereiche und Code Syntax. Styles halten zusammengesetzte Werte, etwa mehrere Füllungen oder mehrere Schatten auf einer Ebene.

Für eine importierte Seite hat das eine praktische Folge. Einzelwerte wie Farben, Abstände und Radien kommen in Variablen. Ein mehrlagiger Schatten bleibt ein Style, und ein Verlauf ebenfalls, weil Variablen keine Verläufe aufnehmen können. Wie diese beiden von der Seite ankommen, erfährst du unter wie box-shadow in einen Figma-Effekt übersetzt wird und was mit CSS-Verläufen passiert.

Die Tokens als CSS Custom Properties spiegeln

Wenn ein Entwickler das System umsetzt, gib ihm passende Tokens. Die MDN-Referenz ist bei den wichtigen Regeln eindeutig: Custom Properties gelten im Bereich der Elemente, auf denen sie deklariert sind, sie nehmen an der Kaskade teil und werden vererbt. Namen unterscheiden Groß- und Kleinschreibung, zwei Schreibweisen desselben Namens sind also zwei verschiedene Eigenschaften.

Eine minimale Spiegelung der Tabelle oben sieht so aus:

:root {
  --gray-500: #6b7280;
  --space-16: 16px;
  --radius-4: 4px;

  --text-secondary: var(--gray-500);
  --card-padding: var(--space-16);
}

Der erste Block ist die primitive Ebene. Der zweite ist die semantische Ebene, geschrieben als Aliase mit var(). Die Struktur entspricht den Figma-Sammlungen eins zu eins.

Gute Namen zahlen sich ein zweites Mal aus. Wenn du eine Seite mit Figmas eigener Webseiten-Erfassung erfasst, bindet Figma CSS-Variablen in fester Reihenfolge an Figma-Variablen: Zuerst gleicht es den CSS-Namen mit der Code Syntax der Variablen ab, dann mit dem Variablennamen, und zuletzt greift es auf die am besten passende Variable mit dem engsten Geltungsbereich zurück. Definiere die Code Syntax deiner Variablen, halte die CSS-Namen lesbar und erfasse von einem Entwicklungsserver, auf dem Build-Werkzeuge die Namen nicht verfälscht haben. Farbvariablen mit Deckkraft werden nicht gebunden, prüfe sie also von Hand.

Das System gegen die Seite prüfen

Ein Token-Satz ist nur dann etwas wert, wenn er die Seite nachbauen kann, von der du ausgegangen bist. Wähle zwei oder drei repräsentative Frames aus dem Import und binde deren Füllungen, Textfarben, Padding und Eckenradius neu an die neuen Variablen, ausgehend von der semantischen Ebene. Vergleiche das Ergebnis dann mit dem Original.

Rechne mit kleinen Verschiebungen. Wenn du 14px und 15px Padding auf 16px angleichst, verschiebt sich alles um ein bis zwei Pixel, und das ist der Preis, den du beim Zusammenfassen der Skala gewählt hast. Ist eine Verschiebung groß genug, um das Layout zu verändern, war die Gruppe falsch: Teile sie in zwei Tokens auf oder behalte den Ausreißer als lokale Abweichung. Dieser Abgleich ist der schnellste Weg, Fehler in der Skala zu finden, bevor andere darauf aufbauen. Hier findest du auch die Werte, die die Prüfung übersehen hat, etwa eine Hover-Farbe, die nur in einer Komponente vorkommt.

Das System so benennen, dass andere es nutzen können

Halte fest, wofür jede Sammlung gedacht ist. Eine kurze Beschreibung an jeder Variablensammlung genügt: um welche Ebene es sich handelt (primitiv oder semantisch), ob Designer sie direkt anwenden dürfen und wer für Änderungen zuständig ist. Nutze die Geltungsbereichs-Optionen der Figma-Variablen, damit eine Abstandsvariable nicht in der Farbauswahl erscheint.

Wenn du zusätzlich die CSS-Spiegelung pflegst, behandle die Figma-Sammlungen als maßgebliche Quelle und aktualisiere das Stylesheet, sobald sie sich ändern. Zwei maßgebliche Quellen laufen schnell auseinander. Dunkelmodus und andere Themes sind der eine Fall, in dem sich ein zweiter Modus früh lohnt, weil sich dank der Aliase zwischen den Modi nur die semantische Ebene ändert.

Komponenten und Styles kommen danach

Sobald die Tokens existieren, ist Wiederverwendung der nächste Schritt. In Pro macht UnHTML aus wiederkehrender Typografie gemeinsame Textstile und aus wiederholten Elementen Komponenten, wie in eine Pro-Importseite in Komponenten und Textstile verwandeln beschrieben. Mach zuerst die Tokens. Dann haben Komponenten und Textstile echte Variablen, an die sie sich binden können, statt loser Hex-Werte.

Fazit

Prüfe, was die Seite wiederholt, gleiche nahezu identische Werte zu einer Skala an und teile das Ergebnis in primitive und semantische Tokens. Lege Einzelwerte in Variablen ab, behalte Zusammengesetztes als Styles und spiegle die Namen in CSS, damit Designer und Entwickler dasselbe Vokabular teilen. Fang klein an, lass die Skala mit dem Projekt wachsen und füge ein Token erst hinzu, wenn ein Wert es sich verdient. Der Import erspart dir den Nachbau der Seite. Das System bleibt deine Entscheidung.