Designer do Ref explica como usar IA sem cair no visual genérico

Matt Dailey, fundador e CEO da Ref, descreve em "How I Design with AI" um método para engenheiros que não são designers e odeiam slop. Ele afirma que landing pages, apps e TUIs estão ficando iguais e que muitos resultados são incompreensíveis. O texto lista sete práticas.

Restrições antes de soluções

Dailey diz que o design tem cerca de três etapas: listar as restrições; considerar soluções que as satisfaçam; e, se uma restrição for adicionada ou removida, voltar à primeira. A referência é Notes on the Synthesis of Form, de Christopher Alexander. Restrições podem ser regras de fonte e tamanho, fluxos ou estados de lógica de negócio. O problema comum é pular a terceira etapa e fazer "design whack-a-mole". Quando um usuário se confunde, a equipe tende a partir para a solução; na Ref, isso ocorre especialmente com a barra lateral esquerda, que concentra muita informação. Correções pontuais levam a um remendo desconexo que prioriza interações aleatoriamente. A IA agrava a tendência ao incentivar pedidos como "deixe X mais proeminente" ou "adicione uma ação para Y", deixando mais usuários confusos. Ele recomenda avaliar se o feedback muda as restrições antes de buscar soluções. A Ref mantém um documento de "papercuts" e incômodos: corrige os óbvios e registra os menores para uma reformulação coesa.

Remover o que os agentes adicionam

Agentes gostam de adicionar coisas; o trabalho é remover o desnecessário. Isso vale para código e planos, em que criam try-catch extra ou reimplementam utilitários, e para UI, em que adicionam textos, linhas e ícones. O resultado pode parecer melhor que o de muitos engenheiros, mas ainda é "meio ruim". O passo fácil é perguntar de cada elemento: "eu realmente preciso disso?"

Iterar fora do produto

Ele desaconselha iterar design dentro do produto e recomenda uma ferramenta com controle fino, iteração rápida e pouco contexto extra. Chama de "gravidade do protótipo" o risco de o agente construir a primeira versão no código e parecer mais fácil refiná-la do que explorar alternativas. Desenhar no código real também força o agente a se encaixar nele. O Figma continua "o GOAT", com integração de IA melhorando a cada semana; Cursor Design Mode, Claude Design, startups e protótipos em HTML também servem. Ele pede uma ferramenta de design e três ou quatro variantes geradas por IA.

Componentes, previews e referências

Para evitar botões reimplementados, é preciso separar visão e lógica e criar componentes reutilizáveis. A Ref mantém uma página /showcase, onde agentes constroem componentes antes de conectá-los ao app. Preview deploys são a melhor forma de avaliar com dados reais e backend real. Sempre haverá polimento; mesmo que o agente construa o pedido, com dados reais pode-se perceber que não está certo. Em recursos grandes, a Ref separa PRs de frontend e backend: o backend é verificado com testes unitários e de integração; o frontend exige verificação humana, e previews facilitam compartilhar um link. Uma GitHub Action cria preview deploy para cada PR de frontend. Ele defende "roubar": a maioria dos problemas de UX já foi resolvida, então vale olhar produtos semelhantes. Bons designers começam reunindo capturas de tela, contexto valioso para o agente.

Explorar o gosto

Dailey trata o gosto como reflexão sobre a própria reação a algo. Respondendo a Kyle Chayka, diz que isso não é propriedade de círculos de Brooklyn; é necessário para criar e não criar slop. Engenheiros de produto identificam bem quando um design não funciona, mas têm dificuldade em consertá-lo por falta de uma biblioteca de soluções. Construir isso exige repetição e reflexão. O processo pode ser divertido e brutal, com críticas até algo ficar bom. Sem designer em tempo integral, a Ref adota uma "debulha": joga um design no meio e bate com varas até se sentir bem.