Figma Slots: Guide und Experten Review (April 2026)

Genau das war der Ausgangspunkt für diesen Artikel. Wir haben Figma Slots im Kontext eines laufenden komplexen Projekts mit eigenem Designsystem bewertet. Das Ziel? Sehen, ob Slots Ordnung ins Chaos bringen können.

Figma Slots gingen am 5. März 2026 in die offene Beta. Sie wurden angekündigt auf der Schema 2025 und seitdem in enger Zusammenarbeit mit Kunden auf Basis realer Workflows verfeinert. Zum Zeitpunkt dieses Artikels sind sie neu genug, dass viele Designer sie noch nicht ausprobiert haben. Und genau deshalb gehen wir hier tiefer: 

‍

Was sind Figma Slots?

‍

Welche Probleme lösen sie?

‍

Wie erstellt man sie?

‍

Dazu zeigen wir drei konkrete Anwendungsfälle aus einem echten Projekt, die wichtigsten Regeln für den Teameinsatz und natürlich auch eine ehrliche Einschätzung der aktuellen Beta.

TL;DR: Das Wichtigste in Kürze

• Figma Slots sind flexible Bereiche in Komponenten. Sie erlauben es, Inhalte in Instanzen einzufügen, zu entfernen oder umzuordnen, ohne die Instanz zu detachen.
  
• Drei alte Workarounds werden überflüssig: Detachen, Hide/Show und Duplizieren hatten allesamt jeweils erhebliche Nachteile für Dateigröße, Konsistenz und Wartung.
  
• Erstellt werden Slots in drei Schritten: Frame innerhalb einer Komponente anlegen, zum Slot konvertieren (Rechtsklick, Toolbar oder Shift + Cmd + S), Auto Layout konfigurieren.
  
• Praxistest mit drei Anwendungsfällen: Modale, Kapitel-Boxen und FAQ-Listen profitieren direkt von Slots, mit messbarem Reduktionspotenzial bei Varianten.
  
• Slots ersetzen Varianten nicht. Varianten bleiben für Zustände (offen/geschlossen, aktiv/inaktiv) relevant; Slots lösen das Problem variabler Inhalte in konstanten Hüllen.
  
• Beta-Status ernst nehmen. Stabil genug zum Testen, aber Rollout erst nach laufenden Projektübergaben empfohlen, dann gezielter Cleanup des Design Systems.

Einleitung

Stellen Sie sich vor, Sie öffnen Ihr Design System und zählen die Modale. 20 Stück. Alle sehen fast gleich aus. Keines ist wirklich überflüssig, aber keines ist wirklich einzigartig. Genau so sah es bei uns in einem Projekt aus; und das war zugleich der Auslöser, Figma Slots ernsthaft zu evaluieren.

‍

Unsere Erfahrungen aus der Praxis wollen wir (neben einer Erklärung, was Figma Slots überhaupt sind) teilen: Die drei Workarounds, die Slots ablösen. Eine Schritt-für-Schritt-Anleitung zum Erstellen. Vier konkrete Anwendungsfälle aus dem laufenden Projekt. Regeln für den Teameinsatz. Und eine ehrliche Einordnung, wann Slots bereit sind für den Produktionseinsatz.

Das Problem, das Slots lösen

Bevor es Figma Slots gab, standen Design Teams vor einem Trilemma: Wie passt man Komponenten an verschiedene Inhalte an, ohne dabei die Konsistenz des Design Systems zu opfern oder die Dateigröße unkontrolliert wachsen zu lassen? 

‍

Jeder der drei gängigen Workarounds löste ein Problem und schuf dafür ein neues.

‍

Workaround 1: Detachen. Die schnellste Lösung, wenn eine Instanz nicht ganz passt. Einfach detachen, Anpassung vornehmen, weiterarbeiten. Das Problem entfaltet sich schleichend: Die detachte Komponente verliert ihre Verbindung zum Design System. Wenn sich die Hauptkomponente ändert (neues Padding, andere Border-Radius oder aktualisierte Farben) bekommt die detachte Instanz davon nichts mit. 

‍

Workaround 2: Hide/Show. Die vermeintlich klügere Lösung: Alle denkbaren Elemente in die Hauptkomponente packen und in den Instanzen einfach unsichtbare Teile ausblenden. In der Theorie elegant. In der Praxis ein Desaster. 

