Pare de Desenhar no Figma

Seu arquivo do Figma é uma fotografia estática de um produto que não existe. Quando o engenheiro entrega, ele já está errado. As fontes renderizam diferente, os breakpoints que você ignorou aparecem, o empty state que você esqueceu surge, e o hover que você rabiscou num comentário é interpretado por alguém que não é você. A solução não são plugins melhores de Figma. A solução é parar de usar o Figma como ferramenta de design e começar a usar a codebase.

Isto não é um ataque ao Figma. Ele ainda vence em trabalho de sistemas, exploração de marca e diagramas no FigJam. A tese é mais estreita e mais dura. Em 2026, design de produto acontece em código. v0, Cursor, Lovable e o registry da Vercel UI substituíram a prancheta como o lugar onde as interfaces realmente são desenhadas. Designers que ainda entregam frames de Figma pixel-perfect para engenheiros "implementarem" estão fazendo dois trabalhos na metade da velocidade.

O que realmente mudou

O Figma foi construído para uma era em que a produção era o gargalo. Em 2018, gerar um componente React funcional levava três dias de um engenheiro, e um designer conseguia soltar vinte frames hi-fi na mesma janela. Entregar pranchetas planas como deliverable era a jogada racional. A prancheta era a parte mais rápida do pipeline.

Essa conta se inverteu em 2026. O v0 transforma uma frase em um componente funcional em trinta segundos. O Cursor edita um repositório real com um diff real. O Lovable levanta um app implantável a partir de um único prompt. A prancheta agora é a parte mais lenta do pipeline, não a mais rápida, e a distância aumenta a cada trimestre. A análise mais profunda da mudança no nível do artefato está em a morte do mockup. Este texto é sobre a ferramenta que produz o artefato.

O frame plano não ficou pior. A bancada ficou melhor.

Onde o Figma ainda se paga

Seja honesto. O Figma é excelente em quatro trabalhos, e fingir o contrário faz o resto do argumento ser descartado.

O Figma ainda vence em exploração de identidade de marca, onde logos, estudos tipográficos e sistemas de cor vivem antes de existir qualquer codebase. Vence em inventários de design system, o arquivo único que lista cada token, variante e estado com um modelo multiplayer que nada mais replica. Vence em diagramas no FigJam e alinhamento de equipe, o whiteboard e o mapeamento de jornada em que a superfície é a conversa. E ainda vence para o designer que genuinamente não consegue ler código, um perfil mais raro em 2026 do que a indústria finge, mas ainda real.

Todo o resto, toda superfície de produto que chega a um usuário real, pertence ao código.

As cinco diferenças

Desenhar no Figma e desenhar em código não são o mesmo trabalho em velocidades diferentes. São trabalhos diferentes.

Fidelidade. Um frame do Figma aproxima a tipografia, ignora o hover, finge o scroll e renderiza fontes que o navegador não carregaria do mesmo jeito. Uma superfície em código usa a fonte real, o componente de botão real, o breakpoint real, o focus ring real. A distância entre aproximação e realidade já foi aceitável. Num produto em que os estados de carregamento, vazio e conteúdo longo são metade do design, não é mais.

Velocidade. O ciclo do Figma é editar o frame, comentar para o engenheiro, esperar, revisar o build, comentar de novo, esperar de novo. O ciclo em código é editar, recarregar, ver. O primeiro roda em dias, o segundo em segundos. A velocidade de iteração decide quantas ideias o time consegue testar antes do lançamento.

Modelo de colaboração. Comentários no Figma e comentários em PR são superfícies diferentes. Comentários no Figma são designer para stakeholder e designer para engenheiro como especificação. Comentários em PR são designer e engenheiro como pares em um único artefato. O segundo modelo é o que as equipes de design engineering praticam, e é estruturalmente mais rápido.

O handoff desaparece. O handoff é o momento mais caro do pipeline tradicional. Desenhar em código o elimina. Não há etapa de tradução, porque o design é a implementação.

Os edge cases se revelam imediatamente. Vazio, carregando, conteúdo longo, mobile, erro, rede lenta. No Figma, eles existem se o designer lembrou de desenhá-los. Em código, existem lembrando ou não, porque o componente precisa lidar com eles para renderizar. O código obriga à honestidade.

v0, Cursor, Lovable e Vercel UI são a nova superfície de design

