A IA é só a ponta.

Antes de qualquer tela, você precisa saber: o que esse negócio faz, para quem, e por que alguém o escolheria em vez do concorrente. Se essa frase não existe, nenhum prompt resolve. Terceirizar isso de cara pra IA funciona. Mas ela vai escrever, com fluência impecável, uma confusão criativa, e você vai ficar por horas brigando com ela pra ter algo decente.

Definimos um ou mais (no máximo 3) visitantes ideais: quem são, de onde chegam, com quais dúvidas. E a pergunta mais reveladora do processo inteiro: o que você quer que elas pensem quando sair? A resposta vira critério de decisão pra tudo que vem depois. E sim, se você já conhece sobre personas, é exatamente o que estamos fazendo, mas podemos chamar de proto-personas, ou protótipos de personas. A diferença entre proto-personas e personas é bem simples: proto-personas não precisam de pesquisa prévia. Elas contam com o conhecimento do seu cliente.

Criando as proto-personas você consegue entender a clareza que o cliente tem do seu público. E isso gera abertura para um estudo mais profundo. Mas agora lembra: quem chegou agora é você. Confie no seu cliente. Ganhe confiança.

Escolhemos uma ação para o visitante. Chamar no WhatsApp, ver um case, baixar um PDF. Tudo na página existe para conduzir a ela; o que não conduz é ruído. Objetivo claro é o que permite dizer "não" com tranquilidade.

Aqui o desafio é fugir de algo muito aberto. O resultado deve ser algo concreto, mensurável e importante. Tente ao máximo evitar coisas do tipo: "se o site trouxesse um resultado, ele seria elogios de pessoas que acharam bonito" e "compartilhar nas redes é a única ação que quero que ela tome".

Mapeamos o terreno: o que o cliente já tem, o que não tem, o que limita e o que libera. É nesta camada que as referências visuais entram. Conectadas ao posicionamento, ao público e ao objetivo, elas deixam de ser um moodboard infinito. A regra é dura e boa: de cada referência, você pode roubar UM atributo. Dessa lista curta já nasce o material da prototipação.

A tarefa aqui é simples: pra cada referência que o cliente trouxer, preencha os dados do board. Isso vai te ajudar a definir depois o que traz ou não pro design e de qual forma.

Nessa etapa é importantíssimo você saber se seu cliente já possui um site, onde ele é hospedado e entender por cima, pelo menos, aonde você vai precisar colocar o site do cliente.

Uma armadilha que eu já caí algumas vezes: ignorar essa etapa. Deixar tudo pronto e depois descobrir que o que você fez não encaixa no que o cliente tem como hospedagem ou CMS, por exemplo.

Entram os projetos que mais destacam o posicionamento. E só. Cada história tem estrutura mínima: problema do cliente, embasamento, resultado esperado, papel, entregáveis. Aqui fica explícito por que isso não é waterfall: as camadas não são fases que se atravessam uma vez em sequência. Num workshop de uma manhã, passamos por todas, e voltamos a elas sempre que o fazer ensina algo novo.

Com as cinco camadas na mesa, o Claude Code deixa de ser uma máquina de adivinhar e vira uma máquina de executar. Contexto é o que torna a IA inteligente: cada resposta do workshop vira instrução, critério e teste. A velocidade que parece mágica é, na verdade, preparo.

A bifurcação: dois jeitos de começar

Caminho A, direto do material: você organiza tudo que o workshop gerou numa pasta e entrega pro Claude com um prompt-mestre. Ele estrutura, questiona e propõe antes de desenhar qualquer tela.

Caminho B, com protótipo de baixa fidelidade: muito recomendado. Você já rabiscou a página, no papel ou no Figma, e o Claude parte da sua intenção de layout em vez de partir do zero. O protótipo entra na pasta como screenshots. Se nasceu no Figma, dá pra conectar o arquivo direto ao Claude Code (veja abaixo).

Nos dois caminhos, a pasta é a mesma.

A pasta do projeto

Copie essa estrutura e preencha com o material do workshop:

