stamatios
← Voltar ao feed
Lápis de designer se transformando em braço robótico que continua desenhando numa tela de app ao vivo, representando a evolução do designer com IA
Produto & Design · IA & Modelos

Como se tornar um designer que constrói com IA

resumo de ~3 min

De Figma para protótipos vibecoded

Maya Brennan, designer na Amplitude, relata que deixou de usar Figma no desenho de produto ao integrar uma equipe 0–1 que lançava várias vezes por dia. Para não virar gargalo, passou a criar protótipos HTML clicáveis no Claude, pedir 3 a 5 variações de componentes e iterar no mesmo dia. Ela afirma que a IA não acerta bem os últimos 10% do acabamento visual e recomenda wireframes simples, dissociados do design system. Com o posterior lançamento do Claude Design, adotou protótipos lo-fi e hi-fi no mesmo canvas e imagens de produto em HTML.

O produto como fonte de verdade

Sem um lugar canônico para apontar como "os designs mais recentes", testou híbridos de screenshots no Figma e exportadores de HTML, todos insatisfatórios. Citando Jenny Wen, da Anthropic, concluiu que o processo tradicional discovery → mock → iterate pressupõe construção lenta e cara; quando o produto evolui rápido, a fonte de verdade passa a ser o próprio produto. Para que essa fonte fosse "designed", ela precisou começar a enviar código real.

Acesso ao codebase e argumentos para convencer engenharia

Brennan sustenta que design AI-native é a capacidade de lançar os próprios designs e refiná-los, porque detalhes de interação e ajustes visuais se perdem no handoff. Para conseguir acesso, sugere: mostrar exemplos reais de designers enviando código, explicar que isso retira trabalho frontend trivial dos engenheiros, encontrar um champion de engenharia e, se houver resistência, começar com um bot de codificação no Slack - ela mesma enviou seu primeiro PR via Cursor Bot.

Dono do frontend, sem construir tudo

Ela esclarece que "owning" não significa construir toda a interface, mas liderar decisões de frontend: revisar PRs de frontend, colaborar com engenheiros em reformulações de UX e implementar boa parte do polimento de UI. Recomenda começar por mudanças pequenas, estudar limites entre frontend e backend e comunicar o raciocínio por trás das decisões. Reconhece que precisou ganhar confiança e renegociar handoffs com engenheiros e PM.

Custos do fluxo e limites do craft

Na etapa final, admite conflito: o fluxo com múltiplos agentes e vários PRs por dia trouxe escala e acabamento, mas exaustão por troca de contexto e sensação de designs transitórios. Citando Amelia Wattenberger, associa a perda de fricção das interfaces à perda de satisfação humana. No FAQ, recomenda pausar após três prompts repetidos no mesmo problema, atualizar o SKILL.md quando o erro se repete, prototipar antes no Claude Design e depois usar o protótipo como referência no Cursor, e criar uma Polish Week mensal para distribuir ajustes de UI. Sua conclusão é que se pode otimizar fluxo e output, mas não acelerar criatividade, simular taste ou substituir tempo, experiência e arte por LLM. Ela usa Claude Chat, ChatGPT, Claude Design, Cursor, Linear e Notion AI, e afirma não ter todas as respostas.