Building Design Systems for Websites That Developers Actually Use

Most design systems are over-engineered.

They have 47 button variants, a color system with 15 shades per color, spacing tokens nobody understands, and documentation that reads like a technical spec.

Then developers ignore half of it and build what they need anyway.

Here's how to build a design system for websites that people will actually use—focused on what matters in production, not design theory.

Start With What You'll Actually Build

Don't design 50 components hoping you'll need them someday. Start with what your website actually requires.

For most marketing sites and company websites, you need:

• Buttons (2-3 variants max)
• Form inputs (text, textarea, select, checkbox, radio)
• Cards (1-2 layouts)
• Navigation (desktop + mobile)
• Footer
• Typography hierarchy (H1-H6, body, small)
• Basic content blocks (text + image layouts)

That's it. You can add more later, but this covers 90% of websites.

‍

One Font, Multiple Scales

I use Inter for everything. Not Inter for body and something else for headings. Just Inter.

Why? Because websites don't need typographic complexity. They need clarity and consistency.

My title scale:

• Title 1: 64px / 80px line height (hero headlines)
• Title 2: 40px / 56px (section headers)
• Title 3: 24px / 36px (subsection headers)
• Title 4: 20px / 28px (card titles)
• Title 5: 18px / 28px (small headers)
• Title 6: 14px / 18px (labels, overlines)

My text scale:

• Text 1: 18px / 28px (large body, introductions)
• Text 2: 14px / 20px (default body text)
• Text 3: 12px / 16px (small text, captions)
• Creative (display text): 100px / 120px for when you need something massive.

‍
That's it. No 12-level hierarchy. No "should this be H3 or H4?" confusion. Clear purpose for each size.

In Webflow: These map directly to text styles. Apply them with one click.
No manual font sizing.

‍

Color System: Brand + Opacity

I don't use 10 shades of blue. I use one brand color (#0048F5) with opacity variants.

My color structure:

• Brand 1
• Brand 2
• Dark (Text, headings)
• Light (backgrounds, borders)

Then opacity variants: 75%, 50%, 25%, 15%, 10%, 5%, 2%, 0%

Why this works:

Instead of maintaining separate color values for hover states and subtle backgrounds, I use the same color at different opacities.

Example:

• Button: Brand 1 at 100%
• Button hover: Brand 1 at 75%
• Subtle background: Brand 1 at 5%
• Border: Brand 1 at 15%

One color, infinite flexibility. Developers don't need to remember which shade to use—they pick the opacity that looks right.

In Webflow:

Set up your primary brand color via variables. All done in one place.

‍

Spacing: Every Value You'll Need

My spacing scale isn't just "8px increments." It's specific values I actually use:

Small increments (tight spacing):

• 0, 2, 4, 8, 12, 16px

Default spacing:

• 24, 32, 40, 48px

Large spacing (sections):

• 56, 64, 80, 100, 120, 240px

Most common values I use:

• 16px: default padding inside elements
• 24px: comfortable spacing between elements
• 48px: section spacing
• 80px: large section breaks
• 120px: major section dividers

I don't use every value on every project. But when I need 56px of spacing, I have it defined. No guessing.

In Webflow:

All is keeped via Variable system. I keep these values consistent. If I use 48px once, I use 48px everywhere for that spacing purpose - thank you Variable!

‍

Corners & Radius

Border radius values:

0, 1, 2, 4, 8, 16, 24, 32, 80, 500

Most used:

• 8px: buttons, inputs, cards
• 16px: larger cards, sections
• 500px: fully rounded (pills, circular elements)

Pick one or two for your project and stick to them. I usually use 8px for everything interactive and 16px for content containers.

Container Widths

This is critical for consistency. My container scale:

240, 320, 480, 640, 720, 960, 1200, 1320, 1440px

Most commonly used:

• 1440px: max site width
• 1200px: content width for most sections
• 720px: narrow content (blog posts, forms)

In Webflow:

Create container classes with these max-widths.
Every page uses the same container logic.

Components: Simple Variants

I have two button types: Primary and Secondary.

That's it. Not small/medium/large. Not 12 states. Just two clear button types with optional icons.

Every variant serves a purpose:

• Primary: main CTAs
• Secondary: less important actions
• Icon variants: when you need visual reinforcement

