Criação de Landing Pages

O que Criação de Landing Pages faz?

Isso captura como Favour realmente constrói landing pages que não parecem modeladas, destilado de suas próprias conversas passadas construindo Allowance, didii, Revolut Founder Mode, TrashPay e o site da conferência FlutterBytes, e aprimorado repetidamente por seu feedback direto em builds de teste feitos com esta skill. Não é um guia genérico de "melhores práticas para landing pages" — é específico para o que ele continua buscando, corrigindo e recusando. É também um documento vivo: verifique references/build-log.md antes de começar e adicione a ele após terminar.

O objetivo de cada vez: algo com um ponto de vista genuíno, não um template competente com o nome do cliente trocado. E, crucialmente: um conceito que pareça óbvio e intencional à primeira vista, não um que só faça sentido quando explicado.

---

Antes de tudo: há informações suficientes para trabalhar?

Se o briefing não fornecer um produto real para ancorar um conceito — nenhum nome, nenhuma noção de para quem é, nenhuma dica de tom, nada que o separe da versão genérica desta ideia — pare e pergunte. Uma ou duas perguntas afiadas são melhores do que inventar uma direção provisória e descobrir depois que não servia.

Mais dois momentos específicos para perguntar em vez de assumir:

• Se uma seção se beneficiaria claramente de uma foto real (não uma representação abstrata ou vetorial), peça uma antes de prosseguir. Se não estiver disponível, diga isso e improvise com gradientes e trabalhos de linha em vez de simular uma foto de banco de imagens.
• Se uma seção precisar de conteúdo de amostra representativo (nomes de exemplo, cartões de amostra, dados provisórios), proponha uma versão primeiro e convide explicitamente a mudanças, em vez de finalizar tranquilamente seu próprio palpite.

Se houver o suficiente — um nome real, um público real, um ponto de diferença real, mesmo que aproximado — prossiga.

---

Stack de construção

O alvo padrão é Next.js, TypeScript, Tailwind CSS e Framer Motion. Essa é a stack real por trás de cada projeto do qual esta skill foi extraída. Nunca HTML simples ou JS vanilla como entregável.

Se o ambiente de trabalho não puder renderizar essa stack ao vivo, diga isso claramente em vez de substituir silenciosamente por algo mais fraco. Ainda assim, construa componentes React reais, nunca JS vanilla, e aproxime a animação pretendida com transições CSS ou a Web Animations API para a pré-visualização — mas ofereça o código Next.js/TypeScript/Framer Motion real como arquivos para download também, e diga claramente se um ambiente que pode realmente executar e capturar essa stack (Claude Code, por exemplo) é onde isso pertence, especialmente quando o julgamento visual real sobre a saída começa a importar mais do que uma olhada rápida.

---

Formulários sempre enviam para um Google Form

Qualquer formulário no site — lista de espera, contato, consulta, inscrição para palestrar, pedido/reserva, seja o que for — é um formulário personalizado e construído sob medida no design do próprio site cujas submissões são encaminhadas para um Google Form nos bastidores através do link de pré-preenchimento desse formulário. O visitante nunca vê um Google Form bruto; eles veem o estilo do site, e os dados caem nas respostas do Google Form (e em sua planilha de respostas vinculada).

Peça isso cedo, assim que estiver claro que o site precisa de um formulário — é uma dependência da pessoa, como as fotos são. Peça a eles que criem um Google Form com campos que correspondam ao que o formulário do site coleta e que enviem de volta seu link de pré-preenchimento. Em seguida, mapeie cada campo no site para o ID de entrada do Google Form correspondente analisado desse link de pré-preenchimento e envie para ele no manipulador de envio do formulário (a abordagem padrão é um POST para o endpoint /formResponse do formulário com os parâmetros entry.<id>, ou um equivalente). Se a pessoa ainda não forneceu o link, construa a IU do formulário personalizado completamente, mas deixe o destino do envio claramente marcado como stub e sinalizado, em vez de inventar um endpoint.

Sempre dê à pessoa as etapas para buscar o link de pré-preenchimento de um Google Form, já que a maioria das pessoas não sabe onde encontrá-lo:

1. Abra o Google Form no modo de edição.
2. Clique no menu de overflow de três pontos ⋮ no canto superior direito.
3. Escolha "Obter link de pré-preenchimento".
4. Preencha cada campo com um valor de placeholder reconhecível (por exemplo, digite o nome do próprio campo nele) e clique em "Obter link" na parte inferior.
5. Clique em "Copiar link" no pop-up e envie-o.

Esse link contém cada entry.<id> do campo e é exatamente o que é necessário para mapear os campos do formulário personalizado para o Google Form.

---

Tipo e cor, escolhidos com a pessoa, não decididos sozinhos

Antes de se comprometer com qualquer um, faça uma breve verificação visual em vez de decidir silenciosamente:

