Challenge
Identifying the Gap Before It Became a Problem
Managing two distinct brands within a single Figma environment meant designers were manually remapping color styles every time they switched brand context. We were duplicating files, hunting through overlapping styles, and repeating work that a better system could eliminate entirely. It wasn’t a crisis, but it was clearly unsustainable as the organization scaled.
The same gap extended to engineering. Without semantic naming, developers had to interpret design intent at handoff, which introduced inconsistency between the Figma file and the live product. Accessibility was equally manual. Dynamic Type compliance for iOS required after-the-fact audits that were hard to visualize and harder to document consistently.
With a third brand already on the roadmap, I saw the window to fix the architecture before the complexity compounded further.
Strategy
Designing a System Built to Scale
When Figma Variables launched in 2023, I recognized it as more than a new feature. It was the architectural primitive the organization needed. I proposed and led a full rebuild of our design library from the ground up, taking sole ownership of the transition from visual styles to systematic token architecture.
Semantic Naming
The first decision was naming convention. I moved deliberately away from primitive labels like "Yellow-500" toward functional, intent-driven names. The reasoning was practical: the same green that represented a primary brand color in Brand A was used for buttons, but Brand B used different colors for each. A primitive name like "Green-500" told you nothing about where or why it was used. Naming it brand-primary versus brand-button-primary made the intent explicit, removing the guesswork for designers switching between brands and giving engineers a clear contract at handoff.
Token Architecture
I structured the system across two files: a styles library housing all 198 tokens, and a component library consuming them. Within the styles library, I defined 6 variable modes, one light and one dark mode per brand, allowing three distinct brand themes to coexist within a single component set. What previously required duplicating entire files and manually updating individual color styles became a two-click theme switch.
Engineering Alignment
I treated engineering adoption as a design constraint, not an afterthought. Because I was building the token system in parallel with an engineering library refresh, I engaged developers early to validate the taxonomy before finalizing it. Developers adopted my naming conventions directly into the codebase, establishing the first true 1:1 correspondence between Figma files and the live product. As one engineer noted, “It will certainly help us maintain the standards” and the naming was already in production before the case was made.
Accessibility as a Variable
To address iOS Dynamic Type compliance, I engineered a dedicated “Size” mode within the variable structure. Designers could toggle any frame to the XXX-Large text size instantly, visualizing component reflow and scaling behavior in real time. This gave the team a fast, reliable way to verify that designs held up under the most demanding accessibility conditions before a single line of code was written.
Results & Impact
A Frictionless Path to Scale
The architecture proved itself when the third brand arrived. Rather than duplicating files and manually remapping every color style, onboarding required only mapping a new set of variables to the existing framework. It was the same two-click operation that had replaced hours of manual work across the existing brands.
198
Tokens
6
Variable modes
2
Platforms