
How to create Figma plugins without coding, using Claude Code to solve real Design System problems
I’ll tell you something that might surprise you: last week I created a Figma plugin. From scratch. In one afternoon. And I’m not a developer.
I’m not talking about dragging no-code blocks. I’m talking about a real plugin that runs on Figma Desktop, that the whole team can use, and that solves a problem that has been bothering me for months: checking whether the components on a screen are using the right tokens from our Design System.
The secret? Claude Code.
If you work with Design Systems (in any large company), you know that adoption is never 100%. There’s always someone using hardcoded colors, typography outside the scale, spacing “by eye”. And we, as designers who take care of the system, discover this late, usually in the code review, when it’s already become code.
I wanted something that would warn me beforehand. Directly in Figma. Like a linter, but for design.
I looked for plugins in the Community. Found generic things. None understood our tokens, our conventions, our context. And then I thought: what if I create my own?
Before AI, the journey would be something like this:
I gave up on this journey at least three times in the last two years. With Claude Code, the journey became different:
The difference is not just speed. It’s about who can structure the problem and some parts – in addition to executing little by little in an organized way and in stages.
Before getting into the process, it’s worth understanding what makes up a plugin. It’s simple:
my-plugin/
manifest.json → identity and permissions
code.ts → main logic (TypeScript)
ui.html → plugin interface (optional)
package.json → dependencies
tsconfig.json → TypeScript configuration
The manifest.json is like the plugin’s ID, it states the name, what it can do, and which files to use. The code.ts is where the logic lives. The ui.html is the interface that appears to the user when they open the plugin.
The Figma API gives access to practically everything: layers, properties, colors, text, components, variables. Everything you see in the properties panel, the plugin can read and modify.
I’ll show you how I did it step by step. You don’t need to follow it exactly, the main objective is to show the method and the structuring of the problem divided into parts for execution:
Step 1: Start the project
Here you have two paths, choose the one that makes more sense for you:
Path A: Start with Figma (more visual)
Open Figma Desktop, go to Plugins → Development → New Plugin, choose a template (I recommend “Custom UI” to have an interface) and Figma generates the folder with all the initial files. Then just open this folder in VS Code with Claude Code and start iterating from there. This path is good because Figma already creates the manifest.json with a valid ID and the right structure, you don’t need to worry about configuration.
Path B: Start with Claude Code (more direct)
Open Claude Code in the terminal and describe what you want:
“Create a Figma plugin that checks whether the colors, typography, and spacing on a screen are using Design System tokens.
The plugin should:
– Scan all nodes on the current page;
– Check if the colors are valid tokens;
– Check if the font sizes follow the typographic scale;
– Check if spacing is multiples of 4;
– Show errors in a side list with layer name and problem;
– When clicking on an error, select the node on the canvas.”
That’s it. In plain language, describing the behavior I wanted as a designer.
In both paths, the destination is the same: a folder with the plugin files open in Claude Code, ready to iterate.
Step 2: Claude Code generates everything
In less than 2 minutes, Claude generated:
I didn’t need to write a single line of JavaScript. Something that accelerated processes, for example, the learning journey of the stack and programming content.
Step 3: Test in Figma
I opened Figma Desktop, went to Plugins → Development → Import plugin from manifest, selected the manifest.json that Claude generated, and ran it.
On the first try it already worked partially. The color verification ran, but the errors weren’t showing the correct layer names.
Step 4: Iterate
I went back to Claude Code and wrote:
“The layer names are appearing as ‘undefined’. Adjust to show the node.name of each layer with an error.”
Two seconds later, fixed. I tested again. It worked.
I did about five more iterations: adjusted the UI colors, added a filter by error type, changed the list layout. Each iteration took less than a minute.
Step 5: Customize with DS context
The coolest part was when I passed the real tokens from IFDS – the iFood Design System to Claude:
“Here are our DS color tokens (example):
– surface-primary: #FFFFFF
– surface-secondary: #F5F5F5
– text-default: #1A1A2E
– action-primary: #EA1D2C
[…]
Update the validation to use these tokens as a reference.”
Instead of a generic linter, now I had a linter that understands our Design System. That knows #EA1D2C is action-primary and that #EA1D2D (one character difference) is an error.
For those who are curious, here’s a piece of the function that checks colors:
function checkColors(node: SceneNode) {
if (‘fills’ in node && Array.isArray(node.fills)) {
for (const fill of node.fills) {
if (fill.type === ‘SOLID’) {
const hex = rgbToHex(fill.color);
if (!isValidToken(hex, colorTokens)) {
errors.push({
nodeId: node.id,
nodeName: node.name,
issue: ‘Color outside DS’,
found: hex,
suggestion: findClosestToken(hex, colorTokens)
});
}
}
}
}
}
I didn’t write this. But I understand what it does. And most importantly: I can explain to my team what each part does, because Claude generates clean and commented code, and I can also ask what that means at any time.
The point is not “designer becoming dev”. It’s designer solving their own problem with the right tool.
If you’re thinking “cool, but what would I create?”, here are some ideas that occurred to me during the process:
Each of these can be created in one afternoon with Claude Code. And each one solves a real problem we face every day.
Plugins don’t need to be just simple utilities. With AI, the possibilities expand:
Some things that surprised me:
1 – The Figma API is more accessible than it seems. The mental model is simple: everything is a node in a tree. Colors, text, positions, everything is a property of a node. If you understand layers in Figma, you understand the API.
2 – Claude Code makes mistakes, but makes them fast. On the first try, the code doesn’t always work perfectly. But the feedback cycle is so fast that it doesn’t matter. Describe the error, Claude corrects it, test again. Three minutes.
3 – The greatest value is not the code, it’s autonomy. I don’t need to open an issue anymore, wait for a dev to have time, explain the context, review, ask for adjustments. I solve it the moment the problem appears.
4 – Plugins are visible impact. Distributing a plugin to the team shows that you understand the problem deeply, so deeply that you built the solution. And when the whole team starts using something you created in one afternoon, the value becomes obvious without needing a presentation.
If you’ve never used Claude Code, the simplest path:
You don’t need to learn JavaScript beforehand. You don’t need a TypeScript course. You don’t need a bootcamp. You need a real problem and the willingness to describe it well.
Figma becomes whatever you want. And the entry barrier has disappeared.
Tiago Penha is a Staff Designer at iFood, where he leads AI strategy for the Design Chapter. He works at the intersection of design systems, frontend, and artificial intelligence.
Estamos sempre em busca de desenvolvedores, designers e cientistas de dados apaixonados para nos ajudar a revolucionar a experiência de entrega de alimentos. Junte-se à iFood Tech e faça parte da construção do futuro da tecnologia alimentar.
Conheça nossas Carreiras
Como criar plugins do Figma sem saber programar, usando Claude Code para resolver problemas reais de Design Systems Vou contar uma coisa que talvez te surpreenda: semana passada eu criei um plugin pro Figma. Do zero. Em uma tarde. E…


Um manifesto sobre como criamos produtos que evoluem rápido e transformam o mundo. Produtos extraordinários não nascem prontos. Eles evoluem a cada decisão. No iFood, fazer produto é lidar com um ecossistema vivo, onde tecnologia, operação e negócio se movem…


Inteligência artificial, comportamento e contexto cultural estiveram no centro das discussões da primeira edição do iFood Camp, encontro promovido pelo iFood para discutir os desafios atuais da construção de produtos digitais. Realizado no dia 10 de março, o evento marcou…

Cada artigo é resultado da visão e expertise dos nossos autores. Veja quem contribui com nosso blog: