Design systems: Figma libraries and coded components that stay in sync

When does a team need a design system?#

A team needs a design system when different people keep making the same interface decisions and the results no longer match. Typical signs: a second product or site sharing the brand, several designers or front-end developers working from one Figma library, a rebrand that has to reach every screen, and QA tickets about buttons and forms that differ from page to page.

We've seen it on our own site. A September 2026 inventory of our stylesheets found 185 distinct hard-coded hex colors and 144 distinct font-size declarations across 28 CSS files. Some belong to artwork and prototypes; the rest are being sorted into tokens, named exceptions and dead code.

A single marketing site with one designer rarely needs a system: the reusable components that come with custom web design are enough. If the product is still finding its core workflow, start with product design and turn the patterns that survive into a system later.

What a design system project includes#

A design system project delivers the same decisions in Figma and in code, plus the documentation and process that keep them aligned. The proposal states which of these are in scope and how each one is accepted. To start, we need view access to your Figma files and code repositories and one person on your side who approves decisions.

• An audit of existing screens and code: colors, type, spacing and components
• Design tokens for color, type, spacing, radius and motion, generated for Figma and CSS
• A published Figma library with variants, properties and every interactive state
• Coded React or Astro components whose props match the Figma properties
• Documentation with usage rules and accessibility notes for each component
• A contribution and release process with versioning and a changelog
• An adoption baseline measured in Figma and in the codebase

Starter kit or full system: how big should it be?#

Start with the components your team builds every week, not a complete catalog. A starter kit covers the foundations and the components on most screens; a full system adds themes, platforms, complex components and governance. We ship the kit as the first release and grow it from real requests.

Tokens and Figma variables: one source for design and code#

Design tokens are named decisions, such as action-primary or space-4, stored once and used by both Figma and the code. We layer them: raw values first, then semantic names that say what each value is for, so changing a brand color means editing one value instead of searching through files.

In Figma, tokens become variables. As of October 2026, Figma offers six variable types (color, number, string, boolean, timing and easing), up to 5,000 variables per collection, and modes for alternatives such as light and dark or a second brand: up to 10 modes per collection on Professional, 20 on Organization and no limit on Enterprise through extended collections.

In code, the source is JSON in your repository, which generates CSS custom properties. The Design Tokens Community Group published the first stable version of its file format, 2025.10, on 28 October 2025; it is a community group report, not a W3C Standard, and we follow it wherever your tools can read it. On dardo.studio, brand colors and type recipes are JSON files that generate the site's CSS variables, and the generated files are never edited by hand.

Coded components that match the Figma library#

A component is shared only when its Figma and code versions have the same name, properties and states. We design and build each one together, so a variant in Figma is a prop in code. React suits logged-in products, the kind we build through web app development; Astro suits the content and marketing sites built through our web development service.

Developers inspect designs in Figma's Dev Mode, which needs a Full or Dev seat on a Professional or higher plan; with Code Connect set up, Dev Mode shows your real component code instead of generated snippets. React components get Storybook stories for every state; Astro components get a specimen page in the project, the way our own system is documented.

Accessibility built into every component#

Accessibility fixed in a component is fixed on every screen that uses it. Several WCAG 2.2 success criteria are decided at the component level:

• Text contrast of at least 4.5:1 (3:1 for large text), and 3:1 for the visual parts of controls (1.4.3, 1.4.11)
• A visible focus indicator that sticky headers and overlays don't fully hide (2.4.7, 2.4.11)
• Pointer targets of at least 24 by 24 CSS pixels, or enough spacing around them (2.5.8)
• Form fields whose labels, instructions and errors reach screen readers

We check contrast on token pairs before they reach a component, and test each component by keyboard and with a screen reader. Storybook's accessibility addon runs axe-core on every story, and Storybook's documentation says it catches up to 57% of WCAG issues, so automation is the first pass, not the verdict.

Our own system requires every interactive pattern to define hover, focus, active and disabled states, 44-pixel touch targets where the design allows, reduced motion, and English and Spanish text. To find where your current interface fails first, start with an accessibility audit, from USD 690.

Governance and adoption: how a system stays in use#

A design system stays useful only if someone owns it and there is a clear way to change it. Before handover we agree on an owner on your side, how teams request a component or variant, who reviews it for design, code and accessibility, and how releases are versioned. Exceptions are named: a one-off value for a campaign lives beside that work and doesn't quietly become a standard.

Adoption is measured in Figma and in code. Figma's library analytics, on the Organization and Enterprise plans, count insertions, detachments and instances for each component, style and variable, with up to a year of history. A component that gets detached often doesn't fit a real need yet and moves up the change list. In code we count imports of system components against local copies and hard-coded values.

After a brand refresh, tokens carry most of the rollout: new values reach every component that uses them, and the same counts show which screens still need hand work.

What moves the cost, and who owns the system#

The price follows the number of components and variants, the platforms they ship to, the number of brands or themes, and how much existing interface has to move onto the system. Our inquiry form asks for a budget range, from under USD 5,000 to over USD 60,000, and the proposal fits the scope to it; starting prices for other services are on our pricing page.

You own the result: the Figma library sits in your organization's workspace, tokens and components in your repository, and any package is published under your name, with our team added as invited members. Font licenses should cover web and app use before a typeface enters the system. Dardo is a founder-led team of three in Bogotá, on UTC−5 all year. If you need a team running a system across dozens of products for years, an in-house team is the better long-term owner; we can build the foundations it takes over.

Questions before you choose#