We have a really small Design Team:
2 DesignOps (incl. me) on Design System topic
5 UX Designers creating products
But the amount of the Design System consumers will grow once we make it public.
The public version of Figma must be identical to code snippets we offer, following the goal of one product.
I am currently defining the Figma libraries architecture and the design process.
Once I make the library public, I’ll keep improving the components. Initially, I wanted to do the improvement work in the same public library. Probably on separate pages in Figma and adding an underscore to the components in progress, etc.
But probably this is not a good idea because I don’t want to mess up something in production.
Does the following solution make any sense to you?
I’d borrow the concept of having multiple environments from the developer’s world and create two Figma libraries:
Public Figma Library “Production”: Live, being consumed, in sync with the code examples on the public Design System website.
Hidden Figma Library “Development Environment”: Contains improvements, future components, etc. The working space for DesignOps.
Should I add a third file – a core library containing tokens? That way the previously mentioned two libraries, DEV and PROD, would share the same tokens.
Hey, what I did was to combine the two really. So the components page combines the components on platform and mobile in separate sections for both (being the components in production). The Future to decide is component upgrades/improvements based on feedback and so on.
It depends on what you’re trying to achieve. With your last comment, if you have a DEV and PROD then the core lib one, for them to share the same tokens/variables, you can set up the tokens in the core and copy paste all the components into the core, but will have to attach the tokens/variables to all components. Even if you add the Core lib to the other 2 libraries the DEV and the PROD, I don’t think there is a way where you can share the variables/tokens between them, I think you would have to set this up again individually for each file. But I may be wrong.
@Imzzy Thanks for your comment! Your approach makes sense, if you don’t make your library public. In my case, I can not shаrе my work in progress (your page “Future to decide”) with the world. I really have to keep this in a separate file.
Regarding the variables, I just can’t imagine that they can’t travel from a core library to multiple working files. This would be a serious downside of this feature… But who knows. Gonna check this.
Yeah it’s a bit of a weird one, you have to publish it in the source file then enable it in the destination. It works in cases link here about that, as it comes up with an errors message when you copy and paste component with variables attached from one file to another. Copy pasting variables across files
We ended up with versions. There is a master file that sits in a separate team with limited access. This is where we do all the changes, add new components, update existing ones and so on. From time to time I make a copy of that file, move it to a public space and publish as a new version. Existing libraries go to archive. Upgrade usually happens via library swap, designers who want to use newer version simply swap older version with the one just released.
This way we keep design process steady, DS team is working on master file assured it won’t affect others, when it is time to release we had plenty of time to test new file and prepare release notes.
Side note about tokens. We keep them in a separate file sine variables are not swappable.
Dear Pavel, thanks so much. This is what I was looking for: a real-life experience from a team in a similar situation.
How do you inform consumers that there is a new version?
Do they still have access to the archived library? Or you just set the permissions, so nobody can access it anymore?
