by No meu post anterior, testei o recurso Code to Canvas do Figma – enviando uma UI rodando do navegador para o Figma como camadas editáveis. No final, mencionei que a direção oposta, Figma para código, parecia mais útil da perspectiva de um desenvolvedor.
Então meu colega Gabriel Quaresma e eu decidimos realmente testá-la. Executamos experimentos separados, encontramos diferentes obstáculos, e agora posso te contar como esse fluxo de trabalho realmente se parece quando você deixa os scripts de demonstração para trás.
Meu experimento: aplicando mudanças de design a um projeto existente
Eu tinha um projeto de dashboard hospitalar – React, Tailwind, lucide-react para ícones – com o código dividido em componentes: Sidebar, Header, StatsCards, RecentPatients, e assim por diante. Uma base de código normal, não um projeto de brinquedo em arquivo único.
Mudei o design da sidebar no Figma – cores, layout, itens – e então pedi ao Claude Code para ler o frame específico do Figma e aplicar essas mudanças ao componente Sidebar.jsx existente.
Funcionou. O Claude leu o wireframe através do MCP, entendeu o que mudou, e atualizou o componente. Mas aqui está o que aprendi chegando lá:
Você deve ser específico. Referencie o nó exato do wireframe. Se você passa a URL do arquivo Figma e vagamente pede mudanças, ou não funciona ou te dá uma saída inconsistente. Aponte para o nó exato, diga qual componente atualizar, e ele entrega.
Isso faz sentido se você pensar sobre isso. Você não diria a um desenvolvedor humano “olha o arquivo Figma e descubra.” Você diria “a sidebar mudou, aqui está o frame, atualize o componente da sidebar.” A mesma coisa aqui.
Experimentos do Quaresma: começando do zero
Quaresma tomou uma abordagem diferente. Ele pegou designs do Stitch do Google – uma ferramenta de design com IA – copiou-os para o Figma, e pediu ao Claude para implementá-los do zero.
Experimento 1: HTML, CSS e JavaScript
Ele referenciou um wireframe do Figma e pediu ao Claude para implementá-lo usando HTML, CSS e JavaScript. O Claude colocou tudo em um único arquivo index.html. Estilos, marcação, scripts – tudo em um lugar.
A saída combinou exatamente com o design do Figma. Mas não seguiu nenhuma boa prática estrutural. Nenhum arquivo separado, nenhum módulo. O Claude fez o mínimo para satisfazer a solicitação.
O que, se você pensar sobre isso, é exatamente o que foi pedido. “Implemente isso usando HTML, CSS e JavaScript” não diz “organize em arquivos separados com um sistema de build.” A ferramenta é literal. Ela se preocupa em acertar a saída visual, não sobre como você organizaria um projeto real.
Experimento 2: React e Tailwind
Para o segundo experimento, Quaresma pediu ao Claude para implementar um wireframe diferente usando React e Tailwind CSS v4. Desta vez o Claude estruturou um projeto Vite completo, instalou dependências, configurou o plugin Tailwind – toda a configuração.
Mas todo o código da UI foi para um único arquivo App.jsx. Mais de 170 linhas, tudo inline. Criou componentes auxiliares como ProductCard e ProductRow, mas eles viviam no mesmo arquivo. Um projeto real dividiria esses em arquivos separados, talvez adicionaria um roteador. O Claude não pensou nisso porque ninguém pediu para ele fazer.
O design ainda combinou com o wireframe do Figma com precisão. Essa parte é consistente – a tradução visual é sólida.
O problema do viewport móvel
O wireframe que Quaresma usou para o experimento React era um design móvel – um frame de 390px de largura para uma loja de cerâmica chamada “Clayful.” O Claude gerou exatamente isso: um container com largura móvel, centralizado na página, com um max-w-[390px] fixo.
Não tornou responsivo. Você não pode dar ao Claude um wireframe móvel e esperar que ele descubra que o layout também deveria funcionar em desktop. Ele reproduziu o que viu: uma tela móvel. Se você quer comportamento responsivo, precisa fornecer wireframes para múltiplos breakpoints ou dizer isso explicitamente.
Esse nos pegou desprevenidos no início, mas faz sentido. O Claude traduz o que está no design, não o que você quis dizer que o design implicava.
O que aprendemos
Especificidade é tudo. Continuo voltando a isso. O nó exato do Figma, o componente exato para atualizar, as restrições exatas com que você se importa. Solicitações vagas geram resultados vagos.
Por padrão faz o esforço mínimo. Peça HTML, você recebe um arquivo. Peça React, você recebe um componente. Se você quer arquivos separados, layouts responsivos, ou convenções específicas – diga isso. O Claude não assumirá boas práticas por conta própria. Isso não é necessariamente ruim. Prefiro ter uma ferramenta que faz o que peço do que uma que adivinha o que quero e erra.
A tradução visual é precisa. Ambos os experimentos do Quaresma produziram saída que combinava com os designs do Figma. Designers e PMs que se importam com fidelidade de pixel vão apreciar isso. A lacuna entre “o que está no Figma” e “o que renderiza no navegador” foi pequena em todo teste que executamos.
Projetos existentes funcionam melhor que começar do zero. Quando o Claude já tem uma base de código para referenciar – como arquivos são organizados, como componentes são nomeados – ele segue esses padrões. Meu experimento do dashboard hospitalar foi mais suave que os do Quaresma começando do zero porque o Claude tinha contexto. Se puder, comece com um projeto que já tem estrutura, e deixe o Claude preencher as peças.
Bibliotecas de design ainda são um problema. Quaresma tentou alguns experimentos onde o design do Figma usava uma biblioteca de componentes com seu próprio sistema de design. Os resultados não foram bons. Mapear componentes do Figma para os componentes certos da biblioteca requer contexto que o MCP ainda não fornece bem. Isso provavelmente merece seu próprio post de acompanhamento.
O problema da cota
Aqui está o que realmente torna experimentar frustrante: a cota do MCP do Figma no plano inicial é cerca de 6 solicitações por mês. Cada chamada get_design_context é uma solicitação. Cada screenshot é outra. Você queima sua cota em dois experimentos, talvez três se for cuidadoso.
Para um recurso que deveria mudar como designers e desenvolvedores trabalham juntos, isso é uma barreira. Você não pode iterar, não pode tentar abordagens diferentes, não pode construir intuição para a ferramenta – porque fica sem chamadas antes de aprender qualquer coisa. Se o Figma quer que as pessoas realmente adotem isso, o nível gratuito precisa ter espaço para experimentar.
Onde isso nos deixa
Figma para código funciona. Quanto melhores suas instruções, melhor a saída. É isso. Sem mistério.
Penso nisso como trabalhar com um colega muito capaz mas muito literal. Eles vão construir exatamente o que o wireframe mostra. Se você quer arquitetura, responsividade, ou convenções – você tem que especificar.
Para aplicar mudanças de design a uma base de código existente, eu usaria isso hoje. Para gerar projetos inteiros do zero, te dá um ponto de partida fiel que você precisará reorganizar.
O MCP do Figma está no início. A cota, a lacuna da biblioteca de design, a estranheza ocasional – essas coisas vão melhorar. Mas o loop básico já funciona: o designer muda um frame, você aponta o Claude para ele, o Claude atualiza o código. Só isso já me economiza tempo.
Obrigado pela leitura!
We want to work with you. Check out our Services page!
