Reduzindo a distância entre o problema e a interface.
Um sistema de raciocínio de produto criado para ajudar times a explorar, criticar e estruturar ideias antes de abrir o Figma.
Times entram em UI antes de terminar de pensar.
A maior parte do trabalho de produto hoje começa no Figma. O brief ganha tela antes de ganhar decisão. Discovery vira protocolo — algumas entrevistas, um board no Miro, e rapidamente o time já está empurrando pixels.
O custo aparece depois: modelo de dados ambíguo, fluxos que se contradizem, features resolvidas com craft mas endereçando a pergunta errada. A interface fica limpa. O produto por trás dela não sustenta.
Ferramentas generativas aceleraram esse padrão. Produzir tela ficou barato. Direção continua cara. Times entregam mais UI por semana e perdem clareza estratégica ainda mais cedo.
O valor está na parte do trabalho que costuma ser pulada.
O uso óbvio de LLMs em design é gerar: layout, copy, componente. O uso mais valioso é o oposto — sintetizar, enquadrar, encontrar contradição. A parte lenta do trabalho.
O UX Copilot nasce de uma aposta simples: se um modelo é bom em reduzir ambiguidade, ele precisa entrar antes. Onde a decisão custa caro, não onde a execução é rápida.
Um ambiente de decisão, não mais um gerador.
Na prática, o UX Copilot se parece menos com uma ferramenta de design e mais com um ambiente de raciocínio. Brief entra. Decisão estruturada sai. A interface é uma sequência de conversas que, normalmente, o time só teria tarde demais.
Cada sessão produz um artefato que designer ou PM consegue defender em reunião — premissas nomeadas, tradeoffs visíveis, próximo passo claro.
Quatro estágios, um único loop.
O produto se organiza em quatro modos conectados. Não são features — são o formato de um único ciclo de discovery.
Pensar
Voltar ao problema antes de propor solução. O sistema empurra o time para fora do modo execução quando o brief já vem com resposta embutida.
Solução
Explorar respostas de produto — não telas. Tradeoffs, restrições e efeitos de segunda ordem aparecem explícitos, não subentendidos.
Crítica
Uma passagem adversarial. O modelo argumenta contra a proposta: premissas frágeis, casos não cobertos, pontos onde o modelo de dados quebra.
Construir
Só aqui a interface entra na conversa. A esta altura o time está desenhando contra decisões, não contra opiniões.
Construído em ciclos curtos, testando contra si mesmo.
O produto foi prototipado em Lovable em iterações curtas. Cada ciclo testava uma forma diferente da mesma pergunta: qual é o formato certo para uma conversa estruturada sobre produto?
A modelagem do fluxo veio antes da UI. Prompts foram tratados como componentes — versionados, nomeados, compostos. A interface chegou por último, quase como uma maneira de tornar visível o modelo de raciocínio por trás do produto.
Onde a pressão de design realmente apareceu.
- Fugir do output genéricoA resposta default de um LLM soa sempre igual. Prompts estruturados e uma passagem adversarial foram o único caminho confiável para chegar em algo que um designer sênior usaria de verdade.
- Estrutura sem virar formulárioRígido demais, vira form. Aberto demais, vira chat. O sistema precisava impor formato sem impor resposta.
- Reduzir repetição estratégicaRepetição é o modo de falha da síntese por IA. Cada sessão precisava parecer ganha, não preenchida em um template.
- Evitar raciocínio rasoO modo Crítica existe exatamente para tornar output confiante-mas-superficial desconfortável de seguir adiante.
IA é alavanca no pensamento, não no output.
A versão deste produto que gerava UI deixou de ser interessante em uma semana. A versão que ajudava um time a discordar de forma produtiva continua em uso.
IA composta com estrutura vira repertório. Sem estrutura, é apenas ruído plausível. Com ela, os mesmos modelos viram uma forma de tornar raciocínio sênior de produto replicável dentro do time.
A função mais útil do UX Copilot é desacelerar o time exatamente no momento em que ele normalmente aceleraria.