mickzijdel/design-process

Processo de Design

Os modelos são capazes de criatividade incrível, mas essa criatividade é sufocada pela forma como são treinados. Um modelo constrói um design token por token, e sempre que precisa tomar uma decisão de design — quais cores usar, como organizar elementos — ele preenche os tokens que acha que têm maior probabilidade de agradar a todos. O design acada repetitivo e sem graça: o caso definitivo de design-por-comitê. Um ótimo design começa com o sentimento e visa criar uma resposta emocional. Ele quebra as regras e encanta os usuários com escolhas memoráveis e inesperadas — exatamente o oposto de fazer a escolha mais previsível a cada passo.

Este skill é um processo de design reimaginado para agentes de IA, vagamente inspirado pelo modelo Double Diamond: Descobrir novas ideias além da média, explorando uma variedade de direções e escrevendo briefs de design ousados; Definir uma identidade de design individual, indo além de padrões familiares e encadeando modelos; Entregar um resultado final impressionante, polindo arestas ásperas e descuidadas. (Adaptado de "Como transformar sua IA em um designer de classe mundial" de Anshu Chimala "How to turn your AI into a world-class designer", com as regras recorrentes dos skills de design mais bem avaliados compostas em references/anti-slop.md.)

Duas regras estão acima de cada etapa:

• O brief vence. Onde o usuário fixou uma direção, uma fonte, uma paleta, uma era — siga-a exatamente, mesmo que apareça em uma lista "nunca por padrão". Redirecionar um brief claro para seu próprio gosto é uma falha. As listas se aplicam apenas onde o brief deixa um eixo livre.
• Um vício de design é um padrão alcançado sem motivo, não um padrão que aparece. Julgue pela intenção. Quando não tiver certeza se algo é um vício ou uma decisão, trate-o como decisão.

As etapas

1. Portão: o que é isso e para quem é? Uma linha para cada: o produto, o público, a única ação para a qual a página existe, a plataforma e quaisquer restrições de marca. Se o usuário não forneceu nada disso, pergunte uma vez (AskUserQuestion) — um brief que você inventa é o brief médio. O setor do assunto, os materiais e o vocabulário são de onde vêm as escolhas distintas. Na mesma mensagem, resolva a imagética: verifique se há uma rota de geração (uma chave em .env.agents ou fnox, um servidor MCP fal/replicate, o Codex CLI, ferramentas de imagem integradas; veja define.md). Nenhuma encontrada → peça uma, ou por ativos reais (capturas de tela do produto, fotos). Registre a resposta no brief; uma página apenas com tipo é uma decisão que o usuário toma, não um padrão em que o agente cai.

2. Descobrir — vá para o amplo antes do profundo. Obtenha variedade de fora do modelo. Ou semeie a direção a partir de uma string aleatória (String Seed of Thought) ou obtenha algo específico e selvagem com uma inspiração nomeada que o usuário traz; quando ele não tiver nenhuma, gere uma lista ampla de linguagens de design e deixe-o reagir. Quando a composição e a hierarquia importam mais do que a inspiração semeada em si, crie um mockup da tela com um modelo de imagem primeiro e construa a partir disso em vez de um brief apenas textual. Escreva a direção escolhida como um brief de design antes de qualquer código. Várias direções desejadas → vários briefs, várias variantes descartáveis, cada uma isolada. → references/discover.md

3. Construa a primeira versão contra o brief. Comprometa-se com a direção: tipografia real (escolhida para este assunto, carregada e verificada), um acento usado raramente, uma forma de página inteira que não seja hero → três funcionalidades → CTA → rodapé, um elemento de assinatura que um visitante lembraria, cada estado projetado. Verifique as escolhas em relação à tabela "nunca por padrão" em references/anti-slop.md à medida que avança, não depois, e execute sua verificação automática de seis eixos antes da primeira captura de tela.

4. Definir — o loop do crítico. Capture a tela da página (desktop e celular, para arquivos). Envie um subagente crítico de design no modelo mais forte disponível, em um contexto novo com apenas as capturas de tela e a estética pretendida (nunca o código, nunca a pontuação alvo). Ele nomeia as lacunas para um padrão de estúdio — ou, melhor, contra designs de referência reais, às cegas — e pontua /10. Corrija a maior lacuna, recapture, reenvie com o mesmo prompt. O loop é limitado: duas rodadas por padrão, depois pare no primeiro de padrão atingido / uma rodada que não mudou nada / orçamento esgotado, e mostre ao usuário. Um limite de pontuação sozinho não é uma saída; nenhum loop publicado jamais terminou em um. → references/define.md, prompt em references/critic-prompt.md

