Design Systems in Webflow: How We Build for Scale

Building a design system is one of those projects that feels complete when it's done. The components are in Figma. The variables are mapped. The style guide page is live in Webflow. The team has been walked through it. Everyone agrees it looks great.

Six months later, the site has drifted. There's a button somewhere that doesn't match the button component. A new page section uses hardcoded colours instead of tokens. Two different typeface sizes are being used for what should be the same heading level. No one is quite sure when it happened, but the design system is no longer describing the site — it's describing an idealised version of the site that existed briefly at launch.

This is design drift, and it's the default outcome if governance isn't built into the system from the start. This article is about how to prevent it — and how to recover if you're already experiencing it.

What Causes Design Drift

Design drift doesn't happen because people are careless. It happens because systems without clear governance create ambiguity, and teams resolve ambiguity by doing whatever is quickest.

The most common causes we see:

• No single owner. When responsibility for the design system is distributed across the team, no one takes accountability for its health. Everyone assumes someone else is watching it.
• Components that are hard to use correctly. If using a component requires more steps than creating a custom element from scratch, editors will create custom elements.
• No onboarding for new team members. A system that isn't explained is a system that gets ignored. New editors recreate patterns that already exist because they don't know the existing patterns are there.
• No deprecation process. Old components that should have been retired stay live. New components get added alongside them. Over time, the system has three versions of what should be one thing.
• No audit cadence. Issues accumulate invisibly because no one is regularly checking whether the live site matches the system.

Each of these is solvable. None of them require significant ongoing effort once the right structures are in place.

The Design System Owner

The single most effective governance measure is designating a design system owner — one person who is accountable for the health of the system. This isn't necessarily a full-time role, but it needs to be an explicit, named responsibility.

The design system owner's responsibilities typically include:

• Reviewing and approving new component requests
• Running the quarterly audit (more on this below)
• Managing the deprecation process for old components
• Maintaining the changelog and versioning documentation
• Onboarding new editors and developers to the system
• Being the escalation point when teams aren't sure which component to use

In smaller organisations, this is often a senior designer or a design-aware front-end developer. In larger teams, it may be a dedicated design technologist or a design ops function. What matters is that the role exists and the person in it has the authority to enforce decisions.

Without an owner, governance discussions happen in Slack threads that don't reach conclusions, and the system degrades by default. With an owner, there's a clear point of accountability and a person whose job it is to care.

Component Naming and Versioning Conventions

Naming is the foundation of a maintainable component library. In Webflow, component names are visible to editors and developers; ambiguous names create ambiguity in the product.

The conventions we use and recommend:

Naming

• Use a consistent prefix for system components: ds/ or a client-specific prefix like cw/. This separates design system components from one-off page elements at a glance.
• Name components by what they are, not what they look like: ds/card-feature not ds/card-blue-with-icon. Names tied to visual properties break when the design evolves.
• Use a category–component–variant structure: ds/nav-primary-desktop, ds/nav-primary-mobile. Categories group related components and make the library easier to browse.
• Use consistent terminology across Figma and Webflow. If the Figma component is called "Feature Card", the Webflow component should also be called "Feature Card" — not "Card Feature" or "Card w/ Feature".

Versioning

Webflow doesn't have built-in component versioning, so you manage this through naming conventions and documentation. Our approach:

• When a component is being superseded but can't be immediately retired, rename the old version with a -legacy suffix: ds/hero-split-legacy. This flags it as deprecated without breaking existing instances.
• Maintain a changelog document (shared in Notion, Confluence, or wherever your team documents things) that records when components are added, modified, or deprecated, and why.
• When a significant structural change is made to a component — not a style update, but a structural change that affects how it's used — treat it as a new component and deprecate the old one rather than modifying in place. Modifying a component in place can break existing uses in ways that aren't immediately visible.

How to Deprecate Components Without Breaking Pages

Component deprecation is one of the areas teams handle worst. The common approaches — deleting the component, or just leaving it in the library indefinitely — both create problems. Deletion breaks pages. Indefinite retention creates a cluttered library that no one trusts.

A structured deprecation process:

