How to Build a Scalable Design System in Webflow with Lumos

Who is this article for?

Webflow developers, agency owners, and design leads who want to go beyond page-by-page styling and build a structured, scalable design system inside Webflow. You should already be comfortable with CSS variables and utility-based frameworks. If you've read our Lumos guide or migration guide, this is the next step.

Most Webflow projects start the same way: a few pages, a handful of styles, everything looking consistent. But by the time you hit 15+ pages, three color themes, and a growing CMS, the cracks appear. Classes multiply, spacing becomes inconsistent, and every new section feels like it's fighting the ones before it.

A design system solves this by turning your design decisions into reusable, centralized tokens. And in Webflow, Lumos is the framework best equipped to make this work — because it was built from the ground up around CSS variables, variable modes, and utility-based architecture. The result is a system where changing one value updates your entire site.

At Klyra, every project we build starts with a design system in Lumos. Here's exactly how we set one up.

What Is a Design System Inside Webflow — and Why Does It Matter?

A design system is not a style guide. It's not a Figma file with color swatches and font specimens. Inside Webflow, a design system is a living, functional layer of CSS variables, utility classes, and components that enforce consistency across every page, section, and CMS template on your site.

Without a design system, every developer on the team makes micro-decisions: which shade of gray for borders, how much padding between sections, what font size for captions. Multiply that across 20 pages and two locales, and you get visual drift — things that look almost right but never quite match.

Lumos changes this by centralizing every design decision into variables and variable modes. Typography, colors, spacing, and layout all flow from a single source of truth. When a client asks to increase body text size or switch to a dark theme, you change one variable — not 47 elements.

This is where the distinction between Lumos and other Webflow frameworks becomes critical. Client-First gives you naming conventions. Lumos gives you an architecture — one designed specifically to support design systems at scale.

Typography Tokens: Building a Fluid Type Scale

Typography is the foundation of any design system. In Lumos, it's handled through a set of utility classes and CSS variables that create a responsive, scalable type system with zero breakpoint overrides.

The framework provides native font style utilities: u-display, u-h1 through u-h6, u-text, u-text-large, and u-text-small. Each one maps to a set of variables controlling font size, line height, letter spacing, and weight. You apply them by stacking on a component class:

<h1 class="hero_title u-display">Build Faster</h1>
<h2 class="about_heading u-h2">Our Approach</h2>
<p class="card_text u-text">Body paragraph here</p>
<span class="footer_note u-text-small">© 2026</span>

What makes this a design system — not just a set of classes — is how these utilities connect to variables. Each text style references a size variable from a central Size collection. Those variables use clamp() to create fluid sizing that scales smoothly between minimum and maximum values based on viewport width:

/* Font size scales fluidly — no breakpoint overrides needed */
font-size: clamp(2rem, 1.5rem + 2.5vw, 4rem);

/* Line height tightens proportionally */
line-height: clamp(1.1, 1.05 + 0.2vw, 1.2);

The Lumos Fluid Builder tool helps calculate these values. You input your min and max sizes, and it generates the clamp expression. The key advantage: unlike pixel-based breakpoints, this system responds to browser zoom. When a user increases their preferred font size, the entire type scale adapts — exactly what accessibility standards require.

To customize the scale for a project, you edit the Size variable collection. Every text style across your site updates instantly. That's the power of token-based design systems: one change, global impact.

Color Architecture: Primitives, Semantics, and Themes

Color is where most Webflow projects lose consistency. Developers create color variables ad hoc — blue-500, gray-light, brand-accent — without a clear system connecting them. Lumos solves this with a layered color architecture and variable modes that make theming automatic.

The design system uses three layers of color tokens:

1. Primitive tokens. Your raw palette: --blue-500, --gray-100, --white. These are pure values with no semantic meaning.

2. Semantic tokens. Purpose-driven references: --_theme---text, --_theme---background, --_theme---border. These point to primitives and define what each color does, not what it looks like.

3. Component tokens (optional). Specific overrides: --_theme---button-primary--background, --_theme---button-primary--text. These give fine-grained control at the component level.

The magic happens with Webflow's variable modes. You create a Theme collection with modes like Light, Dark, and Brand. In Light mode, --_theme---background points to white. In Dark mode, it points to near-black. In Brand mode, it points to your primary brand color. Then you apply the mode with a single utility class:

<!-- Light section — all children inherit light colors -->
<section class="hero_wrap u-section u-theme-light">
  <!-- Text, backgrounds, borders all resolve to light values -->
</section>

<!-- Dark section — one class, entire palette flips -->
<section class="features_wrap u-section u-theme-dark">
  <!-- Same components, completely different look -->
</section>

Because CSS variables follow inheritance, every child element inside that section automatically adopts the new theme. No overrides, no duplicate classes, no manual recoloring. This is what makes token-based design systems so powerful: the cascade does the work for you.

For interactive states, Lumos uses color-mix() combined with trigger variables to interpolate between default and hover colors without creating additional variables. The design system stays lean even as interactions grow complex.

Spacing Tokens: A Consistent Spatial System

Inconsistent spacing is the silent killer of design systems. In Client-First, spacing is handled through utility classes like padding-vertical and margin-bottom with predefined sizes. It works, but it's static — every breakpoint needs manual adjustment.

Lumos takes a different approach. Spacing is driven by a central Space variable collection with numbered tokens: --space--1, --space--2, --space--3, and so on. These tokens are rem-based and scale automatically through variable modes tied to responsive breakpoints.

