After working on several side projects, I realized that designing UIs by continuously adapting and restyling external UI kits such as MUI was less effective than building my own design system with customization in mind from the start.
In component-based UI design, components and design tokens (Variables in Figma) are tightly connected. Many free UI kits provide only Instances while keeping the underlying master Components inaccessible. As a result, I often had to recreate the master Components myself before I could customize them or integrate them into my own design system.
At the same time, I didn't want to pay for premium UI kits for personal side projects—or small team projects that weren't intended to become commercial products. Building and maintaining my own design system felt like a better long-term investment than repeatedly adapting someone else's.
Problem 1: The repetitive work of changing Variables
While building my own component library in Figma, I ran into a problem. The more Component Properties I added to maximize customization, the more Variants each component needed. On top of that, assigning the correct Variables for each Property value became increasingly time-consuming. For example, adding a single "Color" option could result in many new Variants being created across combinations of "Size", "State", "Hierarchy", and other properties. Every one of those Variants then required the Variables used for fills, strokes, and other styling properties to be updated manually.
As I looked for a better way to handle this, I started wondering: what if Variables could be replaced the same way we use Find & Replace on text? If a Variable name followed a predictable naming pattern, why not replace part of the name and automatically switch the linked Variable? There were already plugins that solved part of this problem, but they had limitations. Variables used in Effects for things like focus outlines were not supported. The plugins were also relatively expensive compared to what I was willing to pay for a personal project. At that point, I thought, "Why not build one myself?" That idea eventually became Rebind.
My goal was simple: if a Variable can be linked somewhere in Figma, users should be able to replace it without having to think about where that Variable is linked. Rebind tries to support as many Variable-bound fields as possible so that replacing Variables feels as straightforward as Find & Replace on text.
There are still some cases that I either didn't discover at the time or postponed because the implementation became too complex, such as supporting Variables linked in Styles. However, it should work reliably for most Variable links you are likely to encounter in everyday component work. As someone who regularly builds and maintains components myself, I still use Rebind frequently today.
Problem 2: Variant explosion
Rebind made it much easier to update Variables across large numbers of Variants, but it didn't solve the underlying problem: the sheer number of Variants themselves. As a component accumulates more Variants, it becomes increasingly complex and heavier to maintain. That complexity doesn't stay isolated. Once the component is used inside other components, the cost of that complexity propagates throughout the entire design system. To reduce this Variant explosion, I experimented with several approaches.
The first approach was to separate structural properties from visual properties. I created one set of components to manage dimensions and layout, and another set to handle colors, hierarchy, and states. The structural component defined the core shape and sizing, while a parent component wrapped it to provide color-related variations for hierarchy and state. This worked reasonably well as long as the responsibilities of the parent and child components remained clearly separated. Overrides also remained fairly predictable within those components.
However, problems started to appear as the architecture became more complex. Once components were composed of multiple layers of group and item components, property values needed to propagate through deeper hierarchies, and overrides no longer behaved as consistently as I intended.
My second approach was to use Variable Modes like Component Properties. Using Variables to represent styling options was not a new idea. However, replacing Component Properties with Variables introduced a different problem. Changing a single Property value now required replacing every related Variable individually. Even when Variables were organized around the same concepts as Component Properties, components themselves had no direct knowledge of those relationships. And when Variables were designed as primitive design tokens rather than Property-specific abstractions, identifying the Variables associated with a given Property became even more difficult.
While looking for a way to simplify this workflow, I started thinking about Variable Modes, which are commonly used for themes such as Light and Dark modes. Since Modes are already exposed in Figma's UI, I realized they could be used in a way that closely resembles Component Properties. In practice, this approach significantly reduced the number of Variants I needed to maintain. It also allowed property-like concepts to be represented indirectly within the component system, without introducing additional component hierarchy.
Problem 3: Managing Variable Modes manually
Of course, this approach introduced its own set of problems. To use Variable Modes like Component Properties, every Variable first had to be grouped into the appropriate Mode structure manually. The most tedious part was assigning the correct Variables to each Mode value of the Variables created to replace Component Properties. As the number of property values increased, so did the number of Modes and the amount of manual work. And when Variables were designed with detailed naming conventions, finding the correct Variable in Figma's UI became a slow and frustrating process — very similar to the Variable replacement problem that originally led me to build Rebind.
Prop2Mode was created to eliminate that friction. The plugin is essentially an implementation of the workflow I had already been using manually. It finds Variables that can be grouped together, organizes them into a Mode structure, and automatically assigns the appropriate Variable to each Mode value of the generated multi-mode Variable. Instead of manually searching for and selecting every Variable one by one, the plugin performs those steps for me. Unlike my previous plugins, Prop2Mode also required much more consideration for long-term maintenance. The implementation became significantly more complex, but that complexity made it possible to preserve the relationship between Variables, Modes, and Collections.
As a result, I can always trace why a Variable or Collection exists, what Component Property it was intended to replace, and how the entire structure was originally generated.