Library Freeze System

The Starting point: 3000 components but no tracing.

Four levels, variables shared across brands, a commons layer, an extended commons for retail brands, and (at that point) two brand-specific UI kits: Brand A, web-first, and Brand B, app-first. Together holding around 3000 components counting variants individually and 8 designers working across them daily, pulled in from several different consulting companies, most with no prior design systems experience and no clear hierarchy despite a nominal lead. Separately, the dev team pulled from these libraries on 2-week sprints that mirrored the design cycle. The problem wasn't the size of the libraries. It was that, between each sprint, there was no record of what had changed or who changed it, and the bigger the libraries grew, the worse that got.

Before building anything we needed to set a process, not just a tool: a library freeze aligned to the dev team's sprint. At the end of each sprint, design freezes the library at a known state; development pulls from that save point. It gave both teams a shared clock; everyone knew which version they were aligned to, and a changed library stopped being something developers discovered mid-sprint. The plugin came after the process, not instead of it, to make that freeze cheap to run and easy to trust, rather than another manual step someone would eventually skip.

Security policies within the Client's Figma environment required all plugins to be requested via a formal acceptance process. Any new plugin needed admin approval before the test cycle, and that timeline ran longer than it would've taken me to just build a custom one myself.
So I did.
Not to bypass process for its own sake, but because the team needed the tool before the request cycle would have delivered it.

Draft, Test, Validate.

It started as a page of rules. Freeze on day 7, starts at noon, etc etc. Six rounds in, the process became clearer on each one landing on the current updated structure: 5 defined stages, a streamline process, clear ownerships, roles and outcomes criteria. Documentation was updated and readied for future potential onboardings on the team, separating each phase with its own checklist and support templates and prompts.

Clear rules and red lines were set for the team: Foundations must be left untouched once a freeze starts; anything that comes up gets queued for the next sprint instead.
Benefit from having a larger design systems team, the role of conductor of the freeze rotates, with this sprint's conductor becoming next sprint's reviewer, so the process doesn't depend on one person remembering how it works.

Underneath it all: The need for a Tool.

With a system now in place a hidden friction point came clearer into view. We were relying on what was pending to be published on each library as the only, very unreliable source of changes across the libraries. I devised a POC changelog using a Notes component from our toolkit, to be used and left by designers next to the components touched, iterated or created, so they could all be collected by the time the freeze came around.

This became the foundation and defined the PRD of the Changelog Plugin.

The friction was deliberately kept as low as possible. We are asking for designers to keep in mind and remember they have to log the changes right after they are done.
Key decisions to achieve this:

• Figma Generative plugin instead of traditional plugin: an unexected benefit of figma's own generative plugins is that they are bound to the files they are run in AND they appear on the right action bar. No need to remember to launch a plugin, it's always there on hand ready to use it.
• Auto detect and auto fill: component's name is filled by simply selecting the component on the canvas. User name and timestamp are autogenerated - removing the ownership traceability problems.
• Daily use first an upfront: plugin opens ready to log in a partial log. No navigation inside needed. Freeze and Snapshop functions are a couple clicks away, with a double verification built in to avoid unwated overwrites or untimely compilations.

The Partial Changelog entry tab in particular needed almost no explanation; the lower the friction to log a change in the moment, the more likely anyone actually does it.

Outcomes

Full adoption of the process and plugin within the first two months.
Freeze documentation and steps ready for onboarding.
Across 4 successful full freeze runs, plugin performs with no bugs detected, zero pushback. Plugin is now self-published on Figma Community.