O novo ambiente de design não é uma ferramenta, é uma stack atingindo massa crítica de uma só vez. Cada uma dessas ferramentas cuida de uma camada do que o Figma fazia sozinho.

v0, da Vercel, transforma um prompt em um componente React e Tailwind funcional em cerca de trinta segundos. Faça um fork do resultado, itere por prompt ou à mão, entregue na codebase. O modelo de fork e iteração substitui o duplicar-e-ajustar do Figma, só que o duplicado é código de verdade.

Cursor é a superfície de design para product designers que sabem ler código. Abra o repositório real, veja a renderização real, edite um componente por prompt ou à mão, veja a mudança no navegador no mesmo minuto.

Lovable é a superfície do fundador e do designer solo. Um prompt para um app web funcional, depois iterar em cima da coisa rodando. O caminho mais rápido da intenção até uma URL no ar, sem arquivo de Figma.

Vercel UI e o registry do shadcn são a prateleira de componentes. Puxe um componente real, customize dentro da codebase, entregue. O shadcn entrega componentes como código que é seu, o que significa que o design system é editável na mesma superfície do design.

As ferramentas diferem na forma, mas compartilham a mesma ideia. A superfície em execução é o artefato. A prancheta é um rascunho, se é que existe. Para o padrão mais profundo de prática, veja vibe coding para designers e Claude Code para designers.

Como Linear, Stripe e Anthropic realmente operam

Os times que entregam a melhor UI de produto em 2026 compartilham o formato de workflow, e nenhum deles entrega Figma como deliverable final.

Linear trata a codebase como fonte da verdade. O time de design engineering entrega designs como pull requests contra o app em execução, não como frames de Figma. O design system da Stripe é construído e entregue a partir do código. O Figma existe como documentação a jusante do código, não como fonte a montante. Editar o sistema significa editar o código. A Anthropic desenha as superfícies de produto do Claude direto em componentes React e artifacts do Claude, com designers lendo e editando o app real a cada release.

O padrão se repete em toda equipe de produto que entrega em velocidade premium. Tokens a montante, código como canvas, IA como camada de produção, designers no diff. O pipeline de frames planos não é como nenhum deles trabalha, e a matemática já alcançou o resto da indústria.

Cinco perguntas antes de desenhar em código

Nem todo designer deve largar o Figma amanhã. O teste honesto são cinco perguntas. Se três ou mais respostas forem sim, desenhar em código é a superfície certa para o próximo projeto.

1. Você entrega o trabalho ou passa adiante? Se entrega, o código vence. Se passa adiante, o código ainda vence, mas a diferença cultural é maior.
2. Você consegue ler a codebase? Não escrever React de produção do zero, só ler componentes, entender props, reconhecer um design token e editar valores sem quebrar o build.
3. O design é uma especificação estática ou uma superfície interativa? Uma especificação pertence ao Figma. Uma superfície com hover, foco, scroll, motion e estados de borda pertence ao código.
4. O time tem um design system para estender? Uma biblioteca de componentes de verdade, mesmo uma base shadcn, deixa o design code-first duas ordens de magnitude mais rápido que o Figma.
5. A velocidade de iteração é seu gargalo? Se você está perdendo sprints no ciclo de handoff, o code-first mata o gargalo. Se está perdendo sprints em estratégia de marca, o code-first não faz nada. Resolva o problema certo.

Um time que acerta quatro de cinco vive em código. Um time que acerta duas de cinco ainda deve dividir o trabalho entre Figma e código, com o viés levemente inclinado para o código em cada projeto novo.

Antipadrões para largar

Quatro padrões matam mais UI de produto entregue do que qualquer escolha de ferramenta. Se um time faz qualquer um deles, a troca de ferramenta importa menos que a mudança de workflow.

A fantasia do Dev Mode como handoff. O designer entrega um arquivo do Figma cheio de marcações vermelhas. O engenheiro "usa o Dev Mode" para traduzir. Ambos fingem que a tradução é fiel. Nunca é. O Dev Mode é útil, mas é a mesma fantasia de handoff com embalagem nova. A solução real é fazer engenheiro e designer editarem o mesmo artefato, que é o que as superfícies em código permitem. Para a camada de conexão, veja o guia do Figma MCP.

