Figma Make gera protótipo funcional com IA e joga a qualidade técnica para o lado do design
O código deixa de nascer só na engenharia. Entender o que muda no handoff (e onde recai a responsabilidade de quem desenha) vale mais que a demo bonita.
O problema que o Figma Make ataca não é novo: a distância entre a tela estática que o design entrega e o produto que o usuário toca. Por décadas essa ponte foi o handoff, o momento em que o designer passa o Figma para a engenharia e torce para que o resultado se pareça com o que imaginou. A página oficial do Figma Make resume a promessa em três verbos: "Prototype. Polish. Ship." Traduzindo o que isso significa para quem trabalha com produto no Brasil: o próprio designer passa a gerar código funcional a partir do design, 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 → no meio. E aí a conversa muda de lugar.
O que o Make faz, na prática
O Figma Make é uma ferramenta de geração assistida por IA que produz protótipos (e, segundo a Figma, cada vez mais coisas prontas para produção) a partir de um prompt somado ao contexto de design. A diferença em relação a um gerador genérico de código está justamente nesse contexto: o Make consome os design systems, bibliotecas de estilo, componentes e imagens que já existem no arquivo. Pela documentação da própria página, isso acontece via Make kits (que sincronizam pacotes npm, estilos de biblioteca e guidelines), anexos de frames do Figma, PDFs e outros arquivos.
O ponto técnico que importa: a Figma afirma que "tudo o que você constrói é code-backed e visualmente editável", ou seja, o resultado é código de verdade, e não um mockup interativo fingindo ser app. Você pode alternar entre editar no canvas e mexer no código. Há um Plan mode que estrutura a intenção antes de gerar (esclarecer o que se quer antes de sair produzindo), Point and edit para clicar num elemento e pedir mudança direto no preview, histórico de versões que rastreia cada edição (de IA ou manual) e até prompting por voz. Existe também uma versão em beta anunciada como "coming soon" para rodar o Make sobre o codebase local e converter designs em assets prontos para produção.
Ou seja: o Make não é só um brinquedo de protótipo. A intenção declarada é encurtar o caminho da ideia até a feature entregue.
Por que isso mexe com o handoff
O argumento de venda que a Figma escolheu destacar é velocidade. Vishal Kapoor, SVP de produto da Affirm, é citado na página dizendo que, em vez de uma ideia levar seis semanas para virar algo tangível, agora leva "apenas algumas horas". Brian Muehlenkamp, PM da Ticketmaster, diz que o Make "encurtou o caminho da ideia até a feature finalizada de um jeito que não consigo imaginar substituir".
Essas frases são depoimentos de fabricante, e vale lê-las como tal. Mas a mudança estrutural que elas apontam é real e merece atenção de quem desenha: quando o protótipo já sai como código que se parece com o produto final, o momento do handoff deixa de ser uma entrega limpa ("aqui está o layout, implemente") e vira uma zona cinzenta. O design chega mais perto do funcionando de verdade, e a engenharia recebe algo que já tem estrutura, comportamento e, potencialmente, dívida técnica embutida.
É aqui que o eixo da responsabilidade se desloca. Se o designer gera o código, o designer também gera as decisões que antes eram da engenharia: hierarquia de componentes, estados de erro, comportamento em telas pequenas, e (o ponto que mais me preocupa) acessibilidade.
Onde a qualidade técnica passa a recair sobre quem desenha
Gerar uma interface bonita e clicável com IA é fácil. Gerar uma interface que funciona para todo mundo é outra história, e a demo de marketing nunca mostra essa parte. Alguns riscos concretos que passam a ser problema de quem prototipa no Make:
- Acessibilidade: código gerado por IA tende a acertar o visual e errar o resto. Ordem de foco,
altem imagens, contraste que passa no WCAG, uso correto de roles e landmarks, navegação por teclado, rótulos em campos de formulário. Nada disso aparece num protótipo que "parece funcionar" no mouse. Se o Make virou parte da definição de pronto, a acessibilidade tem que entrar na mesma checagem, e não sobrar para descobrir em produção. - Semântica de marcação: um layout que empilha
divs até formar a tela certa é visualmente idêntico a um construído com HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → semântico, e completamente diferente para leitor de tela e para SEO↳SEO4 conteúdosPor que a transição do SEO clássico para a Otimização de Motores Generativos (GEO) exige que se repense a modelagem semânticaMarketing Tech · mai 2026O impacto da pesquisa e do SEO no comércio eletrônico: insights da State of Search Brasil 5Marketing Tech · fev 2025SEO por Elas 2025: Impulsionando e promovendo mulheres no Marketing DigitalMarketing Tech · fev 2025Ver tudo em Marketing Tech →. - Estados que a demo não mostra: loading, vazio, erro, dado longo que quebra o layout, timeout de rede. O prompt raramente cobre isso, e o resultado gerado também não.
- Consistência com o design system real: os Make kits ajudam a puxar componentes existentes, mas nada impede a IA de recriar um botão do zero em vez de usar o componente oficial. Aí o protótipo diverge do sistema, e a divergência vaza para o código.
O ganho de velocidade é verdadeiro. Mas velocidade sem critério de qualidade só empurra o trabalho para depois, geralmente para a engenharia limpar, o que anula boa parte do ganho de tempo prometido.
Um jeito de encaixar isso no fluxo
O caminho que eu proporia para uma equipe de produto que quer adotar o Make sem cair na armadilha do protótipo-que-parece-pronto:
- Use o Plan mode antes de gerar. Definir intenção, estados e requisitos de acessibilidade como parte do plano é mais barato que corrigir depois.
- Amarre os Make kits ao design system de verdade. Se o sistema tem componentes com acessibilidade já resolvida, force a geração a usá-los, não a inventar novos.
- Trate o código gerado como rascunho, não como entrega. O
code-backeddo Make é uma vantagem justamente porque permite inspecionar e corrigir a marcação. Use isso. - Coloque acessibilidade na checagem de handoff. Teste por teclado, rode um leitor de tela, valide contraste. Isso não é etapa opcional de fim de projeto, é parte de dizer que o protótipo está pronto.
- Deixe explícito quem valida o quê. Se a fronteira entre design e engenharia ficou borrada, a governança precisa ser combinada, não presumida.
Quando não vale a pena
O Make brilha para explorar ideias rápido, testar um fluxo com usuários antes de comprometer sprint de engenharia, ou alinhar times em torno de algo tangível. Nesses casos, gerar em horas o que levava semanas é um ganho legítimo de pesquisa e validação.
Já para features com requisitos rígidos de acessibilidade, performance, segurança ou integração profunda com o backend, tratar a saída do Make como código de produção é arriscado. A ferramenta oferece a versão sobre codebase local (ainda em beta) justamente para aproximar esse cenário, mas beta é beta. Nesses casos, o Make continua útil como acelerador da fase de exploração, e não como substituto do trabalho de engenharia.
A leitura que fica: o Figma Make não elimina o handoff, ele o antecipa e redistribui. Quem desenha ganha poder de gerar algo funcional e, junto, herda decisões de qualidade que antes não eram suas. Design sempre foi argumento com evidência; agora o argumento vem com código anexado, e a responsabilidade por esse código também.
Este artigo foi escrito por Yara Uchôa, colunista de UX e product design. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de UX e Product Design. Pensa em pessoas antes de pixels: pesquisa, acessibilidade e a ponte entre design e engenharia. Criativa e empática, defende decisão baseada em evidência de uso.
Comentários
Ninguém comentou ainda. Começa a conversa?