1. Identify all instances of the deprecated component. In Webflow, you can find all instances of a component via the component panel. Do this before you start the deprecation process.
2. Build the replacement component first. Don't deprecate until the replacement exists, is tested, and is ready to use.
3. Migrate existing instances. For each page using the deprecated component, replace it with the new one. This is manual work — there's no automated migration in Webflow — but it's safer than leaving mismatched components in production.
4. Rename the deprecated component with a -legacy suffix and add a note to the component description explaining that it's deprecated and linking to the replacement.
5. Set a removal date. The legacy component stays in the library for one full audit cycle (see below), then gets removed. This gives anyone who missed the migration a window to catch up without the system becoming permanently cluttered.
6. Log the deprecation in the changelog. Include the date, the reason, the replacement component, and the removal date.

This process takes more effort than just deleting the component, but it's the only approach that doesn't create invisible production breakages.

Editor Onboarding

A design system that isn't understood by the people using it will be ignored by the people using it. Onboarding isn't a one-time event — it's an ongoing responsibility of the design system owner.

Effective onboarding has three layers:

The Style Guide Page

Every Webflow project we build with a design system includes a style guide page that's accessible to editors but not published to the live site. This page demonstrates every component in use, shows the variable tokens being used, and — crucially — explains when to use each component and when not to.

The "when not to use" section is as important as the "when to use" section. Editors make better decisions when they understand the intended use cases, not just what the components look like.

The Onboarding Session

New editors should receive a structured walkthrough of the system before they start making changes. We typically run a 45-minute session covering: how the component library is organised, how to find and use components, naming conventions, and who to ask when they're unsure. Record it — it becomes useful for future onboardings and as a reference document.

The Contribution Process

Editors and developers will inevitably identify gaps in the system — something they need that doesn't exist yet. Giving them a clear process to request new components (rather than building one-offs) keeps the system growing in a managed way. A simple Notion form or Slack request template is enough. What matters is that there's a defined channel for contributions rather than a free-for-all.

The Quarterly Audit Cadence

Regular audits are how you catch drift before it becomes structural. We recommend a quarterly audit for active sites — more frequent for sites with high publishing velocity, less frequent for relatively static sites.

A design system audit covers:

• Component usage scan. Are any deprecated components still in use on published pages? Are any one-off custom elements being used in situations where a component should be used instead?
• Token compliance check. Are hardcoded colour, spacing, or typography values appearing in places where design tokens should be used? (This is often detectable by spot-checking the CSS of recently edited pages.)
• Visual consistency review. A manual review of key pages against the design system — looking for heading hierarchy inconsistencies, spacing irregularities, and colour use that doesn't match the token definitions.
• Component health check. Are there components in the library that haven't been used in six months? These may need to be retired or reassessed for relevance.
• Documentation review. Is the changelog up to date? Is the style guide page accurate? Are component descriptions current?

The audit produces a prioritised list of remediation items. Not everything from every audit needs to be fixed immediately — but it needs to be triaged, assigned, and scheduled. Audit findings that go into a backlog indefinitely are findings that don't get fixed.

Handling Design Drift in Practice

If you're reading this because your site has already drifted and you're trying to recover, the approach is the same as the audit above — just more extensive. A design drift recovery typically takes two to four weeks for a medium-sized site, depending on the severity of the drift and the quality of the original system documentation.

Start with the highest-visibility pages (homepage, core service pages, the pages that senior stakeholders look at) and work outward. Don't try to fix everything at once — prioritise by impact and work through the list systematically.

The most common drift pattern we encounter is hardcoded values in recently-added sections. The design system has tokens for everything, but whoever added the new section didn't know about them (onboarding failure) or found it faster to hardcode values (usability failure). Both are fixable — but the fix needs to address the root cause, not just the symptoms.

Our design systems team runs design drift recovery engagements for clients who've inherited a system that's no longer being maintained — including full audits, re-documentation, and governance setup. If you've acquired a Webflow site with a design system in an indeterminate state, that's often the right starting point.

The Long-Term Picture

A design system that's maintained well compounds in value over time. New pages get built faster because the components exist. Brand changes propagate across the site in hours rather than weeks because the tokens are properly used. New team members become productive faster because the system is documented and the onboarding exists.

A design system that's maintained poorly compounds in the other direction. The gap between the Figma source of truth and the live site grows. Trust in the system erodes. Teams stop using it because it doesn't reflect reality. Eventually you're in a position where rebuilding from scratch looks appealing — which means the original investment is effectively wasted.

Governance isn't the glamorous part of design systems work. But it's the part that determines whether the investment holds its value. An hour a month of proactive maintenance is worth considerably more than a week of reactive recovery.