meu-projeto/
├── briefing/
│   ├── posicionamento.md    (as 6 perguntas preenchidas)
│   ├── publico.md           (proto-personas, até 3)
│   ├── objetivo.md          (resultado esperado + ação única)
│   ├── tecnico.md           (domínio, hospedagem, CMS, restrições)
│   └── conteudo/
│       ├── cases.md         (os escolhidos, com a estrutura mínima da história)
│       └── depoimentos.md   (com contexto: quem, projeto, resultado)
├── referencias/
│   ├── referencias.md       (por referência: atributo roubado + o que não gosta)
│   └── screenshots/
└── prototipo/               (caminho B, recomendado)
    ├── screenshots/         (fotos do rascunho à mão ou frames exportados do Figma)
    └── notas.md             (o que cada tela quer comunicar)

Ou o caminho preguiçoso e inteligente: você não precisa escrever nenhum desses .md na mão. Jogue TUDO que o workshop gerou numa pasta (fotos dos post-its, transcrições, anotações soltas, prints) e deixe o Fable ou o Opus organizar pra você:

Nesta pasta está todo o material bruto de um workshop de posicionamento que
rodei com meu cliente: fotos de post-its, anotações soltas, transcrições,
prints e o que mais eu tiver jogado aqui.

Organize tudo na estrutura abaixo, sem inventar nada:

meu-projeto/
├── briefing/
│   ├── posicionamento.md   (as 6 perguntas do workshop preenchidas)
│   ├── publico.md          (proto-personas, até 3)
│   ├── objetivo.md         (resultado esperado + ação única)
│   ├── tecnico.md          (domínio, hospedagem, CMS, restrições)
│   └── conteudo/
│       ├── cases.md        (com a estrutura mínima da história)
│       └── depoimentos.md  (quem falou, sobre qual projeto, com qual resultado)
├── referencias/
│   └── referencias.md      (por referência: atributo roubado + o que não gosta)
└── prototipo/
    └── notas.md            (o que cada tela quer comunicar)

Regras:
1. Só use o que está no material. O que não estiver, marque como
   [FALTANDO: pergunta pro cliente] no arquivo correspondente.
2. Em cada informação, cite a origem (o nome do arquivo bruto de onde veio).
3. Nada de melhorar ou completar as respostas do cliente. As palavras dele
   são a fonte da verdade.
4. No final, me devolva a lista do que ficou faltando e do que ficou ambíguo.

O prompt-mestre, em abas por modelo

Aqui está um ouro que ninguém conta: modelos diferentes leem o mesmo material de jeitos diferentes. O prompt que faz o Opus 5 brilhar deixa o Sonnet perdido, e o Fable 5 rende mais quando ganha espaço pra ter opinião. Por isso entregamos três versões.

Leia toda a pasta briefing/ e referencias/ antes de responder qualquer coisa.

Contexto: sou designer e vou criar uma landing page para o cliente descrito em
briefing/. Todo o material veio de um workshop com o cliente: as respostas são
a fonte da verdade. Quando algo estiver ambíguo, pergunte antes de assumir.

Sua tarefa nesta primeira sessão, em ordem:
1. Resuma o projeto em um parágrafo: negócio, público, ação única esperada.
2. Liste o que está faltando ou contraditório no material. Não invente nada.
3. Proponha a estrutura da página, seção por seção, cada uma justificada por
   uma resposta do briefing (cite o arquivo).
4. Gere um CLAUDE.md com as regras do projeto: posicionamento, público, ação
   única, atributos roubados das referências, restrições técnicas.

Não escreva código ainda. O design começa depois que eu aprovar a estrutura.

Você é meu par de design neste projeto. Leia briefing/, referencias/ e
prototipo/ (se existir) e forme uma opinião própria antes de me devolver
qualquer coisa.

Quero três leituras suas:
1. A tese da página em uma frase: o que ela precisa provar, e pra quem.
2. A estrutura que você defenderia, com o porquê de cada seção amarrado ao
   briefing. Aponte onde você discorda do material, se discordar.
3. Riscos: onde este projeto pode ficar genérico, e o que evita isso.

Depois gere o CLAUDE.md do projeto. Não escreva código nem HTML ainda.

Siga exatamente estes passos, um de cada vez, e confirme comigo entre eles.

Passo 1: leia briefing/posicionamento.md, briefing/publico.md e
briefing/objetivo.md. Devolva um resumo de no máximo 10 linhas.
Passo 2: leia briefing/tecnico.md e liste as restrições em bullets.
Passo 3: leia referencias/referencias.md e liste, por referência, o único
atributo roubado.
Passo 4: proponha a estrutura da página como lista numerada de seções, uma
linha por seção, com a justificativa entre parênteses.
Passo 5: gere o CLAUDE.md com: posicionamento, público, ação única,
restrições e atributos das referências.

Não pule passos. Não escreva código.

Se o protótipo de baixa nasceu no Figma

O Figma tem um servidor MCP nativo (Dev Mode MCP Server) que deixa o Claude Code ler os frames direto do arquivo, sem screenshot:

Se o protótipo foi no papel: fotografe com boa luz, salve em prototipo/screenshots/ e descreva a intenção de cada tela em notas.md. O Claude lê imagem muito bem, mas intenção escrita evita interpretação criativa demais.

Prompt: estudar as referências pelo navegador

O board de referências vira instrução pro Claude abrir o navegador na sua máquina e estudar cada site de verdade, com os olhos no que o cliente marcou:

Abra o navegador e visite cada site listado em referencias/referencias.md.

Para cada um, o cliente marcou UM atributo que quer roubar e algo que não
gosta. Sua tarefa é entender COMO o site produz o atributo marcado. Navegue,
role a página inteira, observe menu, títulos, espaçamentos e transições.
Depois registre em referencias/analise.md, uma seção por referência:

1. Como o atributo roubado é construído (layout, tipografia, espaçamento,
   interação, o que for observável).
2. Como reproduzir a essência dele no nosso projeto sem copiar o site.
3. Confirmação de que o ponto que o cliente não gosta ficou de fora.

Não colecione nada além do atributo marcado. A regra do workshop vale pra
você também: um atributo por referência.

Prompt: tipografia e cores (deep research)

Parrudo de propósito: isso é pesquisa, não palpite. E uma dica honesta de custo: invoque o deep research com o modelo mais cost-efficient que der conta. Eu uso Opus 5 pra isso, não Fable 5. Pesquisa longa queima tokens, e o Opus resolve.

Faça uma pesquisa profunda de direção tipográfica e cromática para este
projeto. Antes de qualquer proposta, leia briefing/ e referencias/analise.md.

Tudo que você propuser precisa se justificar pelo negócio, pelas
proto-personas e pela ação única do projeto. Cite a resposta do briefing que
sustenta cada escolha.

Entregue:
1. Três direções de tipografia, cada uma com: par de fontes (título e texto),
   por que combina com o posicionamento, onde ela falharia, exemplos de uso
   em sites reais e situação de licença (priorize Google Fonts ou similar, e
   diga o custo quando não for gratuita).
2. Três paletas, cada uma com: base, superfície, texto e UM acento, valores
   em hex, contraste AA verificado entre texto e fundo, e a sensação que
   sustenta.
3. Um veredito: qual combinação de tipografia e paleta você recomenda, em um
   parágrafo, e por quê.

Regras: nada de tendência pela tendência, cite fontes reais e verificáveis,
confira cada afirmação de contraste, e conecte cada escolha ao briefing.

O prompt final: iniciar o design

Com estrutura aprovada, referências analisadas e direção de tipografia e cores fechada, este é o prompt que abre o design de fato:

Vamos começar o design. Leia CLAUDE.md, briefing/, referencias/analise.md,
prototipo/ (se existir) e a direção aprovada de tipografia e cores.

Construa a primeira versão da landing page em HTML e CSS, mobile-first,
seguindo a estrutura aprovada. Regras:

1. O protótipo de baixa manda no layout. Fidelidade à intenção, não ao traço.
2. Cada seção responde à pergunta do briefing que a justificou.
3. Ação única: todos os caminhos da página levam a ela.
4. Tipografia e cores: somente a direção aprovada.
5. Efeitos, fades e shaders: use o FXLab (fxlab.mirtilo.co) para aplicar
   com base no contexto do projeto, nada de biblioteca genérica de efeitos.

Me mostre o resultado seção por seção e pare pra eu aprovar antes de refinar.

A regra 5 é onde entra o FXLab, nosso projeto pra aplicar shaders, fades e efeitos com base no contexto do projeto, sem depender de biblioteca genérica. Conheça o FXLab: mais de 70 presets pra você animar seu site →

Esta é a trilha de landing pages. Apps, serviços, SaaS e PaaS pedem outras robustezes, outras faces do mesmo iceberg, e vão aparecer aqui, uma a uma. Você já deixou seu e-mail: avisamos quando cada face emergir. Antes que tudo derreta. 🙂