On this page
The three layers
A Webflow design system has three layers, and confusing them is what makes libraries decay.
Variables — colours, sizes, fonts as named values. Change color-primary once, every use updates.
Classes — the styling layer. Reusable rules applied to elements.
Components — reusable structure. One definition, many instances; edit the definition and every instance updates.
Most teams reach for components first because they're the most visible feature. The order that works is the reverse: variables, then a class system, then components. Components built on ad-hoc styling encode the mess rather than fixing it.
Variables, done properly
The mistake is naming variables after what they look like. purple, blue-light, grey-3 are true until a rebrand, then every name is a lie.
Two levels of naming solve it:
Primitives — the raw palette. purple-500, grey-100, space-4.
Semantic — the role, pointing at a primitive. color-text-primary → grey-900. color-action → purple-500. space-section → space-16.
Then build with semantic names only. When the brand colour changes, you repoint one semantic variable. When you need a dark mode, you repoint a set of them.
The same principle applies to spacing. A scale — 4, 8, 12, 16, 24, 32, 48, 64 — used consistently produces visual rhythm without anyone thinking about it. Arbitrary values chosen per element is what makes a site feel subtly untidy in a way nobody can point at.
Components: what they're for
A component is right when the same structure appears repeatedly and should change everywhere at once. Navbar, footer, CTA block, post card, pricing tier.
A component is wrong when instances need to differ structurally. If half your "cards" need an extra row, you have two components, or one component with a property.
Component properties are the mechanism that makes libraries genuinely reusable — text, images, links and visibility exposed as editable per instance, without detaching. Without them, any variation means detaching, and a detached component is a copy that no longer receives updates. A library where half the instances are detached is not a library.
So: expose as properties anything that legitimately varies per instance. Keep structure in the definition.
Where it stops
Being clear about the ceiling saves teams from designing around capabilities that don't exist.
No cross-project inheritance in the way engineers expect. Webflow's Libraries let you share components between projects, and updates don't propagate like an npm package version bump. Plan for periodic manual syncing, not automatic distribution.
No conditional logic inside components. No "if this property is empty, render differently" beyond visibility toggles. Complex variants become separate components.
No composition depth. Nesting components inside components works, and it gets awkward quickly. Two levels is comfortable; four is not.
Detaching is one-way. No reattach. Detaching to make one change severs the instance permanently — the most common way libraries erode.
CMS binding inside components is constrained. A component containing CMS-bound fields depends on the Collection context it's placed in, which limits how portable it is.
Structuring a library that survives
Start from the site you have. Audit what actually repeats. Teams that design a library in the abstract build components nobody needs and miss the ones everyone rebuilds by hand.
Componentise the boring things first. Navbar, footer, CTA, card, section header. Highest reuse, lowest complexity, immediate payoff.
Name for role, not appearance. cta_newsletter, not purple-box.
Document inside Webflow. A hidden page with every component, each with a short note: what it's for, which properties exist, when not to use it. External documentation goes stale; a page inside the project is where people will actually look.
Cap the variants. Three button variants is a system. Nine is a symptom — either the design lacks discipline, or the component is doing too many jobs.
The maintenance question
Libraries decay in a predictable way: someone needs a variation under deadline, detaches an instance, and moves on. Repeat twenty times over a year and the library describes what the site used to look like.
What actually prevents it:
Make the right thing easy. If adding a property takes two minutes and detaching takes ten seconds, people detach. Expose the properties people keep needing.
Audit detached instances quarterly. Find them, ask why, and either add the missing property or accept the divergence deliberately.
One owner. Not a committee. Someone whose job includes the library being coherent.
Decide when to break it. Sometimes the honest answer is that the component is wrong and needs rebuilding. Doing that on purpose, once, beats twenty detached instances drifting apart.
What this is worth
The payoff isn't consistency for its own sake. It's the third page taking a fraction of the time the first did, a brand colour change being one edit, and a new designer producing something on-brand without asking.
The cost is the discipline. A library set up in a fortnight and abandoned is worse than none, because people trust it and it's lying.
If you're going to build one, staff the maintenance. If you can't, a documented class system and a handful of copy-paste sections will serve you better than a component library nobody tends.