/* Space tokens scale proportionally across breakpoints */
/* Desktop: --space--4 = 2rem   */
/* Tablet:  --space--4 = 1.5rem */
/* Mobile:  --space--4 = 1rem   */

/* Applied through variables, not utility overrides */
.card_content {
  padding: var(--space--4);
  gap: var(--space--2);
}

The Lumos u-margin-trim utility removes top margin from the first child and bottom margin from the last child inside a container — solving the common problem of unwanted space at the edges of a section. u-margin-trim-off re-enables it when needed.

The design system benefit: your entire site uses the same spatial scale. Sections, cards, grids, and CMS templates all reference the same tokens. When a client says "everything feels too tight on mobile," you adjust one variable mode — not 200 elements.

Component Architecture: The Stacking Pattern

A design system is only as good as its component architecture. In Lumos, every element follows a strict pattern: component class first, utility class stacked on top.

<!-- Component class = unique identity -->
<!-- Utility class = shared behavior -->
<div class="pricing_card u-card">
  <h3 class="pricing_title u-h4">Pro Plan</h3>
  <p class="pricing_price u-display">$99/mo</p>
  <p class="pricing_desc u-text">Everything you need</p>
  <a class="pricing_cta u-button-primary">Get Started</a>
</div>

The component class (pricing_card) gives the element its unique identity — specific positioning, custom margins, grid placement. The utility class (u-card) provides shared, reusable styling — padding, border radius, background from your design system tokens.

This separation is the core principle of a scalable design system. When you want to update the look of all cards site-wide, you edit the u-card utility. When you want to adjust just the pricing card, you edit the pricing_card component class. No conflicts, no cascading surprises.

The naming convention reinforces the architecture. Component classes use underscores to separate hierarchy levels: pricing_card, pricing_card_header, pricing_card_header_icon. Maximum depth: three underscores. If you need deeper nesting, it's a signal to break the component into smaller sub-components.

For sections, the structure always follows the same pattern:

<section class="pricing_wrap u-section u-theme-dark">
  <div class="pricing_contain u-container">
    <div class="pricing_layout">
      <!-- Components go here -->
    </div>
  </div>
</section>

_wrap handles the full-width section with vertical padding and theme. _contain sets the max-width and enables container queries. _layout controls the grid or flex arrangement. Never put layout properties on _contain — it needs container-type: inline-size to support container queries, and grid properties would break that.

Responsive Design Without Breakpoints

Traditional Webflow development means styling desktop first, then overriding at tablet, mobile landscape, and mobile portrait. Four breakpoints, four passes through the designer. This approach doesn't scale — and it doesn't belong in a design system.

Lumos eliminates breakpoints entirely through three techniques that work together.

1. Fluid sizing with clamp(). Typography and spacing scale smoothly between min and max values. No jumps, no jarring reflows.

2. Responsive variables. Variables like --flex-medium, --column-medium, and --none-small flip between values based on screen size. You use them as CSS fallbacks:

/* Grid on desktop, flex column on tablet and below */
display: var(--flex-medium, grid);
flex-direction: var(--column-medium, row);
grid-template-columns: repeat(3, 1fr);

3. Container queries. For cases where variables aren't enough, @container queries let components respond to their actual available space rather than the viewport. This makes components truly modular — a card grid that works in a full-width section also works in a sidebar, without any changes.

For your design system, this means responsive behavior is built into the tokens and components. You don't configure responsiveness per page — it's inherited from the system itself.

Maintaining and Scaling Your Design System

Building a design system is the easy part. Keeping it consistent across projects, team members, and months of iteration is where most systems fail.

Here's how we maintain design systems at Klyra.

Document your tokens. Every variable collection should have a clear purpose. Size tokens control typography. Space tokens control spacing. Theme tokens control colors. If a variable doesn't fit into a collection, it probably shouldn't exist.

Use the Lumos Chrome Extension. The extension (rated 4.9/5) automates repetitive tasks: quick class naming, automatic px-to-rem conversion, and color-mix() wrapping for variable-based transparency. It keeps your team working within the design system instead of working around it.

Audit regularly. Check for custom classes that duplicate utility behavior. Look for hardcoded values that should be variables. Watch for component depth exceeding three underscores — it means something needs refactoring.

Start from the starter project. The Lumos V2 starter (MIT license) includes all core utilities, variable collections, and component patterns pre-configured. Clone it, customize your tokens, and you have a design system ready for production.

The design system philosophy behind Lumos — centralized tokens, utility stacking, breakpoint-free responsive — aligns with where Webflow is heading as a platform. Variables, variable modes, components, container queries: these are all features Webflow has invested heavily in, and Lumos is the framework that uses them most fully.

If you're building Webflow projects that need to scale — across pages, themes, locales, or team members — a design system isn't optional. It's the foundation. And Lumos gives you the best architecture to build it on.

Need help setting up a design system for your next Webflow project? At Klyra, we specialize in scalable Lumos builds. Let's talk.

Additional Sources

• Lumos Framework Official Documentation
• Lumos V2 GitHub Repository
• Lumos V2.1 Crash Course (Timothy Ricks)
• Typography Styles in Webflow with Lumos (FlowSuggest)
• How to Best Utilize Webflow Variables (Caleb Raney)
• Variable Modes and Collections in Webflow (Caleb Raney)
• Responsive Design with Lumos (State of Flow)
• Modular Component Libraries (Timothy Ricks)
• Lumos Chrome Extension