Start with what your design system needs to support, who will use it, and what’s already in place. Set clear conventions, build accessibility into your approach, and give your team a shared reference to work from.
Decide what your design system should help your team achieve, such as consistent branding, faster page building, or easier collaboration. Ask teammates where they repeat work or run into limitations, then use those needs to prioritize what to build.
For example, a team managing regional sites might need shared brand standards with room for local differences. Your team might also want AI agents to build on-brand pages that need fewer corrections.
Pro tip: Make goals specific enough to guide your plan. Instead of “build faster,” try “spend less time assembling campaign pages.”
Identify what teammates need to do, then match their Webflow roles and access to those responsibilities:
Identify who will maintain the shared resources and keep their documentation current. These responsibilities may belong to one person or be shared across a team.
Pro tip: On Enterprise plans, use custom roles when teammates need a different mix of permissions than the standard roles provide.
Review what’s already in place before creating new resources. Decide what to keep, adapt, or replace:
An agent can help inspect these resources, compare them with approved references, and propose a plan before making changes.
Pro tip: When migrating, give your agent site-crawling tools or exported HTML and CSS to help identify existing styles. Ask it to flag gaps or inconsistencies.
Choose an approach for organizing your design system that your team will recognize. Start with how they describe things today. Do they look for a style by its appearance, a component by its job, or a pattern by the page it belongs on?
For example, color variables could be grouped into a brand palette or by uses such as text, backgrounds, and borders. Components could be grouped by function, such as navigation and forms, or by page type, such as products and campaigns.
Pro tip: Outline the groups you’ll use for components, styles, and variables. Add a few examples under each to check that the structure fits what your team needs.
Choose consistent naming rules for classes, variables, and components so teammates and agents can recognize what each one does and when to reuse it.
For example, card-heading and card-image show that two classes belong to the same pattern. A variable named Text Primary explains its job, while Blue 500 describes its color. Document the patterns you choose, including capitalization, separators, and any prefixes or abbreviations.
Pro tip: Explore frameworks such as Mast, Lumos, or Client-First for naming conventions that also help organize your site.
Give your team and AI agents a shared reference for your design system. Create a draft page within your Webflow site with examples of your colors, typography, spacing, and common components. Add brief guidance on when to use them, such as which button style is for a page’s primary CTA.
If you build multiple sites, consider creating a dedicated design system site for internal use. You can then share its resources across your sites through a Shared Library.
Pro tip: Show examples of hover, focus, and error states on your style guide page so teammates can see styles that could otherwise stay hidden.
Make accessibility part of your design system from the start. Define standards for color contrast, readable text, visible focus states, and keyboard navigation. Build these into your shared styles and components so teammates and AI agents can reuse them across pages.
Document what still needs checking when someone uses a component, such as choosing the right heading level or adding descriptive image alt text. Accessible building blocks still need to work in the context of each page.
Pro tip: Test shared components with a keyboard before putting them into wider use. Check that you can reach and use each control, see where focus is, and leave menus or dialogs.
Before building from scratch, explore cloneable style guides, starter sites, and frameworks. Options such as Lumos, Mast, Relume, and Client-First can give you established naming conventions, styles, and reusable patterns to build on.
Choose a starting point that fits how your team plans to organize and maintain the system. Review its documentation and customize it for your brand. If you work with AI agents, include the framework’s conventions in your Agent Instructions so they follow the same approach.
Pro tip: Check the starter’s documentation for custom code or external libraries it relies on. Make sure your team can maintain them.
Create styles, components, and page templates your team and AI agents can reuse. Set up options for customizing content and layouts, then test that everything works for those who will use it.
Create variables for reusable colors, typography, spacing, and other style values. Group related variables into collections and groups so teammates and agents can find them.
Choose names intentionally. Primitive names describe values, such as Blue 500. Semantic names describe jobs, such as Text Link. A semantic variable can reference a primitive, so you can choose styles by purpose while managing their underlying values in one place.
Use variable modes to prepare for different screen sizes or themes. For example, use automatic modes to set heading sizes for desktop and mobile so they adjust across breakpoints. Use manual modes to apply light and dark color values to different sections without assigning different variables to each style.
Pro tip: Reuse a variable when its uses should change together. A heading size and a section gap might both be 3rem today, but they should be adjustable independently.
Build a consistent starting point for styling your site:
Use the same variable across different styles when they should share a value. For example, a card’s padding and a layout’s gap could use the same spacing variable.
Pro tip: Before creating a class, check whether you can reuse an existing one or add a combo class for the variation you need. Ask agents to do the same to avoid duplicates.
Create components for things your team and AI agents will reuse, such as navigation, buttons, cards, and page sections.
Each instance is connected to a main component. Update the main component to change shared structure and styling across your site. Give teammates options to customize content and appearance on individual instances without changing the others.
Pro tip: Nest smaller components inside larger ones. For example, use your Button component inside a Card component so button updates also reach the buttons in your cards.
Add properties so teammates can change text, images, and links on individual component instances. You can also let them show or hide optional content, such as a card’s image. Leave anything that should stay the same across instances fixed in the main component.
Organize properties around what teammates will edit. For example, group a button’s text and link together with names that explain each option. Set default content that gives them a starting point.
Pro tip: Review Webflow’s suggested properties before accepting them. Rename any vague suggestions and deselect anything teammates shouldn’t change.
Create variants when a component needs different appearances or layouts, such as solid and outline buttons or horizontal and vertical cards. Teammates can choose a variant on each instance without creating a separate component.
Use variants for different versions of the same component, such as a card with its image above or beside the text. If the design needs a substantially different structure or serves a different purpose, create a separate component. Give each option a recognizable name and choose the default that teammates will use most often.
Pro tip: Open the component on the Component Canvas to create, edit, and compare its variants side by side.
Add a component slot where teammates need to add, remove, or rearrange other components within an instance. For example, a card section component could have a slot that holds as many or as few card components as the section needs.
Give the slot a descriptive name and use a class to define its layout and spacing. Add default components so new instances have a starting point, and choose which components marketers can add to it.
Pro tip: To let marketers change a component’s slot content on a page, place that component inside a page slot. Test this setup in Build mode before handing it off.
Make it easy for teammates to find the right component and use it:
Before handing components off to your team, test them with longer headings, optional content, and different variants at smaller screen sizes.
Pro tip: Ask a teammate to find and customize a component using their usual role. Watch for confusing names, missing options, or anything they need help figuring out.
Create static page templates to give teammates a starting point for pages they build often, such as campaign landing pages or event pages. Each new page starts with the template’s design, content, and page settings.
Add shared components such as navigation and a footer, then include a page slot where marketers can add and arrange components. You can fill the slot with starting components that teammates can customize or replace.
CMS Collection page templates work differently. They give every item in a Collection, such as blog posts, the same layout with content from its CMS fields. Both can have a place in your design system.
Pro tip: Page settings carry over from the template. Help teammates understand how to customize each new page’s SEO title, description, and social sharing image before publishing.
Components such as CTAs and testimonials can be added directly within a CMS Collection item’s rich text field, alongside text and images. Teammates can customize each instance’s properties, just as they would elsewhere on the site.
Some existing components may already fit well within your content. Others may need a compact variant or a separate version designed for rich text. Check how they look within the text column and on smaller screens.
Pro tip: Group components suited to rich text together or add a naming prefix so teammates can find them easily.
Use motion to guide attention, explain changes, and give feedback. Create consistent effects your team can reuse, then test that they work across pages, devices, and accessibility preferences.
Use motion to help visitors understand what to do or what just happened. It can confirm that an action worked, show where a menu opens, or guide attention to the next step. Avoid movement that competes with the content or adds animation just for its own sake.
Use CSS effects for simple changes, such as a button changing color on hover. Choose GSAP-powered interactions for coordinated movement or sequences, such as revealing a section’s heading, text, and image as visitors scroll.
Pro tip: For a multi-step animation, list what should move and in what order before building the timeline.
Define timing, easing, and effects for common situations so similar actions feel familiar across your site. For example, cards that reveal as visitors scroll should follow the same pattern.
Give interactions and actions descriptive names, such as “Card Reveal” or “Menu Open.” Document when to use each pattern, and add working examples to your style guide so teammates can see the motion alongside its settings.
Pro tip: Agents connected through Webflow MCP can build GSAP-powered interactions. Add your motion standards to Agent Instructions so agents can follow the same timing, easing, and naming conventions.
Build motion your team can reuse without recreating it:
Interactions added to individual instances are page-specific and don’t travel with the component.
Pro tip: Reuse classes with CSS effects you’ve already set up, such as hover transitions. Those effects carry over when you use the classes in a component and share it across sites.
Test interactions with realistic content, different screen sizes, and the browsers your visitors use. Check that controls work with keyboard and touch input where relevant, and that animations run smoothly. Test shared components on a receiving site, too.
Turn on reduced motion in your device or browser settings. Check that visitors can still reach the content and use controls when animation is reduced or skipped. Review agent-created motion against the same checks.
Pro tip: Publish to your Webflow staging domain to test the experience as visitors will see it.
Keep sites on brand with shared resources your team can maintain in one place. Plan how sites will use your design system, share it through Libraries, and coordinate updates as it evolves.
Share resources from one site so teammates can install and reuse them on other sites in your Workspace. A Shared Library can include components, variables, fonts, tag styles, and assets, along with component-scoped interactions and Agent Instructions.
The Library stays connected to the site you shared it from, called the source site. Make changes there, then share updates for other sites to review and accept. You can manage your Shared Libraries centrally from your Workspace settings.
Pro tip: Organize shared assets into folders and choose which folders to include, so teammates receive the resources they need.
Decide which site will maintain your shared design system and which sites will use it. A dedicated design system site gives your team a place to manage shared resources separately from the sites visitors use.
Shared resources are edited on this source site. Other sites install its Library and can use those resources alongside their own site-specific components, variables, and assets. Decide what should stay consistent across sites and what each team should manage independently.
A site can install multiple Shared Libraries, but a site that shares its own Library can’t install another. Shared Libraries work within the same Workspace.
Pro tip: List the sites that need your system and what they should share before choosing the source site.
Install a Shared Library to make its resources available on another site in your Workspace. You can apply its variables to styles, add its components to pages, and customize component instances through their available options. Your site’s own resources can still be used alongside the Library’s.
Shared resources are maintained on the source site. For example, you can use a variable from an installed Library but not change its value. Likewise, you can customize a component instance, but its main component can only be edited on the source site.
Pro tip: You can convert a component from a Shared Library to a site component if you need to edit it locally. It will no longer receive Library updates.
You can keep making changes on the source site after other sites install its Library. When those changes are ready, share a Library update and let teams know what changed.
Decide who will review and accept updates on each site using the Library. Check affected pages for changed layouts, missing content, or editing options teammates rely on. Publish each site when the changes are ready to go live.
Pro tip: On Enterprise plans, push Library updates to selected sites in bulk without requiring teams to accept them individually.
If your team often builds similar sites, save a site as a shared Workspace template. Include the pages, CMS structure, components, and styles they need so they can start with those pieces already in place.
Teammates can choose the template when creating a new site in your Workspace, then customize their copy. Later changes to the template won’t update sites already created from it. Use a Shared Library for resources you want to keep connected across sites.
Pro tip: Create a test site from the template before handing it off. Check for leftover branding, links, or settings teammates could easily miss.
Keep your design system aligned with the way your team works. Set a process for changes, give teammates and agents guidance they can follow, and review the system as your needs evolve.
Decide who can change shared styles, variables, and components, and who reviews those changes before others start using them. Match their access to those responsibilities.
Give teammates a way to request additions or report problems. Explain where requests go, who responds, and when a proposed change needs review.
Pro tip: Create a feedback form that asks which resource is involved, where it’s being used, and what needs improving. Include a place for screenshots or examples.
Give teammates one place to find current guidance, such as a style guide site, component reference, or team knowledge base. Explain which resources to use, what they can customize, and when they should ask for help.
Include examples of common tasks, such as choosing a card variant or building a campaign page. Assign someone to keep the guidance current when resources change.
Pro tip: Keep a short change log with what changed, why, and anything teammates need to do differently.
Agent Instructions store guidance on your Webflow site that agents can reference while working. Write a Design System skill or generate one from your site, then review and adapt it to your team’s workflows.
Use rules for expectations that always apply, such as checking for existing components before creating new ones. Use skills for tasks that need more guidance, such as assembling a campaign page. Insert resource references to connect the guidance to your site’s components, styles, and variables. Review instructions before enabling them.
Pro tip: Ask your agent to use a specific instruction on a small task, then check its work. If it misses something, ask what guidance was missing or unclear.
Set a review schedule, such as quarterly or after a rebrand, and assign someone to organize the review and track improvements.
Look for duplicate components, inconsistent names, gaps teammates have reported, and outdated guidance. Before changing a resource, inspect the pages, components, and styles that use it so you understand what else will change.
Test improvements on a small set of pages before applying them more widely. Update documentation and Agent Instructions to reflect the changes.
Pro tip: Mark resources you’re phasing out with a label such as “Legacy” so teammates know not to use them in new work. Remove them only after checking that nothing still depends on them.