Hey ​@Premkumar Sadasivam, thanks for bringing this up and welcome to Figma Forum!

I did some digging and tested this in my own Figma Design account. Variables behave independently based on the library they’re in — even if they share the same name and structure. This helps prevent unintended changes across larger design systems when multiple libraries are in use.

That said, I’d love to get this in front of our product team for a closer look. When you have a moment, could you share a bit more about how the two libraries are set up and the impact of needing to rework things manually? I’d also be curious to hear what an ideal workflow would look like for your team in this case.

Looking forward to learning more and advocating on your behalf. 🙏🏻

Thank you for your thoughtful response. ​@Tom Reem.

I appreciate your willingness to bring this to the product team. To provide more context on our setup and where the current limitations lie:
 

Our Setup:

We’re a service-based organization working with multiple clients, each with distinct brand guidelines and design styles. Previously, each client's design system (DSM) was maintained directly within their individual Figma files, leading to duplication and inefficiencies.

To streamline and scale, we’ve recently adopted a centralized DSM approach:

• L1 (Central DSM): Houses all core components and foundational variables.

• L2, L3, L4, etc.: These are client-specific style libraries, containing only variables and styles (no components), aligned structurally and by naming convention with L1.

This allows us to design with reusable components while dynamically applying brand-specific styling via library swapping—a workflow dependent on variable-level interchangeability.

What’s Working:

• Color variables

• Typography (text style) variables

• Spacing and padding (number) variables
  All swaps are successful across libraries as long as variable names and types match. This has been key to reducing effort when adapting designs to different brands.

What’s Not Working—Corner Radius Variables:

However, corner radius (number) variables do not swap—even if the variable name and type match in both libraries.

Example:

• corner-radius-sm = 8px in L1 (used for buttons).

• corner-radius-sm = 160px in L2 (client-specific, pill-style buttons).

• When we swap to L2, the visual radius remains at 8pxunless we manually reassign the new variable.

This inconsistency breaks the automation we rely on and introduces a significant manual burden, especially at scale.

Why This Matters:

Our approach relies on Variables > Alias Styles as the bridge between centralized components and client-specific themes. For this to be effective:

• All variable types—including corner radius—must swap seamlessly when libraries are changed.

• Without it, we’re forced to manually audit and reapply radius variables, which increases friction and reduces trust in the system.

Ideal Workflow:

We would benefit from parity in how Figma handles all number-based variables. An enhancement like a toggle—“Match “number variables by name across ”libraries”—would allow teams like ours to confidently scale a modular, multi-brand DSM architecture.

I’d be happy to provide examples or walk through the workflow in more detail if needed. Thank you again for considering this—your support is appreciated 🙏🏻.

Thanks
Premkumar Sadasivam

Hi ​@Premkumar Sadasivam, thanks for taking the time to lay out what’s working, what could be improved, and why this matters for your organization. That added context is really helpful.

I’ve shared your experience with the appropriate team and flagged your note on what an ideal setup might look like. While I can’t promise a specific timeline, we’ll make sure to surface any relevant updates if and when they go live.

In the meantime, feel free to keep an eye on our Release Notes for the latest. Appreciate you raising this.