‍

„Wir hatten das ja mal so lösen wollen, dass wir alles in einem hatten und Sachen einfach versteckt hatten. Am Ende brachten wir immer mehr Gewicht in unsere Files, weil so viel versteckt ist."

‍

Unsichtbar heißt eben nicht weg. Die Dateigröße wächst, die Komponenten werden unübersichtlich, und gerade für neue Teammitglieder ist das System kaum zu überschauen.

‍

Workaround 3: Duplizieren. Für jede Variation eine eigene Komponente erstellen. Klingt zunächst nach dem saubersten Ansatz, führt aber zu einem Design System, das unkontrolliert wächst. 20 fast identische Modal-Varianten waren das Ergebnis in unserem Fall. Jede einzelne hatte ihre Berechtigung und trotzdem war keine davon als eigenständige Komponente wirklich notwendig.

‍

Hier die drei Workarounds im direkten Vergleich:

‍

Alle drei Methoden teilen einen fundamentalen Fehler: Sie versuchen, ein Flexibilitätsproblem innerhalb eines starren Systems zu lösen. Figma Slots setzen an dieser Stelle an.

Was sind Figma Slots?

Slots sind flexible Bereiche, die in Hauptkomponenten platziert werden und es ermöglichen, Inhalte bei gleichzeitiger Einhaltung des Design Systems direkt in einer Instanz hinzuzufügen und anzuordnen, ohne sie zu detachen.

‍

Das Kernprinzip lässt sich einfach runterbrechen: Innerhalb einer Komponente definiert man einen Bereich (den Slot), der als Container für variable Inhalte dient. Andere Komponenten, Texte oder Elemente können dort eingefügt, entfernt oder umsortiert werden. Die Instanz bleibt dabei vollständig mit der Hauptkomponente verbunden. Alles, was fix sein soll, bleibt fix: Padding, Border, Schatten, Buttons. Nur der Slot-Bereich ist offen.

‍

Slots vs. Varianten - die entscheidende Abgrenzung. Varianten beschreiben den Zustand einer Komponente: offen oder geschlossen, aktiv oder inaktiv, expanded oder collapsed. Slots beschreiben, was in einer Komponente stecken kann. Die Unterscheidung klingt subtil, ist aber in der Praxis enorm.

‍

Wir stimmten einander im Test zu:

‍

 „Die Instanzen sagen einfach nur den Zustand von dieser einen Komponente. Aber wenn es darum geht, Flexibilität zu wollen in einer Komponente, wie z.B. in Modalen oder ganzen Sections… da werden Slots eigentlich sehr hilfreich."

‍

In Figma werden Slots visuell pink hervorgehoben. Das ist eine bewusste Designentscheidung, damit sie im Layer-Panel sofort ins Auge fallen und nicht übersehen werden.

Das Konzept hinter Slots ist Entwicklern längst vertraut. Wer aus einem Development-Hintergrund kommt, hat mit diesem Muster während der gesamten Karriere gearbeitet: Children props bei React, Vues Slot-System, Web Components' slot elements: Entwickler setzen Interfaces seit Jahren so zusammen. Das Konzept eines vordefinierten Bereichs, in den Inhalte eingefügt werden, ist fundamental für die Funktionsweise des Web.

‍

Figma nähert sich mit Slots also der Art, wie Entwickler tatsächlich arbeiten. 

‍

„Slot ist einfach der Name, den Figma gegeben hat. Aber eigentlich arbeiten die Developers tatsächlich nicht so, dass sie eine Komponente haben mit Sachen, die sie ein- und ausblenden. Das gibt's nur in Figma bei uns." 

‍

Die Empfehlung aus unserem Team: Frühzeitig mit den eigenen Developern validieren, ob das Slot-Konzept ihrer Arbeitsweise entspricht. Die Chancen stehen gut, dass es das tut.

Figma Slots erstellen: Schritt-für-Schritt-Anleitung

Slots funktionieren ausschließlich innerhalb von Komponenten. Jeder Frame innerhalb einer Hauptkomponente kann in einen Slot konvertiert werden. Freie Frames außerhalb von Komponenten kommen nicht infrage. Das ist die erste und wichtigste Voraussetzung.

‍

So wird ein Frame zum Slot:

