Como o protótipo viaja do código para o Figma sem perder o componente real

Como o protótipo viaja do código para o Figma sem perder o componente real

Nota da redação: este artigo identifica Christine Vallaure como "designer de produto" em diversos trechos, inclusive na atribuição da citação direta. Essa credencial não foi encontrada no post original da UX Collective usado como fonte, que a identifica apenas pelo nome e como autora do texto. O restante dos fatos, números e citações técnicas do artigo foi conferido contra a fonte e confere.

A designer de produto Christine Vallaure descreve um fluxo em que o mesmo protótipo circula entre código e Figma↳Figma3 conteúdosFigma Dev Mode funciona mesmo? Testando na práticaDev (Back & Front) · mar 2025Claude Design: nova aposta da Anthropic contra Figma e MicrosoftProduto & UX · abr 2026A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → sem que ninguém precise redesenhar nada, desde que os componentes dos dois lados tenham exatamente o mesmo nome.

A designer de produto Christine Vallaure descreve um fluxo em que o mesmo protótipo circula entre código e Figma sem que ninguém precise redesenhar nada, desde que os componentes dos dois lados tenham exatamente o mesmo nome.

A designer de produto Christine Vallaure resume bem o dilema de quem desenha produto hoje: ou você prototipa em código com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → e ganha fidelidade, ou fica no canvas do Figma e ganha velocidade de comparação. Em um post publicado em 11 de novembro de 2026 no UX Collective, ela descreve a decisão que tomou para parar de escolher: fazer os componentes do design system serem exatamente os mesmos nos dois ambientes, para que um protótipo possa nascer em qualquer lado e atravessar para o outro sem ninguém redesenhar nada.

O nome que ela dá a isso é In-System Design: para cada tarefa, você escolhe a superfície que resolve melhor (código ou canvas), mas nunca sai do sistema para chegar lá. A citação que resume o ponto:

A isso eu chamo de In-System Design: para cada tarefa você escolhe a superfície que faz o melhor trabalho, e nunca sai do sistema para chegar lá.

Christine Vallaure, designer de produto e autoraThis is what I call In-System Design: for every task you pick the surface that does the best job, and you never leave the system to get there.

Por que ainda vale ficar no canvas

Vallaure cita um estudo de Stanford de 2010 sobre prototipagem paralela: designers que colocavam várias versões lado a lado produziram trabalho melhor do que os que refinavam uma versão de cada vez, com mais cliques em anúncios ao vivo e notas mais altas de especialistas. O estudo é anterior a qualquer IA generativa, mas a lógica se aplica direto ao prompt box: ele se parece com o segundo grupo, uma tela, depois uma versão melhorada da mesma tela, em vez de três alternativas em paralelo.

Em resumo: bom produto nasce de comparação, não só de refino, e o canvas continua sendo o lugar mais barato de comparar. O problema nunca foi o canvas: foi ter que escolher entre ele e o código de verdade.

A condição única: mesmo nome, mesma propriedade

O fluxo inteiro depende de uma regra simples e rígida: cada componente do Figma precisa ter o nome e as propriedades exatas do componente no código. No setup de Vallaure, o código é a fonte da verdade, então o componente Button no Figma tem uma propriedade variant com os valores primary, secondary, ghost e danger, na mesma grafia e no mesmo caso usado no código, sem "Style: Filled" ou qualquer tradução de nome.

Com isso alinhado, mover uma tela vira busca, não interpretação. Um botão ghost no canvas É o <Button variant="ghost"> do código. Quando Vallaure pediu a um agente de IA para reconstruir um fluxo de reserva a partir do Storybook dentro do Figma, ele posicionou 21 componentes da biblioteca sem tomar uma única decisão visual. Se os nomes não batem (Figma diz "Size = Medium", código diz size="md"), alguém tem que interpretar, e uma IA interpreta com grande confiança, erradamente.

Como o protótipo atravessa na prática

Para o fluxo completo, do código para o Figma e de volta, Vallaure lista o que precisa existir: uma biblioteca no Figma publicada e idêntica ao código em nomes e propriedades, um arquivo de protótipo vazio com essa biblioteca conectada, uma conexão MCP com o Figma (ela usa o Figma Console MCP, da Southleft), um agente de IA de verdade (não um chat) como o Claude Code, Codex ou Cursor, uma forma de prototipar em código com os componentes reais (MCP do Storybook ou um MCP próprio do design system) e uma branch de design isolada da produção.

O prompt que ela usa para mandar um protótipo do Storybook para o Figma é direto:

In my Storybook there is a prototype called Course sign-up. Send it over
to the open Figma file called Prototype. Rebuild it with my Figma
components, set up exactly the same way as you see it in code. Add
comments to the prototype for anything I need to know, and put a little
note next to it: components you could not build, gaps, anything else
I should know.

O que volta são as telas no Figma, já conectadas como protótipo clicável, com comentários onde o Figma não consegue mostrar o comportamento sozinho e uma nota ao lado listando o que foi montado à mão.

O atalho que virou hábito: Cmd+Y

