• 1 for this idea. Our design system team struggles to keep up bug fixes and improvements from our demanding team - really hard to prioritise. I would love if I could simply branch the design system library, make the changes I need, use the branched component in my own design work, and help out the the design system team at the same time.

That’s what we all have been hoping for since … 2021 (wow). No communication, no progress, no plans. Just think it is not how they intended the feature (no idea how it would be usefull without it, but ok. Maybe it became too complex once they implemented the first beta, that they are trying to remove the feature all together).

I am kind of surprised that this isn’t a feature. 😕 It’s great that we can make changes to one file, but it’s not quite what I anticipated after we upgraded to organization today.

Hey! I’m in the early stages of creating our design system and we have a WIP library file for the beta components, and another one for handoff. But I’m not sure how to handle the dependencies between the two files. It would be really helpful to hear from your experience! Are designers consuming components from both files??? Is there a duplicate of each component in each file? Does this lead to double maintenence?

It’s hard to understand how this isn’t already implemented. It should be a very common pattern for people to use libraries containing master components and variables (typically the design system) in external files, and instancing these in various prototypes. For example, we have a library containing system components and variables for iOS 17, and another containing our bespoke design system. Both of these libraries are utilized whenever I make a new design file for our iOS apps.

How are you going to create branches in prototypes to explore design options or work on features if you can’t also branch the design system library file in a corresponding manner?

This would be a major improvement to the entire workflow for design systems. I should be able to access the components of a branched library to test changes against the consumer files.

Is this any closer to being considered in a future update? The organisation plan really needs the advanced features to be more joined up. Currently most of the advanced features are only half as useful as they should be

Just upgraded to able to use Branches and this is an important feature we’re also looking for.

When your organization grows and you have a Design System Figma Library file containing your components and are using separate Figma files for Layout designs you inevitably run into this problem.

For a new layout in File A you might need to use an updated version of a new component in your Library file B.

Right now it is possible to simply copy/paste the new/updated component from the Library branch and use it in any other file. The cool thing is that it actually keeps the reference to the component.

The problem is that wherever you use an instance of that new component it will keep notifying you of a necessary component update to be done to keep it in sync with the Library Main file.

It’s very difficult to make sure to not accidentally click update for that component or to apply ‘All updates’ in a file.

Would be nice if any copy/pasted component from a branch would keep its reference to the version in that specific branch unless overridden to fall back to its Main File version.

Any updates on this, Figma? How can design teams effectively support a business with systematic approaches if we can’t visualize large-scale design changes, like rebrands, through the design system?

Developers have had branching, staging areas, and similar tools for years, but design is still lagging behind. To close this gap, we need features like these to showcase the true power of design systems, enabling smoother collaboration from designers to development.

Can we get some meaningful upgrades to the tool instead of these monthly gimmick updates? We need features that actually make us more efficient. This is just one example of many that would genuinely elevate the design and creative process across the industry.

Bumping this topic up to the DS Project team

A bit late response to that but since I have issues with branches for the 47854th time I decided to look up the forum. My way of dealing with the fact that my Design System is in a separate file and I can’t use branch variants in another branch is stupid but it works most of the time.

I started making branches of the DS with an empty page called “Screens”. I would copy/paste designs on this page that will use the new components. Then I would color code them - new screens that need to be transferred are in a brighter color and old screens that will get updated just from publishing the library are just white. When merging the branch I’ll move them to the correct project file.

The pain begins when I’m working on V2 of something while the dev team is still on V1 or BETA and I can’t merge the older versions I need. As far as I can see most people here have this issue and I kinda regret that I went with that decision for branching… It has created more issues than goods and it’s already too late to go back without useless labor.