Most designers use Figma variables for light and dark mode and leave it there. That’s fine — it’s useful. But variables are capable of a lot more, and once you start using them properly the way you work changes pretty fundamentally.
Here’s what I built with variables in ABBUI and why it’s worth the upfront investment.
Plan data as a variable system
ABB sells a range of NBN and broadband plans. Every plan has a name, speeds, pricing, inclusions, and a set of feature flags. The naive approach is to build a component variant for each plan — one card per plan, maintained separately, updated individually whenever anything changes.
The better approach is to treat the plan data as a variable set.
In ABBUI, every product card is driven by Figma variable modes — one mode per plan. The component is built once. Switching the variable mode populates it with that plan’s data — name, speed tier, price, features, all of it. There’s one component and as many modes as there are plans.
The prototyping benefit is immediate. Building a plan comparison page, a new sales funnel, or an A/B test variant takes minutes rather than hours. The accuracy benefit is just as significant — when a plan changes, it’s updated in one place and the change flows everywhere the component appears.
This mirrors exactly how a developer would build it — a single component fed by an API or a data layer. The design tool and the codebase are describing the same mental model.
Responsive layout as a variable system
The second system handles responsive behaviour.
Responsive design in Figma typically means creating separate frames for each breakpoint — mobile, tablet, desktop — and maintaining them in parallel. It works but it’s slow, and keeping multiple frames in sync as a design evolves creates overhead.
I built a responsive variable system that mirrors Tailwind’s default breakpoints. It covers columns, layout grids, typography scales, padding, margins, min and max widths, and three reusable spacing variables that cover the majority of layout decisions across the system.
For most pages and components, switching the viewport mode on a single frame demonstrates the full responsive behaviour. No parallel frames, no sync overhead. A developer looking at the handover can see exactly how the layout adapts at each breakpoint — and because the variable names map to Tailwind’s scale, the translation from design to code is direct.
Theming and colour modes
The colour variable system covers three themes — Base, Home, and Business — each with light and dark variants, for six modes total. This is documented in more depth in the colour system article, but from a workflow perspective the key benefit is the same: one component, multiple contexts, switched by mode rather than maintained as separate variants.
A designer building a new product page activates the Home theme. A developer implementing it applies the same token set. The design intent survives handover.
The wholesale architecture
One of the less obvious things variables enable is the ability to serve the system to wholesale partners.
ABBUI ships unstyled to partners — they receive the component architecture, interaction patterns, accessibility, and responsive behaviour, then supply their own design tokens in their codebase. The token contract is the interface between the system and the partner’s brand. Partners can theme the components without touching the underlying logic.
This is similar to the shadcn/ui model. The components are the infrastructure. The tokens are the brand layer. They’re deliberately separate.
The practical benefit for partners is significant — they don’t need to build a component library from scratch, and they inherit ABB’s production-tested accessibility and interaction patterns automatically. Updates to the core system flow through without requiring partner involvement.
The architecture is in place. The business capacity to operationalise it as a partner service is a separate conversation.
Spacing tokens
A minimal set of spacing variables goes a long way. I settled on three reusable spacing tokens that cover the vast majority of layout decisions across the system — component padding, section spacing, and layout gaps. Having named tokens rather than arbitrary values keeps things consistent and makes it easy to adjust spacing system-wide when needed.
The key was mirroring Tailwind’s spacing scale. A designer specifying gap-6 in Figma and a developer writing gap-6 in code are describing exactly the same thing. That shared language removes a whole category of handover ambiguity.
What makes this worth the setup time
Variable systems take longer to build than static components. The payoff is in repetition — every time you prototype a new flow, every time a plan changes, every time you need to demonstrate responsive behaviour, the investment pays back.
The deeper value is accuracy. Static components drift. Variable-driven components stay in sync. And when the design tool and the codebase are structured the same way, handover stops being a translation exercise.