Workflow Lab: como usar agentes para alternar entre design e código

Bem-vindo ao Workflow Lab, onde apresentamos um exemplo de fluxo de trabalho usando produtos e ferramentas Figma.

A equipe de engenharia da Radicle, um app fictício de aprendizado de STEM, acelera cada vez mais. Tarefas que antes levavam semanas agora levam dias, ou até mesmo horas. No entanto, toda essa velocidade não leva a equipe muito longe: muitas vezes, o código gerado por IA se desvia das especificações do projeto. Como base para o seu trabalho, o agente de programação recebe da equipe capturas de tela e tíquetes de desenvolvimento. No entanto, isso não é suficiente para obter os resultados corretos e a equipe perde tempo com retrabalhos.

E se a primeira passagem da IA já estivesse quase pronta para produção? Com mais contexto de design para trabalhar (como componentes aprovados e tokens documentados no Figma), um agente de programação pode gerar resultados coerentes com a intenção em menos prompts. Neste exemplo de fluxo de trabalho, um desenvolvedor da Radicle usa ferramentas de desenvolvimento do Figma para dar ao seu agente de programação um contexto melhor, para que ele possa gerar um código melhor. Acompanhe para ver como o desenvolvedor mantém o design e o código de um novo recurso alinhados, desde o primeiro wireframe até a revisão final.

O problema

A equipe da Radicle quer atualizar a caixa de entrada usada pelos alunos para enviar mensagens para instrutores e outros alunos. Primeiro, eles planejam adicionar um novo fluxo de atualização em massa, que terá três superfícies: uma barra de ferramentas, um modal e uma notificação temporária (toast). Na barra de ferramentas, o usuário pode selecionar, excluir ou marcar suas mensagens como não lidas. O modal solicita a confirmação ou cancelamento da ação. Por fim, a notificação temporária mostra se a ação foi executada e oferece a opção de desfazê-la.

O designer da equipe cria as telas no Figma Design e o desenvolvedor do projeto envia esses designs ao agente de programação. O código é gerado rapidamente, mas a UI está incorreta. Os ícones são diferentes, o espaçamento do modal é desigual e a notificação temporária ficou sem estado de falha. O desenvolvedor poderia passar toda a tarde refazendo esse trabalho. Em vez disso, ele dá um passo atrás e recomeça o processo usando as ferramentas de desenvolvimento do Figma.

Planejamento antes da criação de prompts

Antes de escrever qualquer código, o desenvolvedor descreve o comportamento pretendido das telas, estados e transições que definem o novo fluxo de atualização em massa. Ele envia ao agente a descrição, o PRD e o código dos componentes usados na caixa de entrada atual. Em seguida, usando a ferramenta generate_diagram com o servidor MCP do Figma, o desenvolvedor cria um diagrama editável no FigJam que ilustra o fluxo em três superfícies:

• A opção “selecionar tudo” da barra de ferramentas seleciona todas as mensagens
• A opção “excluir” abre o modal de confirmação
• O botão “desfazer” da notificação temporária muda o painel para seu estado anterior

O diagrama fornece contexto adicional para orientar o agente, além de permitir que a equipe interfira antes do início do desenvolvimento. O desenvolvedor compartilha o FigJam com seu colega de design e um líder de design systems, que inserem seu feedback diretamente no diagrama, em vez de em uma conversa do Slack.

Fornecer ao agente um sistema como base da construção

Depois que todos aprovam, o desenvolvedor envia o diagrama do FigJam ao agente de programação por meio do servidor MCP da Figma. Por sua vez, o servidor concede ao agente acesso aos componentes, tokens e layouts no design system da Radicle.

Se o desenvolvedor tivesse apenas uma captura de tela para trabalhar, teria de procurar o componente certo na base de código ou esclarecer os detalhes com o designer: se 12 px é o token de espaçamento correto, se o botão é o secundário que já existe no repositório, ou se o modal é um novo padrão ou já foi lançado pela equipe. Em vez disso, todas essas respostas estão no arquivo por meio do servidor MCP do Figma, oferecendo ao agente todo o contexto de design necessário.

Conectar o design system ao código

Saber qual componente usar e saber como ele é construído são duas coisas diferentes. As informações para construção são fornecidas pelo Code Connect configurado pelo líder de design systems da Radicle. Começando no Figma, ele conecta a biblioteca ao repositório GitHub da equipe para que cada componente aponte para o arquivo que o implementa. Em seguida, ele grava arquivos de modelo para componentes como botões, ícones e modais na base de código, mapeando propriedades do Figma para propriedades do código.

Agora, o desenvolvedor envia um prompt ao agente com suas seleções no Figma como base para a construção e o Code Connect identifica os componentes a serem importados. Em vez de gastar tempo e créditos escrevendo novo código, o agente começa a partir do plano de implementação já existente.

Mas o estado de seleção da atualização em massa é “novo”, ou seja, é a única parte que o Code Connect não consegue mapear. Antes de construir essa parte do zero, o desenvolvedor envia o prompt search_design_system para que o agente procure um componente de seleção existente nas bibliotecas do Figma da equipe. O agente identifica um componente semelhante de um recurso lançado pela equipe há alguns meses. Assim, o agente encontra esse componente na base de código e o adapta para o fluxo de atualização em massa. O resultado é alinhado à marca e consistente com o restante do app da Radicle e o agente não precisa inventar um padrão já construído pela equipe.

Evitar desvios antes que aconteçam

O desenvolvedor passa a codificar o modal de confirmação. Durante esse trabalho, a equipe de design faz duas alterações: o modal precisa ter uma cor mais escura que a da marca e o raio do canto do botão mudou. O designer publica a atualização na biblioteca da Radicle e sinaliza as alterações em um tíquete. Em vez de fazer as alterações manualmente, o desenvolvedor pede ao agente para verificar se há desvios.

Ele envia o prompt get_variable_defs ao agente de programação, que retorna as variáveis usadas no modal, que agora refletem as alterações do designer. Ao comparar esses valores com os tokens no código, o agente encontra imediatamente as duas incompatibilidades e atualiza o modal.

O caminho para a produção

O desenvolvedor terminou a barra de ferramentas, os estados de seleção de mensagens e o modal de confirmação, todos usando os componentes mantidos pela equipe. Restou apenas a notificação temporária, que foi criada durante a construção e até agora só existe em código. Ela ainda precisa de um estado de falha. O desenvolvedor envia o prompt use_figma para colocar a notificação temporária na tela de trabalho como camadas editáveis. O designer adiciona o estado ausente com uma ação “tentar novamente”. Em seguida, o líder de design systems publica o novo componente e o mapeia para o código com o Code Connect. Agora, a notificação temporária funciona como todo o resto na biblioteca da Radicle.

A partir desse ponto, é como qualquer outro lançamento. O desenvolvedor abre uma solicitação de pull e a diferença está concentrada na lógica do recurso. Os engenheiros revisam o código e o designer verifica uma prévia da construção.

O servidor MCP do Figma e o Code Connect concedem ao agente acesso ao mesmo sistema em que todos trabalham. Dessa forma, a equipe mantém o foco nos detalhes que definem a experiência do usuário, em vez de ajustar o código gerado por IA. Mais tempo para construir significa um trabalho melhor, e não apenas mais rápido.

Comece a dar um melhor contexto aos agentes instalando o servidor MCP do Figma e conectando-o ao agente de programação de sua escolha. Configure o Code Connect para os componentes que sua equipe mais reutiliza.

Leia todas as nossas postagens de blog da série Workflow Lab para explorar outras maneiras de trabalhar no Figma.