Lumos ist ein modernes Entwicklungs-Framework für Webflow, entwickelt von Timothy Ricks. Es organisiert eine Webflow-Site component-first: statt jede Section von Grund auf zu bauen, baut man wiederverwendbare Komponenten, die der Kunde nach der Übergabe selbst neu zusammensetzen kann.
Bei designtakt bauen wir seit Ende 2025 mit Lumos. Vorher haben wir Client First von Finsweet verwendet. Client First hat uns gute Dienste geleistet, hat sich aber für unseren Geschmack zu wenig schnell an die neusten Best Practices im Web und Komponenten-Möglichkeiten in Webflow angepasst.
Was ist das Lumos Framework?
Lumos ist ein strukturiertes System für den Aufbau von Webflow-Projekten. Im Kern definiert es vier Dinge, die zusammen wirken: eine konsistente Klassen-Konvention, ein Komponenten-System mit wiederverwendbaren Blöcken wie Hero, Card oder Section, ein durchgängiges Layout-System auf Basis aktueller Grid- und Flex-Patterns, und Fluid Responsiveness.
Entwickelt wurde Lumos von Timothy Ricks, einem der bekanntesten Webflow-Experten weltweit.
Für Webflow-Projekte heisst das im Alltag: einmal sauber aufgesetzt, kann eine Marketing-Person später eine neue Landingpage zusammenklicken, ohne jemals einen Designer oder Developer anzufragen. Das ist absolut zentral und in den meisten Fällen die wirtschaftliche Rechtfertigung für die Entscheidung, mit Webflow zu arbeiten.
Die vier Säulen von Lumos
Klassen-Naming
Die Benennung von Klassen ist ein wesentlicher Bestandteil jedes Webflow-Entwicklungsframeworks.
Lumos definiert die drei Typen "Custom Classes", "Utility Classes" und "Combo Classes". Das macht es einfach, bspw. Utility-Classes wie `margin-bottom-4` auf deine Custom Class `hero_wrap` zu stacken.
Wer eine Klasse im Webflow Designer sieht, weiss sofort, wo sie hingehört und was sie tut. Das senkt die kognitive Last beim Bearbeiten.
Plus einmal sinnvoll aufgesetzt, hast du über dein ganzes Projekt weg Konsistenz und bist deutlich schneller im Bauen neuer Sections.
Komponenten-System
Das ist der eigentliche Kern. Lumos behandelt jede Section, jedes UI-Element und jedes Pattern als wiederverwendbare Komponente. Webflows native Component-Funktion wird voll ausgeschöpft, inklusive Properties, Variants und Slots. Eine Änderung an einer Komponente wird projektweit übernommen, ohne dass man fünfzehn Sections einzeln anfassen muss.
Das beginnt bei simplen Containern bis hin zu komplexeren Komponenten wie bspw. Accordion List.
Layout-System
Lumos setzt konsequent auf CSS Grid und Flexbox, mit klaren Container- und Wrapper-Regeln.
Das Spacing wird über ein durchgängiges Skalensystem, das auf Tokens basiert, gesetzt. So hast du über das ganze Projekt ein konsistentes und gleichbleibendes Spacing. Das Ergebnis ist ein Layout, das vorhersehbar bleibt und sich auch in einem Jahr noch sauber erweitern lässt.
Diese Variablen passen sich auch immer der Container-Grösse an, was uns zum nächsten Punkt bringt.
Fluid Responsiveness
Aus Developer-Sicht der wahrscheinlich wichtigste Punkt. Anstatt in den verschiedenen Device-Breakpoints haufenweise Padding oder Display-Options zurecht zu klicken, wird das über Variablen wie var(--flex-medium, grid) und var(--_spacing---space--4) ganz einfach gehandelt.
Um das zu verstehen, muss man erst Container Queries verstehen. Anders als die älteren Media Queries messen sie nicht die Breite des ganzen Viewports (also bspw. der Bildschirm deines iPhones), sondern die Breite des Parent Containers. Das ist ein entscheidender Unterschied, da es den Fokus auf die Modularität und den individuellen Content, statt nur des Endgerätes setzt.
Zurück zu den beiden Variablen. var(--flex-medium, grid) heisst also, dass der Standard display:grid ist, bei einer Container-Breite von < 65em aber zu einer Flexbox gewechselt wird. medium kann dabei den Wert 0 oder 1 annehmen, basierend auf der Grösse des Containers.
var(--_spacing---space--4) ist eine Variable mit einem Clamp-Value. Das bedeutet, dass sie sich innerhalb zwei definierter Werte jeweils basierend auf ihrem verfügbaren Space vergrössert und verkleinert. Das heisst, dass wir auf Desktop und Mobile dasselbe Spacing benutzen können, das aber wunderbar auf allen Geräten skaliert!
Unter dem Strich bedeutet das also, dass man das komplette Styling auf Desktop machen kann, ohne jemals Webflows Breakpoints zu benutzen. Das macht es viel einfacher zu erkennen, wo welche Styles gesetzt sind, und bedeutet insgesamt auch deutlich kleinere CSS-Files.
Das erfordert zu Beginn etwas Umdenken und braucht sicherlich einige Builds, bis man sich daran gewöhnt hat. Anschliessend kann man aber nicht mehr zurück.
Lumos im Vergleich mit Client First: was ist der Unterschied?
Client First war jahrelang der inoffizielle Standard in der Webflow-Community.
Und auf den ersten Blick wirkt es ähnlich wie Lumos: Es existieren Utility Classes wie bspw. `background-color-primary` und Custom classes wie bspw `team-slider_card`. Der entscheidende Unterschied ist aber, dass Client First Builds typischerweise viel verschachtelter sind und es keine standardisierten Components gibt. Auch fehlt die Variablen-Tiefe und Fluid Responsiveness von Lumos.
Und genau hier zeigt sich der Generationenunterschied: Client First entstand vor dem grossen Component-Update von Webflow und wurde nie dafür konzipiert. Lumos nutzt Components, Variables und Variants als Fundament.
Aus Kundensicht hat das eine spürbare Konsequenz. Bei Client First muss ein Redakteur lernen, welche Utility-Klassen er für welche Wirkung kombiniert. Bei Lumos zieht er eine Komponente in die Seite und ist fertig.
Was man hier ausserdem erwähnen kann: Lumos mag auf den ersten Blick deutlich komplizierter und schwieriger zu lernen sein. Das ist es auch, aufgrund der Tiefe, die es bietet. Hat man das System erstmal verstanden, kann man neue Sections und Landing Pages deutlich schneller erstellen und hat sogar noch mehr Konsistenz, da man viele Elemente wiederverwenden kann.
Warum designtakt mit Lumos baut
Wir haben lange mit Client First gearbeitet. Es war ein guter Standard und hat uns sauber durch viele Projekte getragen. Aber zwei Dinge haben sich verändert, und beide zeigten sich gleichzeitig.
Das erste ist Webflow selbst. Native Components, Variables, Variants: Das alles sind Features, die es zum Zeitpunkt des Releases von Client First 2.0 noch nicht gab. Wer heute mit Webflow baut und diese Features nicht voll nutzt, lässt Effizienz auf dem Tisch liegen. Lumos wurde von Anfang an dafür gebaut, sie auszuschöpfen.
Das zweite sind die Kunden. Die häufigste Frage nach dem Launch ist inzwischen nicht mehr "Könnt ihr das noch ändern?", sondern "Können wir auch selbst eine neue Seite anlegen?". Mit einem component-first Setup lautet die Antwort konsequent Ja. Mit utility-basierten Frameworks wird die Antwort schnell zu einem "Theoretisch ja, aber meldet euch doch besser kurz bei uns".
Dazu kommt der Übergabe-Vorteil. Ein Lumos-Projekt ist nach drei Monaten genauso lesbar wie am Tag des Launches, weil die Klassen nicht wuchern und die Komponenten-Logik im Designer sichtbar bleibt. Für unsere Projekte ist das der entscheidende Punkt: Webflow-Sites, die der Kunde nach dem Setup ohne Händchenhalten weiterführen kann, und eine Codebase, die auch in einem Jahr noch Sinn ergibt.
Für wen ist Lumos Framework geeignet?
Lumos entfaltet seinen Nutzen vor allem dort, wo eine Website über die Jahre lebt und wächst. Webflow-Agenturen, die Projekte sauber übergeben wollen, ohne dass der Kunde später ständig zurückkommt, gewinnen damit ein Setup, das auch ohne sie funktioniert. In-House-Teams, die Marketing- und Designer-Rollen mischen, finden in den klar definierten Komponenten eine gemeinsame Sprache. Und KMU-Websites, bei denen über die Jahre neue Produkt-, Service- oder Landingpages dazukommen, profitieren von einer Struktur, die das Wachstum mitträgt.
Weniger Sinn ergibt der Aufwand bei einmaligen Microsites ohne Pflegebedarf, bei reinen Prototypen, die nach dem Pitch entsorgt werden, oder bei Projekten ohne CMS-Anforderungen, wo der Komponenten-Vorteil schlicht nicht zum Tragen kommt.
Aber auch da lässt sich argumentieren, ob ein Build mit Lumos unter Umständen nicht trotzdem effizienter ist. Die Vorteile würden da einfach deutlich weniger zum Tragen kommen.
Häufige Fragen zu Lumos Framework
Was ist das Lumos Framework?
Lumos ist ein component-first Entwicklungs-Framework für Webflow, entwickelt von Timothy Ricks. Es legt eine konsistente Klassen-Konvention, ein System aus wiederverwendbaren Komponenten und ein durchgängiges Layout-Regelwerk fest, mit dem Webflow-Sites strukturiert und wartbar gebaut werden. Im Kern funktioniert es wie ein modularer Baukasten: Statt jede Seite neu aufzusetzen, setzt du sie aus standardisierten Bausteinen zusammen, die projektweit identisch funktionieren. Dabei nutzt Lumos aktuelle Webflow-Features wie native Components, Variants und Variables von Grund auf und ergänzt sie um eine Fluid Responsiveness, die ganz ohne manuelles Breakpoint-Klicken auskommt.
Was ist der Unterschied zwischen Lumos und Client First?
Auf den ersten Blick wirken beide ähnlich, denn beide arbeiten mit einer Mischung aus Utility- und Custom-Klassen. Der Unterschied liegt tiefer: Client First entstand vor Webflows grossem Component-Update und kennt keine standardisierten Komponenten, weshalb die Builds typischerweise stärker verschachtelt sind. Lumos baut von Anfang an auf ein modulares Baukastensystem aus nativen Components, Variants und Variables und bringt eine Variablen-Tiefe und Fluid Responsiveness mit, die Client First fehlt. Für Projekte, die du nach dem Setup selbst weiterführen willst, ist Lumos deshalb in der Regel die bessere Wahl.
Muss ich als Kunde Lumos kennen, um meine Website zu bearbeiten?
Nein. Du arbeitest im Webflow Designer mit fertigen Komponenten wie Hero, Card, Section oder CTA und setzt daraus neue Seiten zusammen, ähnlich wie mit einem Baukasten. Das Framework und seine Klassen-Konvention musst du dafür nicht kennen. Bei designtakt erhältst du nach dem Launch eine kurze Einführung, danach legst du eigenständig neue Seiten an und passt bestehende an.
Setzt designtakt Lumos auf allen Webflow-Projekten ein?
In der Regel ja. Ausnahmen machen wir nur dort, wo ein bestehendes Setup weitergeführt werden soll. Wenn du mit einer Client-First-Site zu uns kommst, kann eine Migration zu Lumos zwar Sinn machen, muss aber nicht zwingend sein. Wir zeigen dir gerne auf, ob sich der Aufwand für dein Projekt lohnt.
Fazit
Lumos ist für uns die Antwort auf die Frage: Wie baue ich eine Webflow-Webseite, die der Kunde nach dem Launch ohne Reibung weiterführt? Die Bausteine dafür sind ein component-first Aufbau, ein sauberes Klassen-Naming und der konsequente Einsatz der aktuellen Webflow-Features. Zusammen ergeben sie einen modularen Baukasten: einmal aufgesetzt, lassen sich daraus immer wieder neue Seiten zusammensetzen. So entsteht eine Webseite, die mit dem Unternehmen mitwächst.
Zu Beginn kostet der Umstieg etwas Einarbeitung. Doch sobald das System sitzt, bauen wir neue Sections schneller, übergeben sauberer und bekommen nach dem Launch deutlich weniger Support-Anfragen, gerade weil sich die Komponenten modular wiederverwenden lassen.
Für uns also definitiv der neue Standard, Webflow-Webseiten zu bauen!