‍

1. Komponente erstellen oder öffnen: Ohne bestehende Komponente kein Slot. Falls noch keine existiert, zuerst den gewünschten Aufbau als Komponente definieren.
   
   
2. Frame innerhalb der Komponente anlegen: Dieser Frame wird zum Slot-Container. Er definiert den Bereich, in dem später variable Inhalte eingefügt werden.
   
   
3. Frame zum Slot konvertieren: Dafür gibt es drei gleichwertige Wege:
   
   
   
   • Rechte Toolbar: „Convert to Slot" anklicken (das kleine Plus-Icon)
     
     
   • Rechtsklick auf den Frame: „Convert to Slot" im Kontextmenü wählen
     
     
   • Tastenkürzel: ⌘ Command ⇧ Shift S (Mac) oder ⌃ Control ⇧ Shift S (Windows)
     
     
4. Optional: Description hinterlegen: z.B. „Nur Textelemente" oder „Checkbox, Radio Button, Input Field". Klingt nach einer Kleinigkeit, ist in größeren Teams aber Gold wert.
   
   
5. Optional: Preferred Instances definieren: Komponenten, die als Standard-Auswahl vorgeschlagen werden sollen, wenn jemand den Slot befüllt.
   
   

‍

Auto Layout bleibt die stille Voraussetzung: Ohne korrekt konfiguriertes Auto Layout verhalten sich eingefügte Elemente nicht wie erwartet. Bevor Slots produktiv eingesetzt werden, muss das Auto-Layout-Setup der Komponente sauber stehen. Sonst verschiebt sich alles und die wilde Fehlersuche beginnt.

‍

Slot-Descriptions sind Teamkommunikation: In großen Design Systemen mit vielen Mitwirkenden ist die Description-Funktion keine Nebensache. Über das Bearbeiten der Slot-Eigenschaft im Eigenschaften-Panel lassen sich Name, Beschreibung und Preferred Instances anpassen. 

‍

Wir empfehlen: formatierter Text, Links, sogar Code-Snippets können hier hinterlegt werden. 

‍

„Wenn man ein riesiges Design System hat und mit sehr vielen Leuten arbeitet, möchte man Fragen verhindern. Deswegen kann man hier alle Regeln aufschreiben." 

‍

Je vollständiger die Description, desto weniger Rückfragen.

Drei Anwendungsfälle aus der Praxis

Die folgenden Beispiele stammen aus einem laufenden Projekt, an dem unser Designteam aktiv arbeitet. Jeder dieser Fälle war ein konkreter Schmerzpunkt, den das Team mit Figma Slots adressiert hat.

‍

Modale: Von 20 Varianten zu einer Basiskomponente

Die Ausgangslage: 20 Modal-Varianten im Design System. Alle mit dem gleichen Grundaufbau: Header, Buttons, Schatten, Border, Padding. Der einzige Unterschied lag im Innenbereich, im Content. Und trotzdem existierte jede einzelne als eigenständige Komponente.

‍

Die Lösung mit Figma Slots: Eine einzige Basis-Komponente, in der Header, Buttons, Schatten, Border und Padding als feste Elemente definiert sind. Der variable Innenbereich wird zum Slot. In jeder Instanz können unterschiedliche Inhalte eingefügt werden, ohne die Basis zu verändern.

‍

„Überall ist das Padding richtig, überall sind die Border richtig, die Schatten richtig und die Buttons sind an der richtigen Stelle. Nur der Content ist variabel." 

‍

Ein Satz, der das gesamte Versprechen von Slots zusammenfasst. 20 Varianten werden zu einer Komponente. Die Konsistenz steigt, der Wartungsaufwand fällt.

‍

Kapitel-Boxen: Flexible Aufgabenlisten ohne hard-coded Maximum

Im Projekt gibt es Kapitel-Boxen, die Aufgaben enthalten. Bisherbrauchten wir separate Komponenten für 3, 6 oder beliebig viele Aufgaben pro Kapitel. Jede neue Anforderung (z.B. eine siebte Aufgabe) bedeutete: zurück ins Design System, Komponente anpassen, neue Variante erstellen, überall prüfen, ob sich nichts verschoben hat.

‍

