Automating Design System Release Prep with an AI-built Figma Plugin

Verizon Design System

  • Year

    2026

  • My Role

    Lead Experience Designer - Design Systems

Note: Due to confidentiality agreements, visuals and product-specific details have been simplified or recreated. The work shown focuses on my design process, responsibilities, and outcomes while respecting client and employer confidentiality.

About the project

Every release of our Design System required manual prep work in the Figma library file before it could be released. Two version numbers had to be kept in sync across the file.

  1. Component version - a date stamped in each component's description, marking when it was last published.

  2. Library version - a date tracked at the file level, marking the most recent publish of the whole library.

Updating both for a small release of one or two components will only take about 5 minutes. But it climbed to about an hour for a large release including many or all components. It was repetitive and error-prone.

With this plugin, this same update now takes under a minute or two cutting the release prep time by 80-95%.

The opportunity

I can't code. But with the latest AI tools, I saw a chance to remove this manual step entirely, and make releases easy for anyone on the team, not just whoever knew the file inside out. I used GitHub Copilot in VS Code to build a Figma plugin that automates the version update process.

I kept the plugin internal rather than open-sourcing it. Every team structures their files and versioning differently, so a one size fits all plugin may not work. This one is built specifically around how our library is organised.

How I built it

Giving the context to AI

I walked Copilot through how our file works: how component descriptions are formatted and where the version sits inside them, and how library version variables are set up to track the file's latest publish date.

Iterating toward the right output

I started with basic functions and built up incrementally, testing each change before adding the next. I kept the project under version control throughout, which mattered more than I expected. As someone who can't read code fluently, I couldn't always tell where an AI-generated change had gone wrong, and the AI itself couldn't always revert cleanly to a known-good state.

Testing

Once the core logic worked, I ran the plugin against a sandbox copy of the file, so I could safely test real release scenarios to confirm if the plugin works the right way before using it on the live file.

How the plugin works

The plugin scans the file and pulls two things:

  1. Every component that has a version in its description.

  2. Every variable in the "Version" collection.

From these two, it has everything it needs to update version numbers across the file in one pass.

Performance

Our file is large, so I also optimized for speed. We keep unpublished components, ones we use internally, on a dedicated page. Since the plugin has no reason to touch them, I set it to skip that page entirely, cutting down scan time.

Learnings and way forward

This project changed how I think about the boundary between design and engineering work. A task that used to eat upto an hour of manual clicking is now a one-click step anyone on the team can run.

This experience showed me that AI has a real place in the design systems workflow beyond just a plugin. Going forward, I want to keep looking for the manual, repetitive parts of our processes like audits, documentation, QA checks and evaluate where an AI-assisted tool could take that work off the team's plate the same way this one did.