Wireframes e protótipos: porque o site deve ser desenhado antes de feito

Quase todos os projetos de site mal corridos partilham um momento: o cliente vê o site em HTML real, no browser, e descobre que "afinal não é assim que imaginava". Nessa altura, foram 3 semanas de programação, 12 secções construídas e a margem do orçamento já desapareceu. Tudo isto evita-se com um passo simples — desenhar antes de construir.

Wireframes, mockups e protótipos são esse "antes". Não são luxo de agência cara — são proteção do cliente, do estúdio e do prazo. Este guia explica os três níveis, qual usar quando, e como aprovar sem rondas infinitas.

Wireframe, mockup, protótipo: três coisas, três decisões

Os três termos confundem-se. A distinção prática:

Nível	O que mostra	Para quê
Wireframe	Caixas, hierarquia, o que vai onde	Aprovar estrutura e fluxo
Mockup	Visual final — cores, fontes, fotos, espaçamentos	Aprovar estética e tom
Protótipo	Mockup com interação clicável	Testar fluxo de uso

Um wireframe responde "isto faz sentido?". Um mockup responde "está bonito?". Um protótipo responde "consigo encontrar o que procuro?". Os três servem três conversas diferentes — e tentar tudo numa só fase é onde a maioria dos projetos se enrosca.

Porque o wireframe vem sempre primeiro

A tentação típica do cliente: "passa logo para o bonito". A tentação típica do estúdio mau: aceitar. Resultado: discussão estética sobre uma estrutura que ainda não foi validada. O wireframe ataca o problema certo na ordem certa.

O que o wireframe valida:

• Hierarquia da informação — o que aparece acima da dobra, o que vem a seguir.
• Fluxo do utilizador — de onde vem, para onde vai.
• Densidade — quantas secções, quantos cliques.
• Mobile vs desktop — onde corta, onde reordena.

Quando isto está validado, discutir cores e fontes é honesto. Sem isto validado, o cliente diz "gosto" do mockup mas dois dias depois lembra-se que "afinal precisava de uma secção de testemunhos antes do CTA" — e refaz-se tudo.

A Nielsen Norman Group documenta o custo de mudar tarde no projeto vs cedo: alterar estrutura no wireframe custa minutos; alterar no código custa horas a dias. Ver Paper Prototyping da NN/g.

Wireframe de baixa vs alta fidelidade

Há duas escolas no wireframe:

• Baixa fidelidade — esboço a lápis ou caixas cinzentas no Figma. Lê-se em segundos. Foca o cliente na estrutura.
• Alta fidelidade — wireframe já com tipografia certa, espaçamentos finais, mas a cinzento. Mais perto do mockup.

Para uma PME portuguesa sem equipa de design interna, baixa fidelidade ganha em 90% dos casos — o cliente percebe que está a aprovar estrutura, não estética. Wireframes muito polidos confundem ("já está pronto?") e geram comentários estéticos prematuros.

Ferramenta padrão em 2026: Figma. Alternativas: Whimsical, Balsamiq, FigJam, ou mesmo papel + caneta. A ferramenta importa menos do que o critério.

Mockup: onde o cliente decide o "look"

Com wireframe aprovado, o mockup aplica:

• Palete de cores (1 primária + 1 acento + 3 neutros — já discutido em branding para pequenas empresas).
• Tipografia (par escolhido, hierarquia H1-H6, espaçamento).
• Fotografia / ilustração (reais ou stock).
• Iconografia.
• Espaçamentos finais (8px ou 4px grid).
• Estados (hover, ativo, erro de formulário).

O mockup é geralmente entregue em 3 telas-chave: Home, página interior modelo (ex.: Sobre ou Serviço), e formulário/contacto. Não é preciso desenhar as 7 páginas todas em Figma — desenhar 3 e replicar padrões nas restantes.

Protótipo: quando vale o esforço

Protótipo é mockup com cliques. Em Figma, ligam-se telas com transições.

Quando faz sentido criar protótipo:

• Fluxos de conversão complexos — checkout de loja online, formulário multi-passo, marcação de consulta com seleção de horário.
• Validação com utilizadores reais antes de programar — testes com 3-5 pessoas detetam 80% dos problemas (regra clássica de UX).
• Apresentação a stakeholders que não percebem mockup estático.

Quando não faz sentido:

• Site institucional simples de 5 páginas. O Figma estático chega.
• Cliente pequeno sem tempo para revisões com utilizadores.

Mobile-first no Figma: ordem e prioridade

Em 2026, mais de 60% do tráfego em sites de PME portuguesas vem de telemóvel. Desenhar primeiro em desktop e "adaptar para mobile" produz mobile mau.

O processo correto:

1. Wireframe em mobile primeiro (375px-414px).
2. Wireframe em desktop (1280px+) como segunda passagem.
3. Mockup em mobile primeiro, depois desktop.
4. Tablet é geralmente derivação simples — raramente precisa de design dedicado.

Ver mobile-first: porque o teu site se desenha primeiro para telemóvel para o detalhe técnico, e o guia Responsive Web Design Basics do web.dev.

Como o cliente aprova sem 5 rondas

Aprovação descontrolada mata prazos. Regra que funciona:

