Bild: Mit KI generiert

Auto Layout ist in Figma seit Jahren verfügbar, und trotzdem ist der Unterschied zwischen Teams, die es nutzen, und Teams, die es wirklich verstehen, in der Praxis deutlich spürbar. Wer Auto Layout als Formatierungstool begreift — als bequemere Art, Abstände zu setzen — verschenkt den eigentlichen Wert. Wer es als systemisches Prinzip versteht, baut Komponenten, die sich vorhersehbar verhalten, mit dem Produkt wachsen und in der Übergabe an Entwicklung keine Interpretationsspielräume lassen.

In diesem Artikel erfährst du, was Auto Layout als Designsystem-Fundament leistet, warum die drei Sizing-Modi Fill, Fixed und Hug keine technischen Details sind, sondern Designentscheidungen über das Verhalten einer Komponente, und wie komponentenbasiertes Denken mit Auto Layout anfängt — nicht endet.

 

Was Auto Layout wirklich ist

Auto Layout macht aus einer statischen Gruppe von Elementen einen Container mit Verhaltensregeln. Ein Frame mit Auto Layout reagiert auf seinen Inhalt, auf seinen Kontext oder auf beides — abhängig davon, welche Regeln definiert wurden.

Das klingt technisch. Die Konsequenz ist aber eine gestalterische: Wer einen Button mit Auto Layout aufbaut, entscheidet nicht nur, wie er jetzt aussieht. Er entscheidet, wie er sich verhält, wenn sich der Text ändert, wenn er in eine enge Spalte gesetzt wird, wenn er in einer anderen Sprache mehr Zeichen braucht. Diese Entscheidungen sind Designentscheidungen und sie werden beim Aufbau der Komponente getroffen, nicht beim Layouten eines Screens.

Figmas eigene Dokumentation beschreibt Auto Layout als das Werkzeug, mit dem Frames auf ihre Inhalte reagieren. Das ist korrekt, aber unvollständig für den Designsystem-Kontext. Im Systemkontext ist Auto Layout das Werkzeug, mit dem Komponenten auf ihren Kontext reagieren: und genau das macht den Unterschied zwischen einer Komponente, die in jedem Kontext funktioniert, und einer, die für einen einzigen Anwendungsfall gebaut wurde.

 

Fill, Fixed und Hug: Drei Entscheidungen über Komponentenverhalten

Die drei Sizing-Modi sind das Herzstück jeder Auto-Layout-Entscheidung. Wer sie als technische Einstellungen behandelt, wird sie situativ wählen. Wer sie als Verhaltensregeln versteht, wird sie systematisch einsetzen.

 

Fixed bedeutet: Diese Dimension ist unveränderlich. Der Frame behält seine Größe, unabhängig davon, was sich innen oder außen ändert. Fixed ist die richtige Wahl, wenn eine Komponente eine definierte, unveränderliche Größe haben soll. Etwa ein Avatar oder ein Icon-Button mit festem Klickbereich. Fixed wird zum Problem, wenn es als Default eingesetzt wird, weil es der einfachste Modus ist. Eine fixed-breite Card in einem responsiven Layout ist keine Komponente, die skaliert; sie ist eine Komponente, die bei jeder Breitenanpassung manuell korrigiert werden muss.

 

Hug bedeutet: Dieser Frame passt sich seinem Inhalt an. Die Größe entsteht durch den Inhalt, nicht durch eine externe Definition. Hug ist die natürliche Einstellung für Komponenten wie Buttons, Tags oder Badges, deren Größe durch ihren Textinhalt bestimmt wird. Das macht sie flexibel bei Textänderungen und robust bei Lokalisierung, also bei Übersetzungen, die signifikant mehr oder weniger Zeichen benötigen als das Original.

 

Fill bedeutet: Dieser Frame füllt den verfügbaren Platz seines übergeordneten Containers. Fill setzt Auto Layout im Eltern-Element voraus und ist die Grundlage für responsive Verhaltensweisen. Ein Input-Feld, das die volle Breite seines Containers einnehmen soll, braucht Fill. Eine Karte in einem Grid, die sich proportional an die Spaltenbreite anpassen soll, braucht Fill. Ohne Fill sind responsive Layouts in Figma nicht sauber darstellbar.

 

Die systemische Frage hinter jedem dieser Modi lautet: Wer bestimmt die Größe dieser Komponente: der Inhalt, der Container oder eine fixe Definition? Diese Frage zu stellen, bevor eine Komponente gebaut wird, verhindert den häufigsten Auto-Layout-Fehler: Sizing-Modi zu wählen, die im Einzelfall funktionieren, aber im Systemkontext inkonsistentes Verhalten erzeugen.

 

Komponentenverhalten und Design Tokens: Zwei Seiten desselben Systems

