Maintaining a design system in Figma

Design systems evolve over time and so do the platforms they are built on. As maintainers, we need to make sure to keep them up to date. This includes Figma and your Figma design system library. Figma has only a basic versioning, so we need to be careful with changes. But there are some techniques to make sure we don’t release updates that break consumers Figma projects.

In this article I will explain what I find to be the best process to make sure you can keep your library up to date without breaking designers’ files.

Figma branch PR process

I have often seen Figma files, especially for design systems, turn into chaos. Since it is relevant for everyone the whole team works in the same file. Adding new components, fixing bugs, exploring what components can do.

While this seems logical, it does come with a few problems:

• components may be published in a half-changed state together with other changes
• it is hard to write change notes as you don’t know what was changed and why
• no review process for changes
• noise in the publish window makes it impossible to tell what changed

Many changes in the publish window create anxiety in library maintainers.

The solution is to lock down the process similar to a GitHub repository. In most repos only a select few are allowed to merge changes into the main branch. Or there are other safeguards in place, like requiring approvals.

In Figma we can implement a similar flow by locking down the main file and requiring branching¹ for every change.

You may initially get some pushback from designers as they are not used to branches and this makes their workflow more complicated. While true, it is only a minor inconvenience that will be forgotten in a week or two.

The benefits greatly outweigh the downsides:

Encapsulation

Every change is encapsulated as a pull request² (PR) so there is no interference between folks working on the file at the same time.