In Webflow:

Single Button Component with Variant Switcher

‍

From Figma Pixels to Webflow REM

Here's something critical: I design in pixels in Figma, but I build in rem units in Webflow.

Why? Because rem scales with user preferences and creates more accessible sites. Plus, it makes responsive typography way easier.

The conversion is simple:

• 16px = 1rem (browser default)
• 24px = 1.5rem
• 48px = 3rem
• 64px = 4rem

But here's where it gets better: fluid typography.

Instead of fixed sizes that jump at breakpoints, I use clamp() in Webflow for fluid scaling:

Typography example:

• Title 1 (64px desktop): clamp(2.5rem, 5vw, 4rem). Scales from 40px on mobile to 64px on desktop, smoothly.
• Title 2 (40px desktop): clamp(1.75rem, 3.5vw, 2.5rem). Scales from 28px to 40px.
• Body text: clamp(0.875rem, 1.5vw, 1rem. Scales from 14px to 16px.
• Etc. Everything adaptible to display.

This means my typography adapts to every screen size, not just defined breakpoints. Better readability, less manual tweaking.

In Webflow:

Use custom CSS for clamp() values or set up your class system with rem units from the start. The initial setup takes longer, but you'll never touch responsive font sizes again. All is handle inside Variables to let it be very smooth!

The benefit:

Your designs scale smoothly across all devices. No weird breakpoint jumps. No manual adjustments for tablet sizes. It just works.

‍

What Developers Actually Need

When I hand off designs to Webflow (or developers), they need:

1. Clear naming conventions

Don't call something "CTA-blue-large-rounded". Call it "Button Primary". The purpose matters more than the appearance.

2. Component states

Show hover, active, disabled, and focus states for interactive elements. If you don't design them, developers will guess—and it'll look inconsistent.

3. Spacing rules

How much space between elements? Define it. "Looks good" isn't helpful when building.

4. Responsive behavior

How do components adapt on mobile? Do they stack, scale, or hide? Show it.

5. Real content examples

Show components with actual content length variations. What happens when a button label is 3 words vs 10 words? What if a card has 2 lines of text vs 10?

The Section Library Approach

Instead of just components, I build full sections: Hero sections, Feature sections, Project grids, Testimonials, etc.

Why? Because websites are built from sections, not just buttons and inputs.

My Figma has:

Section / Hero (multiple variants), Section / Feature, Section / Projects, Section / Testimonials, and more. Each section is a complete, production-ready layout. Developers can see spacing, typography, component usage, and responsive behavior all in context.

This is way more useful than a page of isolated components.

What Actually Matters in Production

After using this system across dozens of projects:

1. Max two typeface is enough.  Don't overcomplicate it.
2. Opacity-based colors scale better. One brand color with opacity variants beats maintaining 10 separate shades.
3. Spacing should be memorizable. My most-used values: 16, 24, 48, 80. I don't need to look them up anymore.
4. Sections > Components. Showing full sections in context is more valuable than isolated component libraries.
5. Consistency beats completeness. Better to use 3 spacing values correctly than have 15 values used randomly.

In Webflow Specifically

This system maps perfectly to Webflow, with one key difference: everything becomes rem-based and fluid. All inside Variable and Component System.

• Typography → Text Styles (in rem with clamp() for fluidity)
• Colors → Color Swatches (with opacity)
• Spacing → rem values/clamp() for fluid spacing
• Main objects→ Class-based styling (padding in rem)
• Sections → Reusable symbols/components

The design system isn't separate from the build. It IS the build. But it's translated from fixed Figma pixels to fluid, scalable Webflow rem units.

This is why the system works so well in production: it adapts to any screen size without manual intervention.

‍

Common Mistakes to Avoid

• Don't create 100 components before building anything. Start with 10, build a page, see what you actually need.
• Don't make developers remember 47 spacing values. Pick 5-6 and stick to them.
• Don't design every possible state and variant. Design what you'll use in the next 3 months. Add more later if needed.
• Don't write documentation that nobody reads. Show examples instead.

The Bottom Line

Design systems for websites aren't about creating the perfect theoretical system. They're about giving developers clear, reusable patterns that make building faster and more consistent.

Keep it simple. Keep it practical. Keep it focused on what you're actually building.

The best design system is the one people actually use.