Auto Layout und Design Tokens bilden zusammen das Fundament eines skalierbaren Designsystems. Tokens definieren die Werte: Farben, Abstände, Schriftgrößen. Auto Layout definiert das Verhalten: wie Komponenten auf diese Werte und auf ihren Kontext reagieren.

Ein konkretes Beispiel: Ein Spacing Token spacing/component/sm definiert den internen Abstand einer kompakten Komponente mit 8px. Wenn Auto Layout in der entsprechenden Komponente diesen Token als Gap und Padding verwendet, hat eine Spacing-Anpassung systemweite Wirkung — ohne dass einzelne Komponenten manuell aktualisiert werden müssen. Das ist der Effizienzgewinn, der in der Praxis zählt.

Umgekehrt gilt: Wenn Auto Layout-Abstände in einer Komponente als Fixed-Werte eingetragen sind statt als Token-Referenzen, ist das System an dieser Stelle nicht mehr durchgängig. Systemänderungen wirken dann nicht auf diese Komponente. Ein bekannter Konsistenzbruch in gewachsenen Designsystemen.

 

Komponentenarchitektur: Wann Auto Layout verschachtelt wird — und wann nicht

Nested Auto Layout, also Auto Layout innerhalb von Auto Layout, ist mächtig und gleichzeitig einer der häufigsten Gründe, warum Figma-Dateien schwer wartbar werden.

Eine Card-Komponente ist ein typisches Beispiel für sinnvolle Verschachtelung: Ein äußerer vertikaler Container hält Bild, Textbereich und Aktionsleiste. Der Textbereich ist seinerseits ein vertikaler Container mit Titel, Beschreibung und Metadaten. Die Aktionsleiste ist ein horizontaler Container mit zwei Buttons. Jede Ebene hat eine klare Verantwortlichkeit. Das ist lesbare Komponentenarchitektur.

Verschachtelung wird zum Problem, wenn sie entsteht, weil Auto Layout-Einstellungen nicht verstanden wurden, und nicht weil die Komponentenlogik es erfordert. Typisches Signal: Ein Container existiert nur, um einer Gruppe von Elementen einen bestimmten Abstand zu geben, den man eigentlich als Padding auf dem übergeordneten Element hätte definieren können. Unnötige Verschachtelungsebenen machen Komponenten schwerer lesbar, schwerer anzupassen und schwerer für Entwickler:innen zu interpretieren.

Die Faustregel: Jede Verschachtelungsebene sollte eine inhaltliche Begründung haben. Wenn eine Ebene nur strukturell existiert und nicht einem definierten Konzept entspricht — Inhaltsgruppe, Aktionsbereich, Metadaten — ist sie ein Kandidat zum Entfernen.

 

Auto Layout und die Entwicklungsübergabe

Auto Layout ist nicht nur ein Designtool, es ist auch ein Kommunikationstool. Ein sauber aufgebauter Auto-Layout-Frame kommuniziert an Entwickler:innen, wie ein Element im Code strukturiert sein soll — welche Elemente als Flex-Container oder CSS-Grid umgesetzt werden, welche Abstände aus dem Spacing-System kommen und welche Elemente feste vs. fluide Breiten haben.

Entwickler:innen, die Figma-Dateien mit konsequentem Auto Layout inspizieren, können daraus direkt ableiten, wie das Flexbox-Modell einer Komponente aussieht. Fill entspricht flex: 1, Hug entspricht width: fit-content, Fixed entspricht einer definierten Pixel- oder Rem-Angabe. Diese Entsprechungen sind kein Zufall; sie sind der Grund, warum Auto Layout als Designtool so konzipiert ist, wie es ist.

Das bedeutet auch: Eine Figma-Datei ohne konsistentes Auto Layout ist für Entwickler:innen schwerer zu interpretieren. Sie sehen Frames ohne Verhaltensregeln und müssen Layoutlogik rekonstruieren, die im Design nie explizit entschieden wurde. Der Mehraufwand entsteht dann nicht in Figma, sondern im Code.

 

Take Away Message

Auto Layout in Figma ist dann ein Designsystem-Fundament, wenn es nicht komponentenweise, sondern systemisch gedacht wird. Fill, Fixed und Hug sind Verhaltensregeln, nicht Formatierungsoptionen. Verschachtelung ist dann sinnvoll, wenn sie inhaltlicher Komponentenlogik folgt, nicht wenn sie technische Umwege kompensiert. Und ein Auto Layout, das konsequent mit Design Tokens kombiniert wird, erzeugt ein System, in dem Anpassungen systemweit wirken statt manuell ausgerollt werden müssen. Der Unterschied zwischen einer Figma-Datei und einem Designsystem liegt oft nicht in der Anzahl der Komponenten, sondern darin, wie durchdacht ihre Verhaltensregeln sind.