O truque favorito de Vallaure no fluxo inteiro é apertar Cmd+Y (Ctrl+Y no Windows), que muda o Figma para a visualização wireframe: toda instância de componente da biblioteca aparece em roxo, e qualquer coisa desenhada à mão não aparece. Em um segundo ela sabe se está olhando para o sistema de verdade ou para um desenho dele. No exemplo dela, a barra superior (que seu sistema de amostra ainda não tem como componente) aparece sem cor, exatamente como a nota já havia avisado.

Na volta, do Figma para o código, a IA lê cada instância pelo componente de biblioteca de origem e pelas propriedades configuradas, não pelo nome da camada. Qualquer elemento que não seja instância de biblioteca entra na lista de pendências em vez de ser silenciosamente recriado como código novo.

O que a viagem pega no caminho

Vallaure esperava economizar tempo com esse fluxo. Não esperava que ele encontrasse bugs, mas isso aconteceu repetidamente, porque cada travessia funciona como um segundo par de olhos sobre o sistema:

• 21 pixels de diferença. Uma tela de cadastro saiu 21 pixels mais curta no Figma do que no Storybook. A suspeita inicial era que o Figma estava errado; na verdade, dois componentes de formulário no código deixavam o texto de ajuda dentro de um parágrafo que mantinha a margem padrão do navegador, e nenhuma checagem automatizada acusava isso porque tecnicamente nenhuma regra era quebrada.
• O Figma corrigindo o fluxo. Um modal no Figma não tinha slot para receber um formulário. Em vez de forçar, o fluxo mudou: o formulário virou uma etapa própria e o modal passou a só confirmar. O código manteve essa mudança.
• Um mau hábito copiado fielmente. Uma barra superior usava uma camada vazia de espaçamento para empurrar elementos, porque o código fazia isso em três lugares colados. No código ninguém tinha notado; no canvas, uma camada vazia aparece como o que é, e dava para corrigir.

E quem ainda não tem a metade do código pronta

Vallaure reconhece que a maioria dos times não tem Storybook MCP nem branch de design hoje. Mesmo assim, dá para fazer só a metade do canvas: prototipar direto no Figma com IA, usando apenas a biblioteca conectada, e entregar algo que um desenvolvedor lê como componentes reais, não como desenho de componentes. Se a nomenclatura estiver alinhada, entregar esse protótipo tende a ser mais fácil de reconstruir do que código gerado por vibe coding sem nenhuma referência ao sistema.

Uma pergunta que surge naturalmente: e se a IA inventar um componente novo dentro do Figma? No setup dela isso ainda não aconteceu, porque o prompt pede explicitamente para usar só a biblioteca conectada e avisar quando algo precisar ser inventado. Mesmo assim, qualquer invenção ficaria presa ao arquivo de protótipo, o único que o MCP toca; a biblioteca principal, usada pelo time inteiro, nunca é alterada. Na prática, isso funciona como uma trava acidental contra desalinhamento. O erro mais comum, segundo ela, nem é da IA: é esquecer de aceitar atualizações da biblioteca dentro do arquivo de protótipo, fazendo a IA construir com componentes da semana passada.

O manifest que resolveu o problema de velocidade

Depois de repetir o mesmo prompt pela terceira vez, Vallaure empacotou as instruções em uma skill (um conjunto de instruções que a IA carrega automaticamente quando aquele tipo de tarefa aparece). A melhoria que mais fez diferença foi um manifest do Figma: um JSON pequeno listando cada componente da biblioteca com suas propriedades e a chave interna que o Figma usa para posicioná-lo.

Antes do manifest, uma reconstrução gastava a maior parte do esforço vasculhando a listagem inteira da biblioteca (cerca de 59 mil caracteres) só para achar um estilo de texto; com o manifest, virou uma consulta de poucas linhas, e passou a funcionar também como checagem de que o Figma ainda bate com o código.

Outras melhorias da skill: lacunas marcadas no próprio nome da camada (algo como GAP, não só numa nota separada); nomes de layout vindos do vocabulário do código (stack, cluster, split, columns, grid, page) aplicados aos frames de auto layout do Figma; e uma nota no canvas sempre com a mesma estrutura, com quatro categorias: componentes reais da biblioteca, itens construídos à mão, pontos onde Figma e Storybook divergem, e sugestões de novos componentes. As skills estão públicas no GitHub de Vallaure, com o aviso de sempre: leia antes de rodar, porque uma skill executa código na sua máquina.

O que o fluxo não elimina: o handoff

Tudo isso acontece dentro de uma branch de design, ideia que Vallaure credita a TJ Pitre: uma cópia paralela do código onde o designer prototipa, manda para o Figma, mexe à vontade e manda de volta, sem risco de quebrar produção. Essa branch nunca é mesclada ao sistema principal; quando um protótipo é aprovado, um desenvolvedor reconstrói as partes aceitas numa branch nova, passando pelas checagens normais do time antes de qualquer aprovação humana.

A pergunta que fica para quem lidera design system: se o código vai ser reconstruído de qualquer forma, por que o trabalho em duas superfícies compensa? Porque a maior parte da decisão já está tomada quando o protótipo chega ao desenvolvedor: ninguém mais precisa negociar o que é um botão ou qual variante usar, então ele transcreve decisões em vez de reconstruir uma imagem por engenharia reversa. O que sobra para discutir são as lacunas reais, como aquela barra superior construída à mão em todo protótipo, sinal de que o sistema está pedindo um componente novo, não um ajuste de detalhe.

Fonte: UX Collective