• Tipo: verifique references/typeface-library.md para candidatos não usados recentemente, então proponha três candidatos de fonte de exibição distintos e não óbvios e renderize o nome do produto real em cada um, da forma que o ambiente suportar (uma imagem, uma pré-visualização rápida, um componente ao vivo) — nunca apenas liste nomes de fontes como texto. Deixe a pessoa escolher a partir de letras reais, não de um palpite sobre como um nome soa. Uma fonte genuinamente nova fora da biblioteca também é uma opção bem-vinda — se for escolhida, adicione-a a references/typeface-library.md depois. Nunca pule esta etapa de proposta e confirmação — mesmo quando uma recomendação forte for óbvia ou uma fonte da biblioteca já for ser usada, ainda assim exiba os candidatos e confirme em vez de decidir silenciosamente.
• Cor e tema: proponha uma paleta (4–6 valores nomeados) com a justificativa por trás de cada escolha fundamentada no assunto, e decida o tema claro vs. escuro deliberadamente aqui, em vez de usar o escuro como padrão (veja a regra de tema em references/taste-rules.md — muitas marcas ficam melhor em claro). Confirme ambos antes que sejam finais.
• Direção de estilo: junto com tipo e cor, escolha uma família de estilo dominante para a página inteira das famílias nomeadas em references/section-bank.md (aurora/brilho pastel, brilho neo-tech escuro, orgânico clean-tech, editorial/brutalista, minimalista high-key, luxo/exibição premium, corporativo B2B/fintech) — escolhida por uma razão específica do briefing, não por hábito. Esta é a pista onde o banco de seções será pesquisado mais tarde; pegar emprestado de fora dela é um acento deliberado, não um padrão.

Ambos os builds de teste até agora pularam isso e decidiram ambos sozinhos — funcionou bem duas vezes, mas isso é sorte, não o processo funcionando como pretendido.

---

Tipo de site primeiro

Descubra qual das sete formas isso é antes de qualquer outra coisa — as regras de bom gosto e a estrutura abaixo se aplicam a todas elas, mas o inventário de seções e, para os tipos de negócio, europeu e mini-negócio, a abordagem visual diferem:

• Página de produto (Allowance, didii, TrashPay) — focada em lista de espera ou download, preços, casos de uso, grade de recursos.
• Portfólio / página de estudo de caso (Revolut Founder Mode) — uma proposta de conceito do próprio designer: um bloco de biografia, estatísticas do mundo real para justificar relevância, "entre em contato" em vez de uma lista de espera.
• Página de evento / conferência (FlutterBytes) — vitrine de palestrantes, histórico de edições passadas, créditos da equipe organizadora, patrocinadores, agenda.
• Página de negócio (uma marca de moda, uma padaria, um salão, um estúdio — um negócio real estabelecido, não uma startup) — vende um produto ou serviço real que já existe, então é pesada em imagens e focada em atmosfera, em vez de focada em grade de recursos. Procure que cerca de 75% das seções sejam construídas em torno de fotografia real (cardápio/lookbook/galeria/espaço), com as regras de movimento característico e animação aplicadas sobre as imagens, em vez de substituí-las.
• Híbrido — uma mistura deliberada de dois ou três dos acima (um produto que também está promovendo um evento, um negócio com um portfólio de trabalhos passados). Escolha o tipo dominante para a estrutura geral e o espaçamento, depois pegue emprestadas as seções específicas que o tipo secundário precisa.
• Site europeu — um site limpo, contido e com sensação premium no estilo de trabalho de estúdio europeu/modelo Framer de alta qualidade. Mesmas bases que os outros, mas o herói é deliberadamente simples: uma ou mais fotografias reais adequadas (buscadas e baixadas do Unsplash, Pexels ou Pixabay) definidas como fundo do herói dentro de um quadro retangular arredondado de ~98% de largura, sem nenhum conceito visual movimentado sobreposto. Sem lista de espera. Simples, mas não chato.
• Página de mini-negócio — uma página única apertada e premium, exatamente quatro seções (herói, oferta, prova, contato), construída para promover negócios estabelecidos, muitas vezes tradicionais, que ainda não têm presença na web — revendedores de máquinas, exportadores a granel, fabricantes, fornecedores industriais, atacadistas. Esta tem que ser convincente o suficiente por si só para fazer um negócio sem site acreditar em ter um, então aposta pesadamente em fotografia real premium, sinais de confiança reais (estatísticas, logotipos de clientes, certificações) e um herói confiante e variado — veja references/site-types.md para as cinco iterações de herói entre as quais alternar e a seção obrigatória de Fale Conosco.

Leia references/site-types.md para o inventário de seções e notas estruturais para cada uma. Se for genuinamente nenhuma destas, trate como mais próxima de uma página de produto e adapte.

---

O processo

1. Oriente-se. Nome da marca, o que faz, para quem é, qualquer site de referência ou clima nomeado. Se estiver claro que o site precisará de um formulário (lista de espera, contato, consulta, pedido), levante a dependência do Google Form agora, conforme a seção de formulários acima — peça à pessoa que crie o Google Form e envie seu link de pré-preenchimento, para que não seja uma correria no final.

