Thiago Xikota
Voltar para o blog
Por Thiago Xikota4 min de leitura

Figma é briefing. Código é protótipo.

Quando uma experiência depende de estado, latência, streaming, erro e confiança, o protótipo precisa rodar. Figma mostra intenção, código revela comportamento.

Figma continua sendo uma das melhores ferramentas para pensar visualmente.

Mas tem um limite que designers fingem não ver: Figma não prova comportamento.

Ele mostra intenção. Mostra hierarquia. Mostra ritmo visual. Mostra direção. Mas quando o produto depende de loading, streaming, erro, latência, permissão, undo, foco por teclado, dados reais ou resposta de modelo, uma tela estática vira uma promessa.

Promessa não é protótipo.

O protótipo precisa sentir o problema

Em produtos com IA, a experiência raramente está só na tela final. Ela está no intervalo.

O que acontece enquanto o modelo pensa? O usuário entende o que está sendo usado como fonte? Pode cancelar? Pode corrigir? O sistema assume demais? O erro tem recuperação? A resposta chega em blocos? O layout aguenta conteúdo real? O foco vai para onde depois de uma ação?

Essas perguntas não aparecem em um mockup bonito.

Elas aparecem quando você roda a experiência.

Figma como briefing visual

O melhor uso do Figma nesse fluxo é como briefing visual.

Ele define:

  • composição;
  • densidade;
  • hierarquia;
  • componentes esperados;
  • direção de marca;
  • relação entre telas;
  • exemplos do que deve ou não deve acontecer.

Depois disso, o código precisa assumir.

Não porque o designer virou dev. Mas porque o designer precisa sentir a decisão em um ambiente mais próximo do produto.

Código como lugar de descoberta

Quando você monta um protótipo em React, Next, Framer Motion ou qualquer stack real, o produto começa a responder perguntas que o Figma escondia.

O card quebra com texto longo. O loading parece ansioso. A animação atrapalha quem usa teclado. O componente que parecia simples precisa de três estados extras. A API demora mais que o esperado. O "Thinking..." fica infantil. O toast desaparece antes do usuário entender.

Isso não é falha do código. É descoberta de design.

O problema é que muitos times só descobrem isso depois do handoff.

Um fluxo melhor

Um fluxo de design com IA pode ser pequeno e rigoroso:

  1. Desenhe a intenção no Figma.
  2. Peça ao agente para auditar componentes, tokens e padrões existentes.
  3. Transforme a tela em um brief de comportamento.
  4. Implemente o menor protótipo que prova a interação.
  5. Teste desktop, mobile, teclado, foco e movimento reduzido.
  6. Volte ao design com o que o código revelou.

O ponto não é publicar código de designer em produção sem revisão. O ponto é chegar na conversa com engenharia carregando uma evidência melhor.

Um protótipo que roda muda a discussão. O time deixa de debater uma imagem e passa a debater comportamento.

O novo handoff

O handoff clássico dizia: "aqui está a tela".

O handoff com IA deveria dizer:

  • aqui está a intenção visual;
  • aqui está o comportamento esperado;
  • aqui estão os estados obrigatórios;
  • aqui está o protótipo rodando;
  • aqui estão os pontos que quebraram;
  • aqui está o que precisa de revisão de engenharia;
  • aqui está o que eu já verifiquei.

Isso é mais trabalho no começo. Mas evita uma transferência ruim de ambiguidade.

Acessibilidade entra mais cedo

Outra vantagem de prototipar em código é que acessibilidade deixa de ser checklist tardio.

Você consegue testar foco, ordem de tab, semântica, movimento reduzido e mensagens de erro no fluxo real. Consegue perceber se a interface só funciona para mouse. Consegue sentir se a animação ajuda ou distrai. Consegue validar se a pessoa entende o estado do sistema sem depender de cor.

No Figma, tudo isso pode ser anotado.

No código, pode ser testado.

O que muda para o designer

O designer não precisa saber escrever todo o código de memória. Mas precisa aprender a ler o suficiente para orientar a IA.

Precisa saber quando pedir componente em vez de tela. Estado em vez de visual. Token em vez de hex. Semântica em vez de div. Verificação em vez de "parece bom".

Essa alfabetização muda a qualidade do pedido.

E muda a qualidade da resposta.

O futuro não é menos Figma

Não acho que isso diminui Figma. Pelo contrário. Um bom frame vira um brief melhor quando o designer entende como ele será executado.

O que acaba é a ideia de que uma tela bonita encerra a decisão.

Em produtos com IA, a experiência vive nos estados intermediários. Vive no tempo de espera. Vive na explicação. Vive na recuperação. Vive no controle que o usuário tem quando o modelo erra.

Figma desenha a promessa.

Código testa se ela aguenta.

Referências

FigmaClaude CodePrototipagemIAFront-end