Construção de página de conversão
Nada é escrito antes que exista um Brief de Conversão. Procure por
03 Projetos/<Projeto>/_Pesquisa/[C] Brief de Conversão — *.md — ou a pasta de pesquisa do seu projeto se
você não estiver executando isso dentro dessa estrutura. Se nenhum existir, pare e invoque audience-research
em vez de adivinhar o ICP, as objeções ranqueadas ou o registro. Uma página construída com base em um público
adivinhado não é uma versão mais barata desta skill — é uma skill diferente e não confiável usando a estrutura
desta, e a seção de Registro do próprio Brief é a única entrada que nada downstream consegue recuperar se estiver errada
(../audience-research/SKILL.md — o registro, uma vez definido, é herdado, não redecidido).
O procedimento: duas passagens de escrita, depois um spec
Cada seção abaixo é escrita em duas passagens, nessa ordem, e a segunda nunca vaza para a primeira. Um terceiro resultado — o spec da seção, abordado mais adiante neste arquivo — segue assim que o texto estiver pronto:
- Decida o que a seção precisa realizar, usando a camada de framework — as alavancas da Equação de Valor, obstáculo revertido em solução, objeção mapeada para objeção oculta mapeada para mudança de crença mapeada para prova, valor empilhado e ancorado contra o preço. Esta camada é estrutural. Um comprador industrial alemão e um comprador de resposta direta self-service precisam exatamente da mesma coisa comprovada na seção de Mecanismo — que isso funciona, especificamente, para alguém na situação deles — mesmo que nada sobre como essa prova é expressa pareça igual duas vezes.
- Escreva no registro que o Brief especifica. O registro decide a intensidade da afirmação, o que conta como prova, se a urgência é utilizável e quão diretamente a página pergunta — não é uma passagem de tom aplicada depois que o texto está pronto. Pegue o registro nomeado na seção de Registro do Brief e mantenha-o em todas as onze seções sem redecidir no meio da página.
Pule a etapa 1 e você terá um texto fluente argumentando a coisa errada para a pessoa certa. Pule a etapa 2 e você terá um argumento preciso que ninguém neste registro terminará de ler. Mescle-as em uma única passagem e o resultado é um gerador de texto vestindo o nome desta skill — a falha que esta skill existe para prevenir.
- Produza o spec da seção, assim que o texto daquela seção estiver escrito — veja
## O spec da seçãoabaixo. Uma execução que para após as etapas 1 e 2 tem texto, mas nenhum artefato de entrega; o spec não é papelada opcional, é o terceiro resultado desta skill.
As onze seções
Herói, Problema, Resultado, Solução, Mecanismo, Pilha de Valor, Prova, Objeções, Garantia, CTA, FAQ —
nesta ordem, para uma página que executa o argumento completo. referencias/arquitetura-de-pagina.md é essa
ordem e a justificativa de por que é essa ordem e não outra. referencias/playbooks-de-secao.md é o que
cada seção precisa realizar e como isso muda entre os cinco registros — leia
a linha de Registro do Brief uma vez, depois leia apenas aquela coluna para cada seção, não todas as cinco.
Nem toda página precisa de todas as onze, ou nesta sequência — referencias/tipos-de-pagina.md cobre o que uma
home page, uma página de opt-in, uma página de preços, uma página de recurso e uma página de vendas completa
mantêm, comprimem ou descartam, e por que o trabalho que aquela página faz no funil é o que decide.
Duas seções carregam raciocínio próprio suficiente para precisar de um arquivo dedicado em vez de uma coluna de playbook:
- Objeções —
referencias/objecao-a-crenca.mdpercorre objeção superficial → objeção oculta → mudança de crença → prova, construída a partir da seção de Objeções ranqueadas do próprio Brief, em vez de uma lista genérica de FAQ montada depois que o texto já está escrito. - Prova —
referencias/biblioteca-de-provas.mdranqueia os tipos de prova por força e por quanto cada um realmente custa para obter, para que a seção seja construída com o que o cliente pode produzir esta semana, não com o que seria bom ter.
referencias/psicologia-de-conversao.md é a camada de modelo mental da qual o raciocínio de framework em
cada seção se baseia. Leia uma vez por projeto, não uma vez por seção — explica por que uma alavanca
funciona, não o que escrever.
O spec da seção
Produza um spec de seção por seção, junto com o texto, neste formato exato — design-handoff
o consome por esses cinco nomes de chave e nenhum outro:
section_type: <um dos onze>
purpose: <o que esta seção precisa realizar, da passagem de framework>
content_hierarchy: <o que um leitor vê primeiro, segundo, terceiro dentro da seção>
components: <os elementos concretos — título, subtítulo, espaço de mídia, formulário, tabela de comparação, selo…>
responsive_intent: <o que empilha, colapsa, reordena ou esconde primeiro em uma janela estreita>
Escreva o spec depois do texto, não antes. Ele descreve o que o texto realmente precisa conter, e um spec escrito primeiro tende a travar um layout ao qual o texto então é moldado, em vez do contrário.
Antes de enviar
Se uma skill de humanizador estiver disponível neste ambiente, passe o texto finalizado por ela antes de
considerar a página pronta. Se não estiver instalada — uma instalação nova deste plugin não tem vault e nenhum
humanizador — aplique ../varreduras-de-texto/referencias/vocabulario-proibido.md ao rascunho diretamente.
Um dos dois sempre é executado; qual deles depende do que está instalado, não se alguma etapa importa.
Onde a página vai
Por convenção neste vault, o texto da página finalizado vai junto ao Brief a partir do qual foi construído —
03 Projetos/<Projeto>/_Pesquisa/[C] Texto da Página — <Página> — <data>.md — ou onde quer que seu projeto
mantenha textos rascunhados se você não estiver executando isso dentro dessa estrutura. Esta skill produz duas
coisas: o texto em si e o spec de seção por seção que o design-handoff consome. Diga onde você
arquivou o texto; uma página que ninguém encontra não é uma página enviada.