Slots sind nicht optional. Wer ein Figma-System betreut, das mehr als eine Handvoll Komponenten umfasst, braucht sie – oder kämpft irgendwann gegen ein Monster aus Varianten, das niemand mehr versteht.
Das Prinzip ist schnell erklärt: Statt Komponenten mit festem Inhalt zu bauen, definierst du Platzhalter. Ein Button bekommt keinen hartcodierten Text und kein fixes Icon. Er bekommt einen Slot – einen definierten Bereich, den der Nutzer der Komponente selbst befüllt. Was da reinkommt, liegt nicht mehr in der Komponente selbst, sondern beim Team, das sie verwendet.
#Warum das den Unterschied macht
Stell dir vor, du baust einen Button. Variante mit Icon links, Variante mit Icon rechts, Variante ohne Icon, Variante mit zwei Icons, Variante mit Badge. Irgendwann hast du zwanzig Varianten für ein Element, das eigentlich eine einzige Aufgabe hat. Wartung wird zum Vollzeitjob.
Mit Slots baust du stattdessen eine Komponente – und lässt die Platzhalter die Arbeit machen. Das Icon-Slot nimmt an, was reingegeben wird. Kein Icon? Slot bleibt leer. Anderes Icon? Einfach tauschen. Die Komponente selbst bleibt stabil.
Das reduziert Wartungsaufwand massiv. Nicht ein bisschen – massiv. Jede Variante, die du nicht baust, ist eine Variante, die du nicht pflegen, dokumentieren und erklären musst.
#Die Verantwortung richtig verteilen
Was Slots konzeptuell leisten, ist interessanter als es klingt: Sie verteilen Verantwortung sauber. Die Komponente definiert Struktur, Verhalten und Grenzen. Der Nutzer der Komponente entscheidet über den Inhalt.
Das ist kein kosmetischer Unterschied. Komponenten ohne diese Logik werden auf zwei Arten kaputt: entweder zu starr – sie decken keine Anwendungsfälle ab, die niemand vorhergesehen hat – oder zu aufgebläht, weil jeder neue Anwendungsfall eine neue Variante erzeugt. Beide Enden des Spektrums machen das System unbenutzbar.
Slots lösen genau dieses Dilemma. Nicht weil sie elegant aussehen, sondern weil sie das Richtige an der richtigen Stelle entscheiden lassen.
#Der Haken: Disziplin beim Setup
Hier ist der Teil, den viele übersehen. Slots funktionieren nur, wenn du sie konsequent benennst und dokumentierst. Ein Slot namens „Content" sagt niemandem, was da reingehört. Ein Slot namens „leading-icon" oder „action-button" schon.
Schlechte Benennung schafft neue Verwirrung. Du hast dann zwar weniger Varianten, aber niemand weiß, welchen Slot er befüllen soll, was erlaubt ist und was nicht. Das System sieht aufgeräumt aus, funktioniert aber nicht.
Deshalb gehört zur Slot-Logik immer eine klare Konvention. Wie heißen Slots? Was darf rein, was nicht? Gibt es Default-Inhalte, die zeigen, wie der Slot gedacht ist? Diese Fragen musst du beantworten, bevor du anfängst – nicht danach.
#Was das für bestehende Systeme bedeutet
Wenn du ein bestehendes Figma-System hast, lohnt sich ein ehrlicher Blick auf die Varianten-Struktur. Wo gibt es Komponenten mit mehr als fünf oder sechs Varianten, die sich nur durch ihren Inhalt unterscheiden? Genau dort sind Slots die richtige Antwort.
Das bedeutet nicht, dass du alles auf einmal umbaust. Starte mit einer Komponente, die besonders viele inhaltliche Varianten hat. Baue sie mit Slot-Logik neu. Dokumentiere die Benennung. Dann ziehe das Muster durch.
Systeme wachsen selten durch große Redesigns. Sie wachsen durch konsequente kleine Entscheidungen, die sich addieren.
#Gegenargument: "Slots machen Komponenten schwerer zu verstehen"
Das höre ich manchmal. Und es stimmt – ein bisschen. Wer zum ersten Mal mit einer Slot-basierten Komponente arbeitet, muss verstehen, was ein Slot ist und wie er funktioniert. Das ist ein echter Lernaufwand.
Aber der Vergleich ist falsch. Die Alternative sind nicht einfachere Komponenten – die Alternative ist ein System mit zwanzig Varianten, durch das sich niemand zurechtfindet. Slots machen Komponenten konzeptuell etwas anspruchsvoller, aber das System als Ganzes deutlich zugänglicher.
Der Schlüssel ist Dokumentation. Wenn du erklärst, wie Slots funktionieren und was in welchen Slot gehört, verschwindet die meiste Verwirrung. Das ist kein Argument gegen Slots – es ist ein Argument dafür, sie bewusst und sauber einzuführen.
#Praktische Takeaways
Wenn du jetzt anfangen willst, hier ist was konkret hilft:
Audit zuerst. Schau dir deine Komponenten an und markiere alle, bei denen Varianten nur durch Inhalt entstehen. Das sind deine Slot-Kandidaten.
Benennungskonvention festlegen. Entscheide dich für ein Schema – zum Beispiel [position]-[typ] wie leading-icon oder trailing-action – und ziehe es durch. Konsequenz ist wichtiger als Perfektion.
Default-Inhalte setzen. Gib jedem Slot einen sinnvollen Default. Das macht die Komponente selbsterklärend und zeigt, was da reingehört.
Dokumentiere den Slot-Zweck. Nicht nur den Namen, sondern auch: Was darf rein? Was nicht? Gibt es Größenbeschränkungen oder Verhaltensregeln? Ein kurzer Kommentar in Figma reicht oft.
Klein anfangen. Eine Komponente umbauen, Feedback einholen, Muster verfeinern. Dann skalieren.
Slots sind keine Magie. Sie sind eine strukturelle Entscheidung, die du bewusst treffen und konsequent umsetzen musst. Wer das tut, baut Systeme, die andere tatsächlich benutzen wollen – und nicht heimlich umgehen.