Mit Slots: Eine Box-Komponente mit festem Rahmen (Kapitelnummer, Überschrift, Beschreibung) und einem Slot für die Aufgaben. Beliebig viele Aufgaben-Instanzen einfügen. Keine hard-coded Maximalzahl. Keine separaten Komponenten pro Aufgabenanzahl. Die Box wächst mit dem Inhalt, nicht mit dem Designsystem.

‍

FAQ-Listen: Reihenfolge-Probleme endlich lösen

FAQ-Komponenten kamen in drei Geschmacksrichtungen: offen, geschlossen und als Liste. Das Anordnen und Umordnen von FAQ-Einträgen innerhalb einer Instanz war ein manueller Kraftakt.

‍

„Ich bin in die Instanz gegangen, habe dort eins hinzugefügt, bin zurückgegangen - und dann ist mir aufgefallen, Content hat die Reihenfolge der Texte geändert. Ich musste überall die Reihenfolge ändern. Ich habe so viel Zeit verloren mit eigentlich drei Klicken, indem man Sachen nach oben und nach unten schieben kann."

‍

Die Slot-Lösung: Eine Wrapper-Komponente plus ein Slot für die FAQ-Einträge. Hinzufügen, entfernen, umsortieren - alles innerhalb der Instanz, alles ohne Detachen.

‍

Wichtig zu wissen: Die freie Reihenfolge im Slot kann auch Inkonsistenzen produzieren. Klare Teamregeln bleiben notwendig.

Slots vs. Varianten: Wann was verwenden?

“Brauchen wir hier eine Variante oder einen Slot?” 

‍

Die Antwort liegt im Unterschied zwischen Zustand und Inhalt.

‍

Varianten beschreiben Zustände. Ein Akkordeon ist offen oder geschlossen. Ein Button ist aktiv oder inaktiv. Eine Checkbox ist gecheckt oder unchecked. Das sind semantische Unterschiede, die zur Komponente selbst gehören.

‍

Slots beschreiben variable Inhalte innerhalb einer konstanten Hülle. Ein Modal hat immer den gleichen Rahmen, aber der Inhalt wechselt. Eine FAQ-Liste hat immer das gleiche Layout, aber die Anzahl der Einträge variiert. Eine Content-Seite hat immer die gleiche Struktur, aber die Module darin sind frei kombinierbar.

‍

Im Atomic Design zeigt sich diese Unterscheidung besonders klar. Atome und Moleküle (Buttons, Input Fields, Checkboxen) bleiben eigenständige Komponenten mit Varianten. 

‍

„Die ganzen Moleküle und Atome existieren immer noch - aber wenn es in größere Bereiche geht, wie ganze Sections, da werden Slots sehr hilfreich, um mehr Flexibilität zu haben."

‍

Slots entfalten ihren Wert auf der Ebene von Organisms und Sections. Dort, wo Komponenten zusammengesetzt werden und der Inhalt wirklich variabel wird.

Beide Konzepte ergänzen sich. Die Frage ist nie „Slots oder Varianten", sondern „Wo Slots und wo Varianten?".

4 Regeln zum sinnvollen Einsatz von Slots im Team

Diese Regeln haben wir auf Basis unserer ersten Erfahrungen aus der Praxis entwickelt.

‍

Regel 1: Nicht alles ist ein Slot

Slots eignen sich dort, wo der Grundaufbau konstant ist und der Inhalt variiert. Ein Modal mit festem Rahmen und variablem Content? Slot. 

‍

Ein Button mit verschiedenen Zuständen? Variante. 

‍

Die Daumenregel: Wenn Sie den Bereich in der Hauptkomponente fixieren wollen (Padding, Border, Schatten), nutzen Sie einen Slot für den Rest. Wenn sich die gesamte Komponente in ihrem Zustand ändert, bleiben Sie bei Varianten.

‍

Regel 2: Nur Components in Slots 

In Slots gehören ausschließlich bestehende Komponenten: Input Fields, Checkboxen, Radio Buttons, Text-Components. Keine freien Rechtecke, keine ungruppierten Texte, keine losen Elemente. 

‍

Nur so bleibt das Design systemkonform. Wer freie Elemente in Slots zulässt, untergräbt genau die Konsistenz, die Slots schaffen sollen.

‍

Regel 3: Slots immer befüllen 