2. Encontre o conceito central único antes de tocar em qualquer seção. Não uma lista de recursos — a única coisa que o usuário realmente obtém ou sente deste produto, declarada como uma frase simples, mais duas ou três ideias de apoio. O movimento característico de cada seção será verificado em relação a isso mais tarde. Pergunte também diretamente à pessoa se ela já tem conceitos, visuais ou ideias que adoraria incluir ou ilustrar — especialmente para o herói — para que sua própria visão alimente o conceito, em vez de ser substituída por um inventado.

3. Escolha tipo e cor com a pessoa (acima), fundamentados no assunto, não decididos sozinhos.

4. Decida o tipo de site (acima) e folheie seu inventário de seções. Verifique references/build-log.md para o que os projetos recentes usaram, para que este não rime com o anterior por acidente.

5. Execute cada seção pela lista de verificação de admissão abaixo, lado a lado, depois avalie honestamente antes de escrever qualquer layout ou código.

   Intake, por seção:

   • O que é esta seção e quanto peso visual ela merece? Um herói merece mais do que um bloco de confiança.
   • Sobre o que é o produto em geral e sobre o que é esta seção especificamente, com base em seu título real, subtítulo e conteúdo — não um rótulo genérico para sua categoria?
   • Qual conceito segue desse conteúdo, especificamente? Verifique references/concept-gallery.md para conceitos já inventados — reutilize um que não esteja esfriando, adapte um ou invente algo novo e adicione lá depois.
   • O que o banco de design de seções oferece? Puxe duas ou três linhas candidatas de references/section-bank.md (combinadas por categoria de seção, depois pela direção de estilo do projeto), pese-as contra uma opção inventada do zero e adapte a vencedora de acordo com as regras de adaptação-nunca-transplante do banco — a paleta da linha, os tipos de letra e as especificações de pixel são remapeados para este projeto, e a seção ainda tem que passar no teste de dois segundos para esta marca específica.
   • Que animação ou interação de hover dá vida a ela? A coluna de movimento do banco é um vocabulário para se basear aqui (desenhos com deslocamento de traço, contagens de odômetro, expansões de flex-grow, entradas escalonadas, revelações de máscara) — ainda assim, nunca a mesma primitiva duas vezes em uma página.
   • Qual é o comprimento do título e subtítulo? Os curtos podem carregar um tratamento centralizado/cercado (veja os arquétipos de layout em references/taste-rules.md); os mais longos não podem.
   • Qual layout e qual movimento característico a seção imediatamente anterior a esta usou, e o que o último projeto usou? Não repita nenhum dos dois.

   Avalie honestamente, usando verificações falseáveis em vez de números confortáveis:

   • O conceito cai em um dos três padrões genéricos de design de IA (creme quente + serifa + terracota, quase preto + um acento ácido, ou estilo jornal/folha com regra fina) sem uma razão específica do briefing? Isso é uma falha — volte para o intake.
   • Esta escolha exata apareceria se o mesmo prompt fosse executado para um produto completamente diferente? Se sim, ainda não é específico o suficiente.
   • Um estranho entenderia o que representa em cerca de dois segundos, sem legenda? Um conceito que só funciona quando explicado falhou, independentemente de quão engenhoso foi o raciocínio.

   A avaliação é uma disciplina que sempre é executada, não algo para mostrar — a pessoa vê o conceito resultante e um veredito simples, não um placar. E seja honesto sobre a limitação real: sem uma maneira de realmente ver uma renderização, a autoavaliação está mais próxima de uma revisão de código cuidadosa do que de um julgamento visual genuíno, então penda para o cético em vez de generoso. Se o ambiente puder realmente executar e capturar a build, use isso — um olhar real é melhor do que prever um.

6. Construa o primeiro rascunho completo, usando os conceitos avaliados mais as regras permanentes em references/taste-rules.md.

7. Vá seção por seção e verifique a qualidade de cada uma individualmente, em relação à página construída. Para cada seção, pergunte:

   • Esta seção se conecta visivelmente ao conceito central da etapa 2, ou apenas ilustra seu próprio recurso isoladamente?
   • O lado não textual de qualquer seção de duas colunas está realmente vivo — uma mini-interface animada, um trecho de tela ou um conceito autocontido — ou é uma imagem plana morta? Não "são duas colunas", mas "há algo aqui estático que não deveria estar"?
   • Este é um cartão com borda simples onde um divisor de desvanecimento ou algo mais pensado serviria melhor? A página inteira está ficando dentro de uma ou duas seções de uso de cartão no total? Se for um cartão, ele tem um toque de personalização real (preenchimento gradiente brilhante, borda tipo vidro, ícone animado) e uma interação de hover real?
   • Todos os ícones são da biblioteca de ícones personalizada escolhida (Lucide/Phosphor/Heroicons/Tabler), sem emojis substituindo-os?

...

[cortado para tradução]