Variables or Variants: Finding the Right Balance
More variants or more variables? The right choice isn’t just about prototyping—it’s about how teams scale design.
Prototyping with Variables: A Design Dilemma
Yesterday, I had an interesting conversation with a friend who asked: "Can I control a prototype using only variables?" It was a simple question—but one that opened up a much deeper discussion about how we approach designs and design systems.
The straightforward answer? Yes, we could achieve the effect with basic prototyping—using a "Click" interaction to navigate between frames. But that wasn’t the real challenge.
The real question was:
💡 If we wanted a fully variable-driven prototype, what would be the best approach?
This led us to a classic dilemma in design systems:
More Variants? A structured approach but requires managing multiple states manually.
More Variables? A flexible, scalable system—but potentially complex for new users.
We brainstormed different solutions and tested them step by step.
Testing the Approaches: What Worked and What Didn’t?
1️⃣ Manual Rewiring & Style Adjustments
Our first instinct was to keep it simple—using manual rewiring to change interactions and manually adjusting colors, typography, and states for each frame.
✅ Pro: Keeps everything within a familiar variant-based structure.
❌ Con: Every frame required manual updates to color, text, and styles, making it time-consuming and inefficient.
❌ Con: Not scalable—each designer using the prototype would have to understand and replicate the wiring.
It worked—but only if you were willing to manually maintain every interaction. This wasn’t an ideal out-of-the-box solution.
2️⃣ Controlling Everything with Variables
Next, we tried putting the control entirely on the variables side. Instead of manually adjusting styles, we used:
🔹 Color Variables to change button states dynamically.
🔹 String Variables to switch text labels based on interaction.
🔹 Number Variables to modify spacing and sizing without touching the frames.
✅ Pro: This turned the prototype into a true out-of-the-box solution. Designers could simply drag and drop the component into their prototype without understanding its inner workings.
✅ Pro: No need for rewiring—the component dynamically updated itself.
❌ Con: Might require an initial learning curve for designers unfamiliar with variable-driven interactions.
This method made the prototype scalable, reusable, and easier for rapid prototyping—but also introduced a new challenge: Does every team need this level of automation?
Business Value: Customization vs. Scalability
Not all companies approach design systems in the same way. The best method depends on how a design system is meant to serve its users:
📌 White-Label Products (B2B & SaaS Companies)
Companies that sell customizable design systems need flexibility. Clients should be able to reconfigure components without limitations—so an approach that leans on variants might be better or not we can control things using Design Tokens.
📌 Internal-Only Design Systems (Enterprise Teams)
For teams working internally, the goal is speed. Designers don’t want to manually rewire prototypes. They need plug-and-play efficiency, making variable-driven components more valuable.
This is where the challenge comes in—one size doesn’t fit all.
✅ Some teams need approach #1 (manual rewiring) for full control.
✅ Others thrive with approach #2 (variable-driven, seamless prototyping).
and there can be multiple number of different approaches using different methods, my current obsession (using Design tokens)
This leads to a bigger discussion: How do we balance customisation with ease of use?
The Real Challenge: Prioritisation
As design system creators, we can’t build for every possible use case. Instead, we have to:
✔️ Identify the most common pain points.
✔️ Listen to real users and their feedback.
✔️ Prioritise features that improve the enterprise experience—without making the system overly complex.
At the heart of it, a great design system is both structured and adaptable. Too much structure limits flexibility. Too much flexibility creates chaos. The key is to find a balance that serves the majority of users without overcomplicating the experience.
So, how do you approach this balance? Would you choose more variants or more variables? Let’s discuss.
💡 Next Up: Unlocking the Power of Design Tokens & Variables in Figma!
Ever wondered where design tokens might be used and where variables could work better? Or even how to use both together? In the next issue, we’ll break it all down so you can build scalable, flexible, and future-proof design systems. Stay tuned!
🎯 Got questions or want to chat more about design systems? Book a quick call with me on Topmate—I’d love to hear your thoughts and help answer any questions.
🔍 Let's connect! Check out my profile and follow along for more insights on design systems, UI trends, and Figma best practices.
📩 Hit reply! I’d love to hear how you’re using tokens & variables—or what challenges you’re facing. Your input might even shape the next newsletter!
Until next time,
Ankur Khatal