Component properties can't be set by interactions — and it's blocking Figma's AI/code vision

+1, I completely agree that this is a downright confusing oversight given Figma’s current direction, but also what Figma is pitched as from the beginning. From the beginning, I thought the whole point of Figma was being able to make libraries of colors and widgets as nested components with prototype interactions, yet this whole time they’ve added things like variable modes and component properties and everything, constantly dancing around the ability to give instances their own custom state.

An example of this “dancing around” I mention is the heaps of interesting complex functionality demonstrated in the https://help.figma.com/hc/en-us/articles/15253268379799-Variable-modes-in-prototypes article and accompanying Advanced prototyping playground file https://www.figma.com/community/file/1234939241273272375, which all looks extremely cool and powerful and useful, at least until the moment it all comes crashing down when you realize that all of that interesting, useful, rich interactive state is global for your entire project/page with no option to localize to a component or scope. They made it so you can do all this like objectively cool stuff, but every step of the way they made it completely impossible to package it up into a component you can put in your design system and actually re-use.

At the Config India 2026 event that just occurred, they had a segment titled “design systems,” which I had prayed meant they were finally going to prioritize these longstanding structural issues that had been invalidating the idea of component-based design systems that I thought the whole point of Figma was, but it wasn’t at all. What they showed off was also something important that had also been missing for far to long, the ability to see and track down issues with the relationships between files, and audit the adherence of your design system to using the design token variables you defined, but I was dumbfounded it didn’t include even a passing mention let alone a commitment to fixing component composition and interaction, instead focusing on AI and how the new design system flow thingy would make it easier for your agents to not get completely lost in the library inheritance nightmare dimension. That’s nice and all, but when can we humans, and you know what, when can our agents too be allowed to create widget libraries that are both interactive and built with shared primitives, as the Figma dream had long promised.

I wrote another long-winded rant in another related thread linked below, but I think your description is actually a little bit more fitting- that currently individual instances can have their own local interactive state, but only through the variant swap component property, which in addition to being extremely buggy when composing components made of instances of other components, flies in the face of what I can make of Figma’s own professed vision, in addition to the image I had in my head of Figma’s capabilities and intent. I would add to your description however that number, color, and enum (string with fixed possible values, like variant swap but having nothing to do with variants) properties are also necessary.

PS, It doesn’t fix this architectural misalignment as experience by the MCP, but on the human side I’ve been spending the last few weeks doing experiments and trying to figure out a method of circumventing this gaping hole for my specific use case (design system with a composed modular interactive widget library) using variable modes and wrapper components. I have had some success, but the road to where I am right now and what I can see ahead is absolutely riddled with bugs and inconsistencies. The most egregious of which I’ve made community posts about and recently escalated to bug report/support tickets, but I’ll see if I can share the workaround if I’m able to complete it, however incredibly complex, inconvenient, and unstable it may be (my proj file is corrupted rn😭). The main idea of the workaround is to capture interactions with a wrapper component which has a variant for each state of the interaction, on each of which variable modes for each kind of interaction are overridden accordingly. Thus, any child component which gets nested into that wrapper in any manner can have properties subscribing to those variable modes to receive the interaction. I describe it in more detail in my comment in the “Create variable in component scope” thread I linked above. In practice however, even under the assumption this workaround even covers your use case, implementing this is made extremely challenging due to some similarly incredibly long-standing and talked about bugs like this one I wrote about, which also has an incredible at least 11 related outstanding threads:

If either one of these, that being the Overrides on Instances… bug(s) or proper interactive local component variables/properties weren’t a problem, all would be well- but it’s the combination of these that from my sisyphean experience make it nearly impossible, or at least egregiously difficult, to create the kind of composed, single source-of-truth design system Figma preaches year after year that Figma is all about, even if you are willing to go off the deep end to try to circumvent it yourself.

I would like to add that there is one small additional architectural consideration to keep in mind- when and where the link happens. What you and some others have described- component properties becoming a sort of local variable that every instance of that component gets it’s own copy of- is for sure an absolute necessity, but I think there is another system that is required in addition to make the underlying data model truly expressive. Consider a checkbox-box component used inside a checkbox-list-item component. You want the box to react to the toggling of the list item, which would make sense to wire up to some interaction event in the checkbox-list-item component using this proposed settable component property/local component instance variable system. However, what if you also want it to react to the hover and pressing states, or custom states like keyboard focus highlight. You would have to know to properly capture and articulate all of these things every time you use the checkbox-box component. You could consolidate the definitions of these interaction behaviors with a single wrapper component that captures and drives those states using the new system, but you will still have to know to actually bind the instances you pull in under that wrapper to use those locally-defined properties. At that point, you might as well use variable modes instead of the component properties, that way the checkbox-box component can bind to those variables in it’s component declaration, since they are defined globally, but the gap still exists that there must be a better way to articulate a variable mode override interactively for each instance of a component, and any other advanced interactions needing numbers or strings or mathematical expressions like a volume slider or something are completely inexpressable with variable modes.