Designer de IA não é prompt engineer. É arquiteto de contexto.
O trabalho mais valioso no design com IA não é escrever prompts melhores. É estruturar contexto, limites, papéis e verificação para que agentes produzam algo confiável.
Muita discussão sobre IA em design ainda para cedo demais em prompt engineering.
Precisa, mas isso é pouco. Prompt bom ajuda em uma conversa. Sistema bom ajuda todo dia. A diferença entre os dois é simples: um prompt tenta convencer a IA a acertar agora; uma arquitetura de contexto reduz a chance de ela errar de forma recorrente.
Quando um designer pede "melhore essa tela", a IA precisa adivinhar quase tudo. Qual é o usuário? Qual componente já existe? O que não pode mudar? A marca permite esse tom? O estado de erro já foi definido? A acessibilidade é requisito ou detalhe? O código atual é a fonte da verdade ou o Figma ainda manda?
Se essas respostas não estão no sistema, o modelo tende a devolver soluções genéricas.
E uma solução genérica é exatamente o que um bom designer deveria questionar.
O problema não é o prompt. É o vazio ao redor dele.
Um fluxo maduro de IA para design tem cinco camadas.
- Briefing do projeto: objetivo, público, restrições e critério de sucesso.
- Regras sempre ativas: tokens, tipografia, acessibilidade, tom de voz, padrões de código.
- Contexto sob demanda: Figma, Storybook, repositório, pesquisa, screenshots e dados reais.
- Papéis reutilizáveis: agentes ou skills com uma função clara.
- Verificação: testes, screenshots, revisão de acessibilidade e checagem de claims.
Sem isso, o designer fica preso em uma espiral conhecida: pede uma versão, recebe algo genérico, corrige no chat, perde contexto, pede de novo, aceita o menos ruim porque já gastou tempo demais.
Isso não é colaborar com IA. É terceirizar julgamento para uma caixa que não conhece o produto.
O designer de IA desenha o ambiente de decisão
O novo papel do designer não é virar engenheiro do dia para a noite. Também não é virar operador de ferramenta. O papel é desenhar o ambiente em que a IA toma decisões.
Antes de pedir uma solução, o designer precisa definir:
- o que a IA pode explorar livremente;
- o que ela precisa seguir com precisão;
- quais fontes são confiáveis;
- quais decisões exigem revisão humana;
- qual formato de resposta reduz ambiguidade;
- como a qualidade será verificada.
Esse é o trabalho de arquitetura de contexto.
Quando isso existe, o prompt fica menor e melhor. Em vez de despejar um texto enorme tentando compensar falta de estrutura, você aponta para fontes vivas: tokens.json, AGENTS.md, Figma, código, critérios de aceite, checklist de acessibilidade.
O modelo não precisa lembrar tudo. Ele precisa saber onde buscar e o que fazer com o que encontrou.
Um exemplo prático
Pedido fraco:
Melhore essa tela de cadastro usando IA e deixe mais moderna.
Pedido com arquitetura de contexto:
Audite o fluxo atual de cadastro no código e no Figma. Use os componentes existentes. Não crie dependência nova. Proponha três alternativas para reduzir incerteza do usuário antes do primeiro envio. Cada alternativa precisa incluir estados de loading, erro, sucesso e foco por teclado. Retorne primeiro a análise, depois a recomendação, depois os arquivos que seriam alterados.
A segunda versão não é melhor porque tem palavras bonitas. Ela é melhor porque remove adivinhação.
Ela define fonte, escopo, restrição, critério de qualidade e ordem de trabalho.
O que vira prova
Em um piloto interno, eu não comecei pedindo para a IA "fazer uma tela". Primeiro fixei a fonte visual, os estados obrigatórios, os componentes esperados, os limites humanos e a evidência mínima.
Só depois veio o protótipo.
O resultado não era uma tela para postar no LinkedIn. Era uma prova pequena: desktop, mobile, foco por teclado, estado vazio, recuperação, movimento reduzido e um relatório dizendo o que foi verificado e o que ainda dependia de revisão humana.
Essa diferença importa. Sem prova, IA vira estética rápida. Com prova, IA vira processo de design.
Designers precisam criar papéis, não pedir milagres
Um erro comum é usar a mesma IA para tudo ao mesmo tempo: pesquisar, criticar, desenhar, implementar, revisar e escrever o case. Isso entope o contexto e mistura modos de pensamento diferentes.
Eu prefiro separar papéis:
design-deconstructor: analisa layout, hierarquia, componentes e interações.frontend-implementer: transforma a intenção em protótipo pequeno.a11y-reviewer: procura bloqueios de teclado, foco, contraste e semântica.evidence-verifier: remove métricas inventadas e claims sem fonte.copy-humanizer: corta linguagem inflada antes de publicar.
Cada papel precisa de uma saída curta. Cinco bullets. Uma tabela. Caminhos de arquivo. Bloqueios apenas. Quanto mais solto o retorno, mais o agente polui o próximo passo.
Onde o portfolio entra
Um portfolio forte na era da IA não deveria mostrar apenas telas finais. Ele deveria mostrar como você estruturou a decisão.
Mostre:
- qual contexto você deu ao agente;
- quais limites você colocou;
- o que a IA tentou fazer errado;
- como você verificou a qualidade;
- quais partes ficaram humanas por decisão, não por falta de automação.
Isso muda a leitura do seu trabalho. Você deixa de parecer alguém que "usa IA" e passa a parecer alguém que sabe governar IA dentro de produto real.
A habilidade rara
A maioria dos designers vai aprender a pedir telas para uma IA.
A diferença competitiva está em aprender a construir o sistema que faz a IA respeitar produto, marca, acessibilidade, código e contexto de negócio.
Esse é o ponto.
O designer de IA não é a pessoa que escreve o prompt mais criativo. É a pessoa que transforma ambiguidade em contexto executável.
E contexto executável é design.
Referências
- Why design.md and skills.md aren't working, Evangeline Ng
- Level up from using the design SKILL.md, Evangeline Ng
- Agentic Design Systems, Into Design Systems
- Design Systems MCP, Into Design Systems