Como briefar um projeto web (guia pro cliente)

O briefing que ninguém faz direito

A maioria dos projetos web começa com uma conversa vaga. “Quero um site moderno.” “Preciso de um sistema pra minha empresa.” “Faz algo parecido com esse site aqui.” O dev interpreta do jeito dele, começa a construir, e na metade o cliente fala “não era isso que eu queria.”

O retrabalho que vem depois custa tempo, dinheiro e paciência dos dois lados. E quase sempre é causado pelo mesmo problema: briefing ruim ou inexistente.

Esse post é pra você que está contratando um dev. Não precisa ser técnico. Precisa responder as perguntas certas antes do trabalho começar. Quanto mais claro o briefing, menos surpresa na entrega.

O que o dev precisa saber (e você precisa responder)

1. Qual o objetivo do site

“Ter presença online” não é objetivo. É consequência. Objetivo é o que você quer que aconteça quando alguém acessa o site.

Exemplos concretos:

• “Quero que pacientes agendem avaliação pelo WhatsApp” (captação)
• “Quero aparecer no Google quando pesquisam [serviço] em [cidade]” (SEO local)
• “Quero que clientes façam pedido sem ligar pro escritório” (automação)
• “Quero mostrar meu portfólio pra fechar contratos em reunião” (apresentação)

Cada objetivo muda a estrutura do site, as seções, os CTAs e a estratégia de conteúdo. Site pra captação é diferente de site pra apresentação. Sem saber o objetivo, o dev constrói o que acha que faz sentido, não o que resolve o seu problema.

No Family Pilates, o objetivo era claro: captar alunos novos via Google orgânico. Isso definiu tudo: SEO local como prioridade, Schema.org de LocalBusiness, seção de depoimentos, CTA de WhatsApp em todas as seções. Se o briefing fosse “faz um site bonito”, o resultado seria diferente e provavelmente pior.

2. Quem é o público

Quem vai acessar o site? Idade, contexto, nível de familiaridade com tecnologia. Isso muda linguagem, design e até a plataforma.

Gestor de obra de 50 anos acessando pelo celular no canteiro é diferente de designer de 25 anos acessando pelo MacBook no escritório. O primeiro precisa de botões grandes, texto legível e carregamento rápido em 3G. O segundo tolera mais complexidade visual.

No Tok Final, o público são gestores de obra e construtoras. Linguagem técnica, sem floreio, site que funciona em conexão ruim. No Soline, o público são empresários interessados em energia solar. Linguagem de investimento e retorno, com dados concretos de economia.

Se você não sabe quem é o público, o dev não sabe pra quem está construindo.

3. O que o concorrente faz

Não pra copiar. Pra entender o que funciona e o que não funciona no seu mercado. Mande 3-5 links de concorrentes e diga o que gosta e o que não gosta em cada um.

“O site do Dr. Fulano é bonito mas não tem preço.” “O site da clínica X carrega rápido mas o design é datado.” “O site do concorrente Y tem blog com conteúdo bom.”

Essa análise economiza horas de conversa. O dev entende o nível do mercado, o que o público espera, e o que diferencia você.

4. Qual conteúdo você já tem

Textos prontos? Fotos profissionais? Logo em alta resolução? Vídeo institucional? O que você já tem e o que precisa ser criado?

Conteúdo é a parte que mais atrasa projeto. O dev termina o layout em 2 semanas e espera 3 semanas pelo texto e pelas fotos. Se você sabe que não tem conteúdo pronto, combine isso no início. O dev pode ajudar com copy (ou indicar quem faz) e você pode agendar fotógrafo em paralelo ao desenvolvimento.

Na minha experiência, o ideal é ter pelo menos textos rascunhados e fotos brutas antes de começar. Não precisa ser perfeito. Precisa existir. Copy final e otimização de imagens fazem parte do processo de desenvolvimento.

5. Referência visual

Mande exemplos de sites que você gosta. Não precisa ser do mesmo ramo. Pode ser “gosto da paleta de cores desse site”, “gosto da tipografia desse outro”, “quero essa sensação de leveza”. Referência visual é muito mais útil que descrições como “moderno” ou “clean”, que significam coisas diferentes pra cada pessoa.

3 a 5 links com comentários curtos sobre o que gosta em cada um já resolve. Se você tem logo e paleta de cores definida, mande também. Se não tem, o dev pode sugerir.