Ein leerer Slot wird übersehen. Wir empfehlen, Slots immer mit Beispielinhalten oder einer visuellen Kennzeichnung zu versehen. 

‍

„In der Präsentation über Slots hatten die hier irgendwie eine lustige Farbe drin und gesagt 'befüll mich' oder 'ich bin ein Slot, pack irgendwas rein'... damit man nicht übersieht, dass etwas ein Slot ist." 

‍

Ein pink markierter Platzhalter mit klarem Label ist deutlich hilfreicher als ein leerer Frame, den niemand als Slot erkennt.

‍

Regel 4: Descriptions vollständig schreiben

Jeder Slot braucht eine ausführliche Beschreibung. Was gehört rein? Was gehört nicht rein? Welche Komponenten sind vorgesehen? Wie viele Elemente sind sinnvoll? Die Description-Funktion in Figma unterstützt formatierten Text, Links und Code-Snippets. Das Team nutzt sie als zentrale Dokumentation direkt an der Stelle, wo sie gebraucht wird. 

Bekannte Einschränkungen und offene Fragen

Figma Slots befinden sich aktuell in der offenen Beta. Änderungen, Bugs oder Performance-Probleme sind in dieser Phase zu erwarten.

‍

Im Test unseres Teams lief das Feature stabil. Keine Abstürze, keine Datenverluste, keine gravierenden Darstellungsfehler. Aber das ist ein einzelnes Team mit einem einzelnen Projekt. Ein Produktionseinsatz über ein großes Design System hinweg birgt andere Risiken.

‍

Elemente innerhalb eines Slots können in der Instanz frei umsortiert werden. Das ist gewollt, aber gleichzeitig gefährlich. Ohne klare Teamregeln kann jeder Designer die Reihenfolge ändern, was zu inkonsistenten Ergebnissen führt. Besonders bei FAQ-Listen oder Aufgabenlisten, wo die Reihenfolge eine inhaltliche Bedeutung hat, braucht es dokumentierte Konventionen.

‍

Abgesehen davon waren wir uns einig: Slots nicht mitten in laufenden Projektübergaben einführen. Lieber zuerst laufende Projekte abschließen, dann eine gezielte Cleanup-Phase einplanen, in der das bestehende Design System auf Slot-Potenzial geprüft und umgebaut wird. Wer zu früh umstellt, riskiert Instabilität genau dort, wo Stabilität gebraucht wird.

‍

Eine weitere Empfehlung: Interne Nutzungsregeln dokumentieren, bevor Slots teamweit ausgerollt werden. Die Flexibilität, die Slots bieten, braucht einen Rahmen. Sonst wird aus kontrollierter Freiheit unkontrolliertes Chaos.

‍

Fazit: Ein Feature, das bleibt(?)

„Es ist irgendwie wie Auto Layout… das kam irgendwann und dann war es der Gamechanger. Ich glaube, hier wird das genauso. Oder auch Komponenten. Die kamen ja auch erst später."

‍

Israas Einschätzung trifft den Kern. Figma Slots lösen ein Problem, das jedes wachsende Design System hat: die Spannung zwischen Konsistenz und Flexibilität. Slots repräsentieren einen fundamentalen philosophischen Wandel im Design-Tooling: weg von „Abweichung um jeden Preis verhindern" hin zu „Kreativität innerhalb klarer Grenzen ermöglichen".

‍

Der konkrete nächste Schritt: ein Design System Audit.

‍

 Welche Komponenten werden am häufigsten detacht? Wo existieren fast identische Varianten nebeneinander? Wo bremst das Hide/Show-Muster die Dateigröße? Das sind die Stellen, an denen Slots heute schon den größten Unterschied machen. Figmas eigener Blog bestätigt: 

‍

„Start with components people detach the most" 

‍

Dort liefern Slots den größten unmittelbaren Nutzen. Early Adopters sahen die größten Erfolge dort, wo Teams bereits am Designsystem vorbeiarbeiteten: Dialoge, Menüs, Modale, Cards und Panels.

‍

Sie wollen Ihr Design System mit Figma Slots optimieren oder sind sich nicht sicher, wo der beste Einstiegspunkt liegt? Wir bei brightside Studio hilft gerne.

‍

Buchen Sie einfach eine kostenlose Beratung und wir finden gemeinsam heraus, welche Komponenten als Erstes von Slots profitieren.