O mock pixel-perfect que ignora fontes e breakpoints reais. Um frame de 1440px com Lorem Ipsum e uma fonte que o app em produção não carrega. O mock parece pixel-perfect, o produto entregue não se parece nada com ele, e todo mundo aprovou a mentira.

O design system que vive no Figma e diverge em silêncio do código. A biblioteca do Figma diz que o botão tem 12px de padding. O código diz 14px. Ninguém atualizou nenhum dos dois. Depois de seis meses, o arquivo do Figma é ficção. Uma fonte da verdade, em código, com o Figma como render a jusante.

O redesign de seis meses que sai como PDF. Um redesign principal entregue como um export de cem páginas do Figma, apresentado à diretoria, passado à engenharia para a "fase dois". A fase dois não acontece porque, quando a engenharia dimensiona a reconstrução, a empresa já mudou de estratégia duas vezes. O redesign que não foi entregue nunca existiu.

A auditoria de design code-first

Antes de o próximo projeto começar, faça a auditoria. Sete perguntas, dez minutos, respostas afiadas.

1. Qual é o deliverable, um frame ou uma superfície entregue? Se entregue, o deliverable é código. Pare de fingir que o frame é o produto.
2. Quem é dono do app em execução, e o designer está no diff? Se o designer não está no diff, conserte isso antes de trocar de ferramenta.
3. Onde vivem os tokens? Se a resposta é Figma, mova-os. O arquivo de tokens deve ser a fonte da verdade que o Figma lê, não o contrário. O detalhamento do workflow de design com IA cobre o caminho de upgrade.
4. Qual é o ciclo de iteração, em horas? Se passa de quatro horas da edição até a mudança entregue, o problema é o workflow, não o design.
5. Quais superfícies ainda são desenhadas em pranchetas planas e quais já migraram para código? Mapeie a divisão. A divisão deve pender para o código em cada nova iniciativa.
6. Em quais plugins o time se apoia para fingir fidelidade de handoff? Se a resposta é "muitos", veja os plugins de Figma que valem a pena manter e corte o resto.
7. O que o time entrega no próximo trimestre que prova que o workflow funciona? Não um slide, uma superfície no ar. Se a resposta é vaga, o workflow ainda não mudou de verdade.

Um workflow que sobrevive à auditoria entrega produto. Um workflow que reprova na auditoria entrega decks. A diferença se acumula a cada trimestre, e velocidade é a marca quando todas as outras variáveis são mais ou menos iguais.

FAQ

O Figma morreu?

Não. O Figma não morreu, e a tese não é "o Figma morreu". O Figma é excelente para identidade de marca, inventários de design system, diagramas no FigJam e apresentação para stakeholders. A tese é mais estreita. O Figma não é mais onde o design de produto acontece, porque a codebase é mais rápida, tem maior fidelidade e entrega o mesmo artefato que o usuário toca.

E os designers que não sabem ler código?

Esse designer deve aprender a ler código, não a escrevê-lo. Ler componentes, reconhecer tokens, editar valores e revisar um diff é uma habilidade de uma semana, não uma mudança de carreira. A IA cuida do trabalho pesado do código de produção em 2026. O designer traz composição, julgamento e gosto para a superfície em execução, o que vale mais, não menos, quando a camada de produção é barata.

Um time pequeno deve mesmo pular o Figma por completo?

Por completo, não. Um time pequeno ainda deve usar o Figma para exploração de marca, inventários de sistema e alinhamento de equipe. A mudança está nas superfícies de produto, onde v0, Cursor, Lovable ou o registry do shadcn superam uma prancheta em todas as métricas. A divisão honesta é marca e sistemas no Figma, superfícies de produto em código, e o viés em novas iniciativas pende para o código.

Fique do lado certo do workflow

A era do Figma como ferramenta de design foi certa por quinze anos e acabou. A codebase é o ambiente de design em 2026, e os times que entregam UI de produto em código estão cobrando mais, aprendendo mais rápido e ganhando briefings que os estúdios de deck de Figma costumavam dominar.

Se você quer uma UI de produto entregue em código, com designers no diff em vez de um deck de Figma jogado por cima do muro, contrate a Brainy. A Brainy entrega marca, engenharia de produto e o workflow de IA como um só projeto, não três. Os estúdios que ainda precificam o arquivo do Figma como deliverable final não estarão no briefing no próximo trimestre. Esteja no briefing.