6. Orçamento e prazo

Parece óbvio, mas muita gente omite orçamento por medo de “pagar mais do que precisa”. O efeito é o oposto: sem saber o orçamento, o dev pode propor algo que custa 3x o que você pode pagar, e os dois perdem tempo.

Não precisa ser valor exato. Uma faixa funciona: “meu orçamento é entre R$ 3 e R$ 5 mil” ou “não quero gastar mais que R$ 8 mil”. Isso permite ao dev propor um escopo que cabe no investimento.

Pra referência de faixas de preço reais, detalhei tudo no post sobre quanto custa um sistema web. Landing page, webapp simples, webapp completo, SaaS MVP. Cada faixa com exemplos concretos.

Prazo também importa. “Preciso pro mês que vem” é diferente de “não tenho pressa”. Prazo apertado pode aumentar o custo (prioridade sobre outros projetos) ou reduzir o escopo (menos features na primeira versão).

O formato do briefing

Não precisa ser documento formal. Pode ser um email, um documento no Google Docs, ou até mensagens organizadas no WhatsApp. O importante é que as informações estejam registradas, não só faladas.

Estrutura simples que funciona:

1. Objetivo: o que quero que o site faça
2. Público: quem vai acessar
3. Concorrentes: 3-5 links com comentários
4. Conteúdo disponível: o que tenho pronto
5. Referência visual: sites que gosto
6. Orçamento: faixa de investimento
7. Prazo: quando precisa estar no ar
8. Extras: qualquer informação relevante

Se você preencher esses 8 pontos, o dev tem material suficiente pra montar uma proposta precisa. Sem esses pontos, a proposta é chute.

O que acontece com um bom briefing

Com briefing claro, o dev monta uma proposta detalhada: escopo definido, seções listadas, prazo estimado, preço fechado. Você sabe exatamente o que vai receber, quando e por quanto.

No meu fluxo, o briefing vira um arquivo .md de especificação. Esse arquivo tem: seções do site, copy de cada bloco, paleta de cores, tipografia, metas de performance e regras de SEO. O cliente aprova o spec antes de eu escrever uma linha de código. Qualquer mudança depois da aprovação segue as regras de mudança de escopo.

O resultado: menos retrabalho, menos surpresa, menos “não era isso que eu queria”. O briefing não é burocracia. É o investimento de 1 hora que economiza 10 horas de retrabalho.

No GPM2, o briefing foi feito numa reunião de 40 minutos. Objetivo claro (captar leads de empresas que precisam de consultoria tributária), público definido (empresários e contadores), referências visuais (3 sites de consultorias premium). Com isso, montei o spec completo e o site foi aprovado na primeira apresentação. Zero rodada extra de revisão.

Erros comuns no briefing

“Faz igual esse site.” Copiar site de concorrente não funciona por vários motivos: você não sabe o que funciona naquele site (pode ser bonito e não converter), o público pode ser diferente, e copiar design é eticamente questionável. Use como referência, não como modelo.

Briefing por telefone sem registro. Conversa por telefone é ótima pra alinhar, mas se não ficar registrado em texto, você e o dev vão lembrar coisas diferentes. Combine por ligação, registre por escrito.

Escopo infinito. “Quero um site com blog, área de membros, e-commerce, agendamento, chat ao vivo e integração com 5 sistemas.” Isso não é MVP, é produto de 6 meses. Priorize. O que precisa funcionar no dia 1? O resto entra depois.

Feedback vago. “Não gostei” não ajuda. “O título tá grande demais, a cor do botão não combina com a marca, e a seção de depoimentos precisa de foto real” ajuda. Quanto mais específico o feedback, mais rápido o ajuste.

Checklist de briefing

• Objetivo do site definido em uma frase
• Público-alvo descrito (quem, idade, contexto de acesso)
• 3-5 links de concorrentes com comentários
• Lista de conteúdo disponível (textos, fotos, logo)
• 3-5 links de referência visual com comentários
• Faixa de orçamento informada
• Prazo de entrega combinado
• Tudo registrado por escrito (email, doc ou mensagem)

Preencher esse checklist antes de falar com o dev é o melhor investimento de tempo que você pode fazer no projeto. O resultado é uma proposta mais precisa, um desenvolvimento mais rápido e uma entrega que realmente resolve o problema.