A aprovação de protótipo de site é a etapa em que o cliente vê e valida a estrutura visual completa do projeto antes de qualquer linha de código ser escrita — e é exatamente aí que retrabalho caro é evitado. Num projeto de criação de sites profissionais, essa fase não é detalhe: ela é a separação entre o que foi combinado e o que vai ser construído.
Neste post, vou explicar como essa etapa funciona no meu processo, por que ela existe nesse ponto específico do fluxo e o que acontece quando o cliente pula ou subestima ela.
Por que o protótipo vem antes do desenvolvimento, não durante
A lógica é simples: mexer em estrutura de página no Figma custa minutos. Mexer na mesma estrutura depois que o Elementor já foi montado, os breakpoints de mobile configurados e as animações ajustadas custa horas — às vezes dias.
Quando o cliente pede para “mover aquela seção lá para cima” ou “trocar a ordem do bloco de depoimentos” durante o desenvolvimento, parece um pedido simples. Mas no código, isso pode quebrar espaçamentos, invalidar lógica de seções interligadas e gerar inconsistência nos tamanhos mobile. Daí vem o retrabalho que ninguém queria pagar e que ninguém quer assumir que causou.
A aprovação de protótipo de site existe para fechar esse ciclo antes de abrir o editor.
O que é exatamente o protótipo que eu envio
Não é um wireframe genérico de caixas cinzas. O protótipo que eu entrego é um arquivo navegável no Figma com:
- Hierarquia de seções definida (hero, proposta de valor, prova social, CTA principal, etc.)
- Tipografia, paleta de cores e espaçamentos reais — não aproximados
- Versão desktop e mobile lado a lado
- Textos de copywriting já posicionados nas seções corretas (não Lorem Ipsum)
- Indicação de quais elementos são interativos, quais são estáticos e onde ficam os CTAs
Ou seja, quando o cliente abre o link do protótipo, ele está olhando para uma representação fiel do que o site vai ser — não para uma ideia vaga que “será desenvolvida depois”.
Isso é diretamente conectado ao que levanto no briefing. Se você quiser entender como eu extraio essas informações antes de qualquer tela ser desenhada, escrevi sobre isso em como eu conduzo o briefing com cada cliente novo.
Como funciona a aprovação de protótipo de site na prática
Depois que o protótipo está pronto, envio o link junto com um resumo textual explicando as decisões estruturais que tomei — por que o hero foi construído assim, por que a seção de serviços aparece antes dos depoimentos, por que há dois CTAs em vez de um.
O cliente analisa, comenta diretamente no Figma (funcionalidade nativa da ferramenta) ou me envia por WhatsApp. Ajustes de estrutura, ordem de seções, revisão de texto ou mudança de abordagem de algum bloco: tudo isso acontece aqui, nessa fase.
Só depois que o cliente aprova formalmente — ou seja, confirma que está de acordo com o que está vendo — é que o desenvolvimento começa de verdade.
Esse fluxo faz parte do meu processo de entrega em 7 dias. Se quiser entender como cada etapa se encaixa no cronograma completo, explico isso em detalhes no post sobre como funciona meu processo de criação de site do briefing à entrega.
Aprovação de protótipo de site não é burocracia — é proteção mútua
Já ouvi de cliente: “Pode ir fazendo, eu confio em você.” Entendo o espírito, mas aceitar isso sem a aprovação formal seria um desserviço ao cliente.
O que acontece sem essa etapa? O cliente vê o site pela primeira vez já desenvolvido, com visual e funcionalidades prontas. Nesse momento, qualquer ajuste estrutural que ele queira — e vai querer, porque é a primeira vez que está vendo algo concreto — envolve refazer partes já codificadas. Isso gera atraso, custo adicional e, pior, desgaste na relação.
A aprovação de protótipo de site coloca cliente e desenvolvedor na mesma página antes do trabalho pesado começar. É um contrato visual: “é isso que nós dois combinamos que vai ser construído.”
O que pode ser ajustado no protótipo (e o que não pode mais depois)
Durante a fase de protótipo, praticamente tudo pode ser alterado sem custo adicional: ordem de seções, inclusão ou remoção de blocos, mudança de abordagem textual, ajuste de hierarquia visual, cores e tipografia.
Depois da aprovação, as revisões do projeto cobrem ajustes pontuais de conteúdo — um texto diferente aqui, uma foto substituída ali, uma cor ajustada. Reestruturação de página inteira depois de aprovada não entra nessa categoria. Escrevi sobre o que cobre cada rodada de revisão no post sobre quantas revisões estão incluídas no projeto e por que esse número existe.
Um exemplo concreto de como isso evita problema
Num projeto recente para uma profissional de saúde, o briefing indicava que ela queria “destacar os depoimentos”. Na primeira versão do protótipo, posicionei os depoimentos logo após a seção de serviços — antes do CTA principal.
Quando ela viu o protótipo, percebeu que preferia os depoimentos mais perto do fim, funcionando como última camada de convencimento antes da chamada para agendamento. Ajustamos em dez minutos no Figma.
Se essa decisão tivesse sido tomada depois do desenvolvimento, seriam pelo menos duas horas de retrabalho — ajuste de seção, reconfiguração de espaçamentos mobile, revisão dos links internos de âncora. Uma conversa de dez minutos no lugar certo evitou um problema que ninguém precisava ter.
Esse tipo de raciocínio estratégico de estrutura é o que diferencia um site construído com intenção de um site montado por estética. Falei sobre isso com mais profundidade no post sobre o que muda quando o design tem estratégia por trás.
O que o checklist de materiais tem a ver com o protótipo
A aprovação de protótipo de site só funciona bem quando o cliente já entregou os materiais necessários antes dessa fase: logo em alta resolução, fotos reais (quando existem), textos principais e referências visuais.
Quando o protótipo é montado com textos fictícios e imagens de banco de dados por falta de material, a aprovação perde precisão — o cliente aprova uma coisa e recebe outra. Por isso tenho um checklist específico que solicito antes de qualquer tela ser desenhada. Detalhei o que entra nesse checklist e por que cada item importa no post sobre o que eu peço de todo cliente antes de começar.
Pronto para ver o protótipo do seu site antes de qualquer código?
Se você quer construir um site profissional sabendo exatamente o que vai receber — sem surpresa na entrega e sem retrabalho no meio do caminho — é exatamente assim que eu trabalho.
A aprovação de protótipo de site é uma das etapas que mais geram segurança para o cliente e eficiência para o desenvolvimento. E ela começa com uma conversa sobre o seu projeto.
Me chama no WhatsApp e conta o que você precisa. Vou te explicar como o processo funciona para o seu caso específico.
→ Falar sobre meu projeto agora
Perguntas frequentes sobre aprovação de protótipo de site
O que é a aprovação de protótipo de site?
É a etapa em que o cliente visualiza e valida a estrutura visual completa do site — com seções, tipografia, cores, textos reais e versões desktop e mobile — antes de qualquer linha de código ser escrita. Ela garante que cliente e desenvolvedor estejam alinhados sobre o que será construído.
Por que a aprovação de protótipo acontece antes do desenvolvimento?
Porque alterações estruturais no Figma levam minutos, enquanto as mesmas alterações no código já desenvolvido podem levar horas ou dias. Aprovar o protótipo antes evita retrabalho caro, atrasos no prazo e desgaste na relação entre cliente e desenvolvedor.
O que pode ser alterado durante a fase de protótipo?
Praticamente tudo: ordem de seções, inclusão ou remoção de blocos, mudança de abordagem textual, hierarquia visual, cores e tipografia — tudo sem custo adicional. Depois da aprovação formal, apenas ajustes pontuais de conteúdo estão cobertos pelas rodadas de revisão do projeto.
O que acontece se o cliente pular a etapa de aprovação de protótipo?
O cliente vê o site pela primeira vez já desenvolvido. Qualquer ajuste estrutural que queira fazer nesse momento — e normalmente quer, pois é o primeiro contato com algo concreto — implica refazer partes já codificadas, gerando atraso, custo extra e desgaste desnecessário.