Context
I have always liked Figma as a UX/UI tool. It has many strengths; besides, they keep adding new features, which keeps them at the forefront (not to mention they practically have a monopoly on the market). Another thing I find entertaining is designing components: building them with a smart, scalable, and well-thought-out structure, and then seeing how they perform.
However, that entails a process that, honestly, I find tedious: Documentation.
Bearing this in mind, I realized the need to automate this process. And just in time, because the Design System stopped operating under a centralized model and moved to a federated one, a shift that brought new challenges.
This new model meant giving more independence to other cells to design their own components, always under our team's supervision and respecting the guidelines established in our libraries.
Documenting a component correctly (its variants, properties, states, uses) is a task that takes time, and in a federated scheme, where more people would be creating components while considering the tasks that each designer might have with their respective teams, that time multiplied. Automating this step became vital.
Thus, the idea was born: a Figma plugin capable of generating component documentation automatically. The concept was simple — the designer finishes building their component, scans it with the plugin, and with a single click gets complete documentation, ready to be integrated into the library.
Technical Challenge
This is where the project got interesting for me. I have basic programming notions, but I am not a developer. And to build a Figma plugin, I needed to write code.
One option was to delegate it to someone on the team. But at that time, we were under a high level of demand, sustaining roadmaps and our own tasks, in addition to providing constant support to the various teams consuming the Design System. Adding this project to someone else's workload was not realistic.
So I took the initiative, starting with the design and the logic of how the plugin should work, how it should look, what steps the user would follow, what information it should extract from a component, how that generated documentation would look, etc. The following flow shows that first approach.
Plugin workflow logic
Since I'm not a programmer, the obvious step was to develop it with AI. Vibecoding is a very trendy term lately, so why not?
Prompt & play
I started with the most popular, Claude. It only took one prompt to get to a functional version of the plugin. It was about presenting the problem: what I needed to solve, what I wanted to use it for, and how it should work.
Something I was also interested in understanding is how this works internally. It runs through Figma's API and has a simple structure:
Plugin Architecture
Testing it was super simple too. In Figma, you go to Plugins > Development > Import from manifest. This allows you to test the plugin in a local environment before publishing it. This is where I realized that the UI the plugin gave me was very simple. So I decided to design it in Figma and transferred it to development using a FigmaToJson plugin.
With the design covered, all that was left was to focus on polishing the plugin's functionality: defining what the documentation structure would be, being able to toggle properties sections on and off, reorganizing them, and adding annotations.
At this point, I decided to make an important change to my workflow: migrate the entire project to Antigravity. When I said I was using Claude, I meant Claude chat, not Claude Code. This made my iteration loop not as optimal as I would have liked.
Migrating the project was the right decision. For those unfamiliar, Antigravity is an AI-powered integrated development environment (IDE) that incorporates agents (including Claude) capable of understanding the project's context, generating code, making modifications, and executing development tasks.
In progress...