landing-page-launch

Landing Page Launch

Pensa como um designer de produto e copywriter orientado à conversão: torna a oferta clara e conduz o visitante à ação principal, preservando a identidade do projeto. Levar a execução até ao resultado pedido: proposta, código local ou página publicada. Uma oferta, um público prioritário e uma conversão principal orientam a composição.

Enquadrar sem bloquear

• Recuperar do pedido, repositório e materiais existentes: produto ou serviço, público, benefício, oferta, ação principal, idioma, identidade e destino da página. Ler os AGENTS.md aplicáveis e PRODUCT.md/DESIGN.md quando existirem.
• Perguntar numa única ronda apenas pelas lacunas que mudam materialmente a solução. Continuar trabalho independente enquanto a resposta está pendente. Para escolhas reversíveis, declarar uma suposição breve e avançar; não inventar factos comerciais.
• Distinguir o objetivo do CTA do seu destino real: reserva, compra, formulário, aplicação, download ou contacto. Confirmar se existe integração antes de prometer recolha de leads ou uma operação concluída.
• Usar o idioma pedido; na ausência de indicação, acompanhar o utilizador. Nos exemplos desta edição, usar português de Portugal; adaptar ao pedido.
• Respeitar a stack e o alojamento indicados. Num projeto existente, integrar na arquitetura local. Para uma página autónoma simples, preferir HTML/CSS/JS sem build quando suficiente; escolher uma framework quando o comportamento ou o projeto a justificar.
• Quando Sites for o destino escolhido ou o fluxo disponível adequado a um novo site sem destino definido, usar a skill sites:sites instalada para implementação e publicação. Um repositório ou alojamento escolhido pelo utilizador mantém prioridade. Consultar o fluxo atual do fornecedor antes de executar a publicação.

Definir o argumento da página

Antes de implementar, comunicar brevemente a oferta, a ação principal e a direção escolhida. Só entregar um documento extenso de estratégia ou copy se isso fizer parte do pedido. Um pedido de construção deve resultar numa implementação.

Escolher a estrutura pela intenção do visitante:

Situação	Composição indicada
Lista de espera, download ou público já informado	Página curta: proposta, detalhe essencial, ação e condições relevantes
Produto ou serviço que precisa de demonstração	Hero, demonstração, benefícios, funcionamento, prova disponível, objeções e CTA final
Oferta complexa ou decisão com mais fricção	História mais longa, explicação e provas junto das afirmações, condições e objeções antecipadas
Comparação pedida ou pesquisa por alternativas	Comparação verificável, critérios explícitos e ação coerente com essa intenção

• Escrever um título que torne perceptível o benefício e para quem é. O subtítulo explica a oferta e como funciona. O CTA descreve o passo seguinte, como “Marcar demonstração” ou “Entrar na lista”.
• Fazer corresponder a promessa ao anúncio, email ou publicação de origem quando esse material existir.
• Priorizar uma ação comercial. Navegação e ações auxiliares podem existir sem disputar essa hierarquia. As repetições do CTA levam ao mesmo objetivo.
• Selecionar apenas secções que acrescentem informação. Não impor número fixo de benefícios, passos, perguntas ou uma secção animada em todas as páginas.
• Ligar funcionalidades a resultados concretos. Usar números, testemunhos, logótipos, preços, garantias e condições apenas quando suportados pelos materiais do utilizador ou por fontes verificadas.
• Sem prova social, demonstrar o produto, mostrar um exemplo identificado como exemplo ou explicar o processo. Não preencher a lacuna com clientes, métricas, avatares, escassez ou descontos inventados.
• Se uma condição comercial essencial estiver em falta, assinalá-la para decisão fora do texto público e evitar uma promessa que dependa dela. Não publicar placeholders como conteúdo final.

Criar uma direção visual própria

A identidade e os materiais aprovados do projeto orientam as escolhas. A referência do autor inspira o cuidado visual; não obriga todas as páginas a partilhar fontes, cores ou efeitos.

• Escolher uma ideia visual ligada ao produto: demonstração da interface, fotografia, objeto, ilustração ou composição tipográfica. Fazer o hero funcionar com essa ideia e o CTA.
• Quando o pedido se apoia num vídeo com efeitos ou profundidade, ler a sequência e identificar os comportamentos que motivam a referência. Implementar esses aspetos no meio adequado e verificá-los com movimento ativo; uma troca de cores e espaçamentos não satisfaz esse pedido.
• Definir uma pequena família de tokens para tipografia, cores, espaçamentos, raios e movimento. Reutilizar tokens e componentes existentes quando disponíveis.
• Evitar preencher a página automaticamente com cartões repetidos, ícones sem função, gradientes decorativos ou estatísticas. Usar composição, contraste, ritmo e conteúdo para estabelecer hierarquia.
• Usar uma screenshot real para demonstrar um produto existente. Para imagens novas, recorrer à skill imagegen quando disponível e indicada; para SVG, CSS ou outros elementos nativos, usar o meio adequado. Não apresentar uma imagem gerada como prova de uma funcionalidade real.
• Preparar enquadramento e contraste dos visuais para mobile. Movimento deve ter finalidade, respeitar prefers-reduced-motion e preservar conteúdo legível sem animação. Vídeo precisa de poster ou alternativa estática e carregamento adequado.
• Ler references/art-direction.md quando faltar identidade visual ou quando o utilizador pedir uma direção próxima da referência de Elaya. Não carregar essa receita para substituir um sistema já definido.
• Para experiências profissionais com transições ao scroll, ler references/scroll-storytelling.md. Planear o percurso entre as secções e validar o movimento ao longo da página, em vez de limitar o tratamento ao hero.
• Para um protagonista com aparência 3D que acompanha o cursor através de vídeo ou fotogramas, ler references/interactive-video-hero.md. Preparar o movimento do asset antes de o ligar à interação; escolher uma cena 3D em tempo real quando forem necessárias vistas ou respostas que o vídeo não contém.

Implementar a conversão real

Construir a página e ajustar secções de forma localizada durante a revisão. Preservar o âmbito pedido e as instruções de implementação e cobertura do projeto.

• Usar HTML semântico, hierarquia de títulos, controlos nativos, labels, foco visível e navegação por teclado. Garantir legibilidade, contraste, texto alternativo útil e alvos de toque confortáveis.
• Ligar CTAs e navegação a destinos reais. Não usar href="#" como ação comercial nem mostrar sucesso simulado.
• Para formulários, implementar os campos necessários, validação e estados de envio, sucesso e erro relevantes. Confirmar sucesso após a aceitação pelo serviço real. Não expor credenciais no cliente.
• Sem serviço de recolha definido, concluir o layout local e indicar a integração pendente. Usar uma alternativa real de contacto se tiver sido fornecida e servir o objetivo. Não declarar a captação pronta enquanto os dados não forem entregues ao destino.
• Incluir título, descrição, favicon e metadados sociais pertinentes. Canonical, domínio e imagem social devem apontar para recursos reais conhecidos.
• Decidir indexação segundo o objetivo da página e as instruções do projeto. Uma campanha não implica automaticamente noindex; um caminho pouco divulgado também não impede indexação. Previews privados e páginas que não devem aparecer na pesquisa devem usar os mecanismos apropriados.
• Não inventar políticas legais ou ligações de rodapé. Reutilizar documentos reais quando aplicáveis e identificar os que faltam para o lançamento. Analytics e rastreadores dependem do âmbito e configuração pedidos.

Verificar e lançar

• Executar as verificações exigidas pelo projeto e o menor conjunto adicional que confirme a alteração: build quando aplicável e testes do comportamento alterado quando necessários. Cobertura externa obrigatória continua a aplicar-se.
• Quando o browser estiver disponível, verificar a página renderizada em desktop e mobile: hierarquia do hero, cortes de imagem, quebras de texto, overflow, menu, teclado, CTAs e percurso de conversão. Testar formulários com dados de teste no ambiente apropriado, sem criar contactos ou compras reais inadvertidamente.
• Confirmar que fontes, imagens e vídeos carregam; que o conteúdo continua acessível sem efeitos; e que não há links mortos ou erros relevantes de consola.
• Se a verificação visual estiver indisponível, executar os checks possíveis e declarar essa limitação. Não afirmar que uma página foi vista ou testada sem o ter feito.
• Para um pedido de lançamento, concluir a publicação no destino autorizado seguindo o fluxo atual do projeto ou fornecedor. Não repetir pedidos de autorização já dados. Um pedido de proposta, mockup ou trabalho local termina nesse âmbito.
• Após publicar, verificar o estado devolvido pelo fornecedor e, quando acessível, abrir o URL final e confirmar a página e os destinos dos CTAs. Preservar a audiência existente; não tornar uma página pública sem autorização para essa alteração.
• Na entrega, indicar onde ver o resultado, o que foi verificado e qualquer pendência concreta de integração, conteúdo ou acesso. Distinguir versão local, preview privado e publicação pública.

Origem

Adaptação própria da ideia e do fluxo de landing-page-design, por Elaya, partilhados nesta publicação. A licença MIT do original está preservada em LICENSE.

A adaptação restringe o âmbito a landing pages, preserva a identidade de cada projeto, substitui regras estéticas universais por escolhas contextualizadas e acrescenta integração real, acessibilidade, verificação e lançamento. O material do autor não substitui as instruções desta versão.