5. Definir — ativos reais. Qualquer página que carregue um visual — um hero, arte de recurso, uma textura, um espaço de ilustração — recebe imagética gerada ou real por padrão, não gradientes, formas ou padrões CSS; os agentes pulam esta etapa a menos que sejam instruídos, e a decoração desenhada em código é o sinal revelador. Onde o movimento justifica, vídeo (loops com chroma key, transições interpoladas por keyframe). As chaves vivem em um arquivo env ignorado pelo git ou fnox, nunca no código-fonte. Nenhuma rota foi encontrada no portão e o usuário escolheu apenas tipo → diga isso na passagem como uma lacuna conhecida e projete para que o hero se sustente apenas com tipografia e composição. → references/define.md

6. Entregar — subtraia, depois verifique. Percorra cada elemento perguntando o que quebra se ele for removido; remova brilhos, gradientes, rótulos redundantes, texto de preenchimento, controles personalizados piores que os nativos, seções que um modelo colocou lá. Depois, responsivo, escuro/claro, auditoria de accessibility, desempenho e uma captura de tela real do navegador em cada ponto de quebra. → references/deliver.md

7. Entregar — passagem de voz. Execute o skill writing:voice-profile em cada string visível ao usuário (títulos, leads, botões, estados vazios e de erro) para que o texto seja lido no registro do usuário, não no padrão do modelo; sem um perfil, suas regras básicas mais writing:humanizer ainda se aplicam. → references/deliver.md

flowchart LR
    G[Portão: produto, público,
uma ação] --> D1[Descobrir:
semente ou prompt selvagem]
    D1 --> B[Brief de design]
    B --> V[Construir v1 contra o brief]
    V --> S[Captura de tela]
    S --> C{Crítico /10
contexto novo}
    C -- "lacunas" --> F[Corrigir maior lacuna]
    F --> S
    C -- "9+ ou travado" --> A[Imagens / vídeo reais
onde a personalidade é fina]
    A --> P[Entregar: subtrair,
depois verificar]
    P --> W[Passagem de voz
sobre todo o texto]

Qual regime

Nem todo trabalho de design merece o loop completo. Escolha o tratamento, não se deve projetar:

Trabalho	Faça
Um componente, um painel de configurações, uma página de documentação, uma pequena reformulação	Etapas 1–3 + um único visual: construa completamente, capture desktop e celular juntos, corrija tudo o que mostra em lote, confirme uma vez, pare
Uma landing page, uma tela hero, qualquer coisa que o usuário chamou de "genérica" ou quer que se destaque	O loop completo, etapas 1–6, crítico limitado como acima
O usuário quer uma variedade para escolher	Etapa 2 três ou mais vezes em variantes isoladas, uma captura de tela cada, deixe-o escolher, depois continue da etapa 3 no vencedor

Referência rápida

Sintoma	Ação
Toda execução parece a mesma (gradiente roxo, hero dividido)	Semeie a partir de uma string aleatória ou nomeie uma inspiração selvagem — discover.md
"Tornar único/aleatório" não ajudou	Não pode ser aleatório apenas pedindo; a variedade deve vir de fora do modelo
Nenhuma ideia de qual direção tomar	Prompt de lista ampla → usuário reage → refine → construa prompt
Layout/hierarquia parece errada, mas a direção está certa	Crie um mockup da tela com um modelo de imagem e construa a partir dele, junto com o brief escrito — discover.md
O agente fica dizendo "parece bom" sobre seu próprio trabalho	Subagente crítico, contexto novo, apenas captura de tela, mesmo prompt a cada rodada
Crítico nunca satisfeito, tokens queimando	Limite em 2 rodadas primeiro; pare em uma pontuação travada; torne o padrão concreto (escolha cega vs referências reais)
Toda escolha não padrão é a mesma não padrão (Space Grotesk, creme + serifada)	Um padrão de segunda ordem ainda é um padrão; rotacione — anti-slop.md
Personalidade vem de gradientes CSS e blobs	Gere imagens reais; shaders/3D apenas em combinação com imagens
Nenhuma chave de geração de imagem disponível	Pergunte no portão ou obtenha ativos reais do usuário; envie apenas com tipo apenas se for a escolha declarada deles
Parece carregado, "premium" está faltando	Passagem de subtração — deliver.md
Parece bom na revisão de código	Não está pronto até que você tenha visto a captura de tela

Pronto quando

• Um brief escrito existe e o design enviado ainda corresponde a ele.
• Remova o nome do produto do brief: alguém ainda pode dizer para que a página serve.
• O crítico pontuou 9+ (ou venceu a comparação cega) em um contexto novo, ou o loop atingiu seu limite e o usuário aceitou onde está.
• Nada na tabela "nunca por padrão" sobrevive sem um motivo escrito no brief.
• Cada espaço visual contém imagens geradas ou reais, ou o brief registra a decisão do usuário de usar apenas tipo e a passagem nomeia isso como uma lacuna.
• Cada elemento restante tem um propósito; o texto diz apenas o que o produto faz.
• Capturas de tela em larguras de celular e desktop, claro e escuro, foram examinadas e a auditoria de accessibility está limpa.
• Cada string visível ao usuário passou pela passagem de voz; o texto lê como o usuário escreveria e o relatório de auditoria de voz não relata palavras proibidas.