How do you manage library versions?

How do you manage components in a shifting environment so that the old versions are still available for older design work to reference?

I’m designing in an organization with a design system, but the area I’m working in isn’t using it. I’ve built out a bunch of components (panels, local nav, cards) to match the current UI so I can efficiently make mockups that match the current product area.

As I do feature design I’m working to update the UI to match the global design system. I’ll update my composite components to use design system atoms (buttons etc.) and themes as I go.

As I do this, though, my old designs will break. Spacing, fonts, layouts, etc. will all change, and past projects will no longer represent the state of the product at that time. This is especially fraught if I’m working on the follow-on to a project still in development. I can’t have reference designs changing when I make updates for the next cycle.

How do you manage components in a shifting environment so that the old versions are still available for older design work? I anticipate my components will also mature in terms of configurability and flexibility as I go, meaning more variants and properties coming into the newer versions.

Hey @spiff, thanks for reaching out!

Right now, the best workaround would be managing the libraries separately, as 2 different libraries Old and New. Be advised that managing the design system this way may become frustrating unless you’re diligent in keeping all assets’ naming convention consistent across all versions.

Here’s an existing topic from the community that may help you think this through: Two separate libraries?

You could consider separating “future work” from “this is a mirror of production.” Our team tries to do this using branches for “future work” and then when that work ships, it merges to the main branch (which should be a perfect reflection of what’s on the production site). This gives designers a space to work on new stuff, but without compromising a reference that you’re not ready to have receive updates.

An issue with this is it could lead to branches being open for a long time. This largely depends on how you scope your work, but having branches hang out and accumulate many big changes could lead to issues when you go to merge. When you merge, the memory usage will spike as Figma reconciles the differences between the branches. Other folks have experienced crashes when trying to merge too many big changes at once.

All of this assumes you’re on a Figma plan that has branching! You could potentially do the same thing (with more work) with a workflow that goes something like this:

  1. create a “production mirror” file
  2. when feature work comes up, peel off a copy of the production mirror file to execute your changes
  3. when those changes go live, replace the production mirror content with what was in your file.

^ but that can get messy if you have many people doing step 2 concurrently.

1 Like

Thanks @dvaliao. We run a continuous delivery process, so there are multiple ongoing projects and the updates aren’t so clearly delineated. I guess I could consider each project to be a single version increase, but that still means there’s a new/duplicated library for each new project. I suppose that’s workable, though I suspect I’ll end up with a lot of library files. I think I’ll also have merge issues if multiple projects are being iterated at once.

That said there’s something here that I’ll think more about, and I’ll read the link you shared to see what’s been covered already. It seems like there’s a viable solution here and it may be better than having multiple variants of each component. Thanks for the suggestion!

I had no idea Figma supported branching! I have some reading to do. Thanks for the suggestion.

Yes! If you’re on the Organization plan or higher then you have access to the branch feature:

An unexpected benefit to using branches is that branches can help keep file memory in check.

Coming back to this thread again, I realized you may also be interested in @Nathan_Curtiswriting on versioning component libraries.

1 Like