• Máx 2 rondas de wireframe. Primeira com input livre. Segunda com ajustes. Terceira: extra à parte, com custo declarado.
• Comentários por escrito, dentro do Figma (comments) ou em documento numerado. Não em chamadas sem registo.
• Aprovação por escrito explícita — "aprovo o wireframe para avançar para mockup, com os seguintes 4 ajustes". Sem isto, o estúdio não avança.
• Janela curta — 48-72h para feedback. Mais do que isso, o projeto perde momentum e o cliente esquece o contexto.

Quando o cliente ultrapassa o número de rondas combinado, há duas saídas honestas: cobrar extra com transparência ("ronda 3 é 200€ adicional"), ou parar a fase e fechar o âmbito.

Wireframe e a poupança no orçamento

Wireframe parece custo extra. É poupança real.

Tipo de mudança:

Fase em que ocorre	Custo aproximado de mudar
Wireframe	15-30 min
Mockup	1-3 horas
Código	4-16 horas
Site em produção	8-40+ horas (e potencial perda de SEO)

Uma PME que aprova wireframe à pressa "para não atrasar" tipicamente paga 5-10x mais para mudar o mesmo no código. O wireframe é o seguro mais barato do projeto.

Para perceber como ligar wireframe ao briefing inicial, ver briefing de website: o guia. E para enquadrar como wireframe se integra num redesign de site, começa por aí — antes de tocar em pixels.

Componentes reutilizáveis: a poupança escondida do Figma

Os estúdios que trabalham bem em Figma criam bibliotecas de componentes — header, footer, hero, cards, formulários — que se reusam em projetos. Para o cliente isto significa três coisas:

• Mais barato no orçamento, porque o estúdio não desenha tudo do zero.
• Mais rápido na entrega, porque os componentes já estão testados.
• Mais previsível no resultado, porque o cliente pode ver componentes "vivos" do estúdio noutros projetos.

Sinais de que o estúdio usa biblioteca a sério:

• Mostra Figma com auto-layout e variants configurados.
• Os componentes têm properties (variação de tamanho, cor, estado) sem refazer.
• A passagem de wireframe para mockup demora horas, não dias.

Estúdios que desenham tudo "à mão" cobram mais e demoram mais — sem entregar resultado melhor.

O que o handoff de Figma para desenvolvimento deve conter

Quando o mockup é aprovado, o ficheiro Figma é a "planta" para o developer. Um handoff bem feito tem:

• Frames separados por breakpoint (mobile, tablet, desktop).
• Naming consistente das camadas e componentes.
• Design tokens declarados — cores em styles, tipografia em styles, sombras em styles. Não valores hard-coded.
• Estados — hover, ativo, foco, erro, vazio.
• Notas em comentário para casos não óbvios ("este card encolhe abaixo de 400px de largura para 1 coluna").
• Plugin de inspect ativado para o developer (CSS, dimensões).

Sem handoff decente, o developer adivinha — e o site sai com 30 pequenas diferenças que ninguém pediu mas todos notam.

Quem não precisa de wireframe (1 caso)

Há uma única exceção legítima: landing page de 1 página com âmbito ultra-claro (ex.: captura de leads para um evento), feita em 3-5 dias, com template já testado e copy curta. Aqui o wireframe é overhead — o mockup direto chega.

Para tudo o resto (site institucional 5+ páginas, loja online, redesign), saltar wireframe é cobrar barato hoje para pagar caro daqui a 6 semanas.

Quanto custa cada fase (referências PT 2026)

Para perceber o que estás a pagar quando o estúdio apresenta orçamento separado por fase:

Fase	Tempo típico (5-7 páginas)	Custo típico em PT
Wireframes baixa fidelidade	8-16 horas	400€-900€
Mockups (3 telas-chave)	16-30 horas	900€-2.000€
Protótipo clicável (opcional)	4-12 horas	250€-700€
Handoff e suporte ao dev	4-8 horas	200€-500€

Estes valores são parte do orçamento total do site. Estúdio que cobra 1.500€ pelo site completo está a fazer template — não há tempo lá dentro para wireframes e mockups dedicados. Site dedicado de raiz em PT raramente sai abaixo de 2.500€-3.500€ se a fase de design existir a sério.

A regra que junta tudo

Wireframe é onde se decide o quê. Mockup é onde se decide o como parece. Protótipo é onde se testa o como se usa. Aprovar a estrutura antes do visual, e o visual antes do código, é o que separa um projeto de site previsível de um projeto que descarrila na terceira semana.

---

No sitesfixe.pt desenhamos sites em Portugal com wireframe e mockup em Figma antes de qualquer linha de código — duas rondas de aprovação por fase, mobile-first, e cliente sempre a saber em que ponto está. Sites previsíveis no prazo e no orçamento. Fala connosco. Sites desde 1.500€.

Lê também:

• Briefing de website: o guia para perguntas que cobrem tudo
• Estrutura de um site institucional: que páginas precisas mesmo
• Redesign do site: quando vale a pena refazer (e quando não)

Fontes

• Figma — Best Practices for Design Teams
• Nielsen Norman Group — Paper Prototyping
• web.dev — Responsive Web Design Basics