Design Web Futurista

O que Design Web Futurista faz?

Um método prático para sites de marketing de página única que parecem dirigidos, não gerados: um briefing claro, um sistema de design, seções construídas e verificadas individualmente, visuais que combinam como uma única sessão de fotos, e um orçamento pequeno e deliberado de movimento cinematográfico.

Por que os sites saem genéricos

Cada detalhe que uma solicitação deixa em aberto é preenchido com a escolha estatisticamente mais provável. Uma solicitação de uma linha, portanto, produz o site médio: cabeçalho centralizado, gradiente suave, uma fileira de cartões arredondados idênticos. A maior parte do trabalho real acontece antes de qualquer código. Fixe as perguntas em aberto (público, a única ação desejada, a sensação, as tipografias, a paleta) e então construa em incrementos pequenos o suficiente para serem inspecionados visualmente.

Mantenha os papéis claros. O usuário é dono do que é construído. Você é dono do como. E nenhum trabalho está terminado até que alguém o tenha olhado em um navegador na largura de um telefone.

Por onde começar

Situação	Vá para
Site novo, pasta vazia ou quase vazia	Fase 1, depois direto adiante
Site existente, uma seção para adicionar ou reconstruir	Leia as regras do projeto, depois a rotina de seção na Fase 5
"Torne isso cinematográfico / 3D / com rolagem"	Fase 7 e references/cinematic-moves.md
Imagens, vídeo do herói ou prompts para eles	references/assets.md
O site parece genérico ou feito por IA	Audite-o contra "Sinais de um site genérico" em references/design-system.md, depois Fase 3
Ajustes para celular, polimento, formulário, deploy, domínio, SEO	references/ship.md

Abra um arquivo de referência ao atingir sua fase, não antes. Cada um é independente.

As fases

1. Briefing

Um único parágrafo, escrito antes de qualquer código, cobrindo três pontos: o público, a única coisa que um visitante deve fazer e a sensação pretendida (três adjetivos e uma comparação, por exemplo "tranquilo, preciso, generoso, como um estúdio bem administrado em uma manhã de semana").

Quando o usuário não forneceu isso, solicite-o em uma única mensagem. Quando ele disser para simplesmente prosseguir, redija o briefing você mesmo, declare-o como uma suposição em uma linha e prossiga. Escolhas posteriores (o botão dominante, quais seções existem, qual movimento justifica seu peso) são todas resolvidas relendo este parágrafo. Essa é a razão pela qual não pode ser pulado.

2. Plano

Escreva a lista de seções de cima para baixo. Cada entrada dá o propósito da seção em uma frase e nomeia o ativo do qual depende. Não construa ainda. Antes que algo exista, mudar de direção é gratuito, portanto, para trabalhos que abrangem vários arquivos, apresente o plano e aguarde a concordância. Use o modo de plano onde o agente tiver um.

Uma ordem de execução típica: navegação, herói, faixa de confiança, a oferta, história ou processo, depoimentos de clientes, preços quando relevante, perguntas frequentes, chamada para ação de encerramento, rodapé. Remova seções cujo propósito você não consegue declarar. Para um negócio real, nunca invente clientes, avaliações ou estatísticas; omita a seção ou solicite o material genuíno.

3. Sistema de design

Fixar a aparência uma única vez para todo o site e registrá-la. Apresente três direções candidatas em uma página de pré-visualização básica, para que a escolha seja feita visualmente. Cada uma combina uma tipografia de título com uma tipografia de leitura, atribui cinco cores hexadecimais para funções (página, tinta, primária, destaque, suave), e resume seu clima em uma frase. Codifique a vencedora nos tokens de tema do projeto e, em seguida, exclua a página de pré-visualização. Páginas de exploração são andaimes: se permanecerem no projeto, elas vão para o ar com o site.

references/design-system.md tem os detalhes, o vocabulário e um modelo.

4. Regras do projeto

