HomeArtigo
How to create a Figma plugin using Claude Code (without knowing JavaScript)
PRODUCT & DESIGNPRODUTO & DESIGN
14 mai.

How to create a Figma plugin using Claude Code (without knowing JavaScript)

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.

The problem that brought me here

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?

The barrier that no longer exists

Before AI, the journey would be something like this:

  • – Learn JavaScript, a long learning journey – around a few weeks;
  • – Study the Figma Plugin API, something that would take a few days;
  • – Set up TypeScript, webpack, build tools, hours of frustration regarding all the necessary steps;
  • – Write the code, a journey of several more weeks;
  • – Debug, a task fueled by lots of coffee and long hours;

I gave up on this journey at least three times in the last two years. With Claude Code, the journey became different:

  • – Describe what I want in plain language;
  • – Claude Code generates the complete structure;
  • – Test in Figma Desktop Iterate with Claude: “adjust this, change that” (as many times as you want);
  • – Publish – final step when satisfied;

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.

Anatomy of a Figma plugin

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.

The process: from prompt to plugin

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:

  • – The configured manifest.json;
  • – The code.ts with all the validation logic;
  • – The ui.html with the error list and click interaction;
  • – The correct tsconfig.json and package.json.

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.

A snippet of the generated code

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.

Plugin ideas that any designer can create

If you’re thinking “cool, but what would I create?”, here are some ideas that occurred to me during the process:

  • Design Lint: validates colors, fonts, and spacing against DS tokens (what I did);
  • Auto Namer: automatically renames layers following the team’s convention. No more “Frame 247”;
  • Token Sync: imports tokens from a JSON file and automatically creates variables in Figma;
  • A11y Checker: checks color contrast and minimum font size. WCAG in Figma;
  • Spec Export: generates a specs document in Markdown from the selection. Handoff without Notion;
  • Icon Inserter: searches and inserts DS icons directly on the canvas, without having to open the library.

Each of these can be created in one afternoon with Claude Code. And each one solves a real problem we face every day.

Advanced applications: when creativity meets AI

Plugins don’t need to be just simple utilities. With AI, the possibilities expand:

  • Plugin + External API: connects Figma to any service. Pulls real data from an API, populates mockups with real content.
  • Plugin + Generative AI: generates copy variations, suggests color palettes based on references, creates contextual content;
  • Plugin + Design Tokens: bidirectional synchronization between tokens in code and variables in Figma. The DS always updated;
  • Plugin + Analytics: measures which DS components are being used most, identifies adoption patterns;
  • Plugin + Figma MCP: agents that edit the design for you. Figma as a programmable canvas.

What I learned in the process

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.

For those who want to start

If you’ve never used Claude Code, the simplest path:

  • – Install Claude Code (as a VS Code, Cursor extension, or a CLI in the terminal);
  • – Open an empty project;
  • – Describe the plugin you want to create, in plain language;
  • – Test in Figma Desktop;
  • – Iterate until it’s good.

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.

Compartilhe:
Tiago Penha

Tiago Penha

Staff Designer no iFood, onde lidera estratégia de IA para o Chapter Design. Trabalha na interseção entre design systems, frontend e inteligência artificial.

Construa o futuro no iFood

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 CarreirasArrow Right