Coloque as regras permanentes no arquivo de regras que o agente atual carrega na inicialização (CLAUDE.md, AGENTS.md, GEMINI.md). Reutilize um arquivo existente; caso contrário, crie o arquivo correto para este agente. Como ele é carregado a cada sessão, mantenha-o breve: o que é o site, a stack, o sistema de design, algumas regras fixas.

Padrões razoáveis quando o projeto ainda não tem opinião:

• Stack: Next.js e Tailwind CSS. Para widgets interativos (accordion, diálogo, menu, inputs), instale uma biblioteca de componentes acessível como shadcn/ui; não os implemente manualmente.
• Cada componente em seu próprio arquivo sob components/.
• Celular primeiro. 390px é a largura que nada pode quebrar.
• Apenas texto genuíno. Sem lorem ipsum, sem "Recurso um".
• Obtenha aprovação antes de adicionar um pacote e explique seu propósito.
• Movimento reduzido significa todo movimento: rolagem suave, transições de hover e ícones incluídos, não apenas os efeitos de destaque.

Regras permanentes pertencem a este arquivo. A tarefa atual não.

5. Construir seção por seção

Pedir uma página inteira de uma vez retorna uma página de seções medíocres sem um ponto de partida claro para reparos. Construa uma seção, verifique-a, continue. Uma vez que o padrão esteja estabelecido, as seções finais mais simples (depoimentos, perguntas, chamada para ação final, rodapé) podem ser agrupadas. Qualquer coisa visualmente importante é construída sozinha.

A rotina de seção, para cada seção adicionada ou reconstruída:

1. Leia as regras e tokens de design primeiro.
2. Confirme o conteúdo. Onde os fatos importam (preços, alegações, citações), pergunte. Em outros lugares, escreva texto genuíno e sinalize as linhas que você inventou.
3. Dê à seção um arquivo de componente próprio.
4. Renderize em três larguras: celular (390px), tablet (768px), laptop (1440px). Repare estouros, quebras feias e cortes ruins.
5. Compare os espaços acima e abaixo com os das seções adjacentes.
6. Feche com um breve relatório: a seção, seu caminho de arquivo e o que precisar dos olhos do usuário.

Gaste o máximo esforço no herói, pois ele determina se os visitantes rolam a página ou não. Especifique cada detalhe importante:

• Um título de aproximadamente oito palavras no máximo que declare o que está sendo oferecido, uma única frase de suporte e uma navegação contendo a marca, alguns links e um único botão.
• Um botão de ação principal claro: preenchido, cor de destaque, vinculado à ação do briefing. A ação secundária se torna um link de texto discreto. Botões gêmeos de igual peso sinalizam que nenhuma decisão foi tomada.
• Texto posicionado longe do assunto focal do visual, decidido para desktop e celular de forma independente.
• Para texto sobre vídeo ou fotografia, resolva a legibilidade localmente com um degradê sob o texto. Não escureça todo o visual.
• Julgue a primeira tela a partir de uma captura de tela nas larguras de celular e desktop. Uma grande faixa vazia, um elemento solitário que parece clip art, ou um visual muito escuro para ser visto significa que o herói não está pronto, mesmo enquanto o ativo real ainda for um placeholder: o substituto tem que sustentar a composição até lá.

Cada botão leva a algum lugar. Cada chamada para ação precisa de um destino real: um link de loja ou checkout, uma página de reserva, um formulário, um endereço de e-mail. Quando o destino for desconhecido, use o destino honesto mais próximo (a seção de produto, um link mailto) e liste cada botão não conectado em seu relatório. Um botão que rola silenciosamente para a mesma página parece terminado e não está.

Com a página montada, role por ela de ponta a ponta, identifique a seção mais fraca (sempre há uma) e proponha duas alternativas para ela em rotas de pré-visualização. Depois que uma for escolhida, exclua as outras variantes e suas rotas.

6. Visuais

Um layout forte não pode resgatar imagens fracas. Comece com uma pequena lista de cerca de sete assets e mantenha uma única linha de estilo (luz, lente, paleta) constante entre eles. Fórmulas de prompt, orientação para vídeo de herói e preparação para web estão em references/assets.md.

Sem um gerador de imagem ou vídeo conectado, forneça os prompts ao usuário e continue com placeholders claramente marcados. Nunca gaste créditos de geração sem aprovação.

7. Movimentos cinematográficos

Cinco técnicas estão no menu: um vídeo de fundo lento no herói, movimento vinculado à posição de rolagem, uma seção que fixa enquanto seu conteúdo muda, profundidade parallax e um objeto 3D renderizado ao vivo. Gaste com moderação: o vídeo do herói e não mais do que dois dos restantes, cada um posicionado onde esclarece algo ou cria uma sensação específica. Usar todas as técnicas de uma vez parece um demo reel, cansa o visitante e dilui cada efeito.

Cada técnica precisa de fallbacks elegantes: um layout comum sob movimento reduzido, uma imagem estática em celulares pequenos e uma página que sobreviva ao efeito falhando. Depois, meça o custo. Receitas e proteções estão em references/cinematic-moves.md; leia-o antes de escrever código de rolagem ou 3D.

8. Celular, polimento, formulário, lançamento

Celulares respondem pela maioria das visitas. Execute uma passagem dedicada em 390px, uma passagem de consistência e uma verificação de velocidade; em seguida, conecte o formulário, faça o deploy e trabalhe na checklist de lançamento. Veja references/ship.md.

Hábitos de trabalho

Estes valem durante todo o processo.

• Uma mudança por rodada. Ao receber um pedido de correção, altere apenas aquilo e nada mais. Um diff mais amplo que a solicitação esconde qual edição ajudou, e "arrumar" algo com que o usuário estava satisfeito é uma regressão.
• Olhe antes de relatar. Carregue a página e inspecione-a em várias larguras antes de considerá-la pronta. Layouts podem satisfazer todas as regras e ainda parecer estranhos.
• Transforme feedback vago em um problema nomeado. "Está pesado" é trabalhável: determine se o espaçamento, o peso ou o contraste são responsáveis, diga isso e ajuste apenas isso. Se o usuário não conseguir articular uma preferência, coloque duas ou três variantes em rotas de pré-visualização com uma descrição de uma linha cada. As pessoas escolhem mais facilmente do que especificam.
• Rastreie surpresas ao que não foi especificado. Quando a saída não for o que o usuário esperava, encontre a pergunta em aberto por trás dela e resolva-a no arquivo de regras, para que não seja corrigida manualmente novamente.
• Corrija erros na raiz e declare a causa em uma linha.
• Salve estados funcionais. Em um projeto git onde o usuário quer commits, commite após cada etapa funcional com uma mensagem que faça sentido semanas depois.
• Proteja chaves e dados. Segredos pertencem a .env.local e ficam fora de arquivos fonte e do histórico do git. Quando um formulário se recusar a salvar, repare a regra de acesso. Nunca desative a segurança para fazê-lo funcionar.
• Relate honestamente. Declare o que foi verificado, o que não pôde ser (um iPhone físico, o domínio de produção) e qual texto é inventado. Uma confirmação na tela não prova nada; a linha armazenada sim.
• Verifique versões. Para GSAP, Three.js, React Three Fiber, Motion e Lenis, consulte a documentação atual sobre versões compatíveis em vez de confiar na memória, e sinalize incertezas.

Arquivos de referência

Arquivo	Leia quando
references/design-system.md	Escolher tipografias, cores e espaçamento; converter palavras de estilo vagas em concretas; auditar uma página de aparência genérica
references/assets.md	Escrever prompts de imagem ou vídeo, manter visuais consistentes, comprimir mídia para a web
references/cinematic-moves.md	Adicionar um vídeo herói, história de rolagem com pinagem, parallax, destaque 3D, vídeo guiado por rolagem ou uma história completa de rolagem 3D ao vivo
references/ship.md	Posicionar mídia, passagem para celular, polimento, velocidade, formulário de contato, deploy, domínio, SEO e a checklist de lançamento