Wireframe vs mockup vs protótipo: o que você está aprovando
Uma fundadora com quem trabalhamos no ano passado passou três semanas de reuniões de design concordando educadamente com caixas cinzas. Ela achava que o estúdio estava mostrando um produto inacabado e demorando para entregar. O que ela estava olhando, na verdade, era um wireframe, e o trabalho dela naquelas reuniões era pegar um problema estrutural que custaria cinco dígitos para corrigir dois meses depois. Ela não pegou nenhum, porque ninguém disse que essa era a tarefa. O fluxo de checkout tinha a etapa de pagamento no lugar errado. Foi para produção assim, e a correção caiu na semana nove em vez da semana um.
Essa lacuna é o assunto deste artigo. A questão wireframe vs mockup parece um problema de designer, mas se você está pagando um estúdio para construir software sob medida e não escreve código, ela é sua: depois que a fase de discovery define o que você vai construir, você vai receber wireframes, depois mockups, depois um protótipo, normalmente nessa ordem, e vai ter que aprovar cada um. Saber para que serve cada um é a diferença entre dar um feedback que economiza um mês e dar um feedback que desperdiça a tarde de todo mundo.
Aqui está a versão curta de wireframe vs mockup vs protótipo, as três palavras que você mais vai ouvir. Um wireframe é a planta: caixas cinzas e rótulos mostrando o que vai onde e como as telas se conectam, sem cor e sem marca. Um mockup são essas mesmas telas com o design visual real aplicado: suas cores, fontes, espaçamento, logo, a aparência de verdade. Um protótipo é o mockup ligado de forma que você consegue clicar e navegar como num app real, mesmo que nada por trás dos botões funcione ainda. Wireframe responde “a estrutura está certa?”. Mockup responde “parece a nossa cara?”. Protótipo responde “o fluxo funciona de verdade?”. Três artefatos, três perguntas, três trabalhos diferentes para você.
Wireframe vs mockup vs protótipo: por que o estúdio mostra nessa ordem
A ordem não é aleatória, e não é o estúdio sendo lento. É o estúdio gastando o seu dinheiro na sequência mais barata possível.
Mudar um wireframe leva minutos. Alguém arrasta uma caixa, troca um rótulo, move um botão do topo da tela para baixo. Mudar um mockup leva mais tempo, porque agora existe design visual real para refazer: o espaçamento, o tratamento de cor, o jeito que o componente aparece em três estados. Mudar um protótipo leva mais tempo ainda. E mudar o software construído de verdade, aquilo rodando em código real, é a mudança mais cara de todas, às vezes em uma ordem de grandeza.
Então um estúdio competente coloca na frente as decisões fáceis de reverter e empurra o trabalho caro e difícil de reverter para o fim. Resolve a estrutura primeiro, quando a estrutura é livre para se mover. Resolve o design visual depois. Confirma o fluxo por último, antes de uma linha de código de produção ser escrita. A sequência inteira existe para encontrar suas objeções enquanto elas ainda são baratas. É também onde o escopo abstrato que você escreveu em um documento de requisitos que o estúdio consegue cotar finalmente vira algo que você consegue ver e reagir.
Por isso também “pula os wireframes e me mostra logo como vai ficar” é um pedido tentador que costuma sair pela culatra. Quando você pula direto para um mockup polido, você e o estúdio começam a discutir o tom de azul e os cantos arredondados, e ninguém percebe que o modelo de navegação inteiro está errado. O polimento esconde problemas estruturais. As caixas cinzas existem justamente porque não têm nada bonito para te distrair.
O que você está aprovando de fato em cada etapa
Os artefatos são fáceis de definir. A parte difícil, a parte que os blogs de ferramentas de design nunca cobrem, é o que você deve fazer quando um deles cai na sua caixa de entrada. Aqui está o trabalho em cada etapa.
Wireframe: confira o encanamento. Toda tela que o usuário precisa existe de fato? Dá para ir do cadastro até a coisa que a pessoa veio fazer sem um beco sem saída? A ação mais importante de cada tela é a mais óbvia? Você está pedindo informação na hora certa, ou pedindo cartão de crédito antes de o usuário entender o que está comprando? Essas são perguntas estruturais, e o wireframe é a única etapa em que respondê-las é barato. Se algo no fluxo parecer errado aqui, fale alto. Essa é a reunião que mais importa e a que os fundadores levam menos a sério, porque parece inacabada.
Mockup: confira a identidade e a hierarquia. Agora existe design de verdade, então agora o seu julgamento visual é útil. Isso parece um produto em que o seu cliente confiaria o dinheiro ou os dados dele? A coisa que você mais quer que as pessoas cliquem está visualmente mais forte do que as que você não quer? A tela densa, aquela com a tabela ou o dashboard, continua legível? Aqui “deixa o botão principal mais destacado” é uma observação útil. Teria sido inútil no wireframe, onde tudo é cinza de propósito.
Protótipo: navegue como um usuário confuso. Clique nas coisas erradas de propósito. Tente fazer a tarefa principal como se você nunca tivesse visto o app. Entregue para alguém parecido com o seu cliente real e observe a pessoa travar sem ajudar. O protótipo é a última chance barata de descobrir que um fluxo que fazia sentido numa imagem estática desmorona no momento em que uma pessoa real tenta passar por ele. O Nielsen Norman Group, o nome mais citado em pesquisa de usabilidade, passou décadas mostrando que até protótipos toscos pegam a maioria dos problemas de fluxo que um build real iria para produção sem resolver. Você não precisa de um protótipo perfeito para aprender as coisas importantes. Você precisa de um clicável e de um testador honesto.
O erro de feedback que custa um mês
O erro mais comum e mais caro que fundadores não técnicos cometem na revisão de design é dar o tipo errado de feedback na etapa errada. Especificamente: dar feedback cosmético num wireframe e feedback estrutural num mockup.
Quando você diz ao designer que a fonte do wireframe é feia, você não disse nada, porque o wireframe não tem fonte de verdade. Você também sinalizou que acha que o seu trabalho é reagir à aparência, o que te treina a continuar reagindo à aparência justamente nas etapas em que a estrutura é a única coisa que importa. Enquanto isso, o problema de navegação fica ali, sem ninguém mencionar.
O contrário é igualmente caro. Quando você espera o mockup polido para dizer “na verdade, os usuários deveriam conseguir fazer tudo isso em uma tela em vez de três”, você acabou de pedir uma mudança estrutural depois que a estrutura já deveria estar travada. O estúdio agora refaz um design que você já aprovou, e o prazo que te prometeram escorrega em silêncio. Todo estúdio já viveu isso. É a principal causa de um build atrasar enquanto, tecnicamente, todo mundo fez o seu trabalho.
A correção é simples de dizer e exige disciplina para seguir. Combine o seu feedback com o artefato. Encanamento no wireframe. Identidade e hierarquia no mockup. Fluxo no protótipo. Quando você se pegar querendo falar de cor numa tela cinza, anote a observação e guarde para o mockup. Quando você se pegar querendo reorganizar as telas num mockup pronto, pare e pergunte por que isso não apareceu na etapa do wireframe, porque pegar agora custa dinheiro de verdade.
O Figma é um wireframe?
Não, e vale esclarecer essa confusão porque você vai ouvir a palavra “Figma” o tempo todo. O Figma é a ferramenta que a maioria dos estúdios usa para desenhar os três: wireframes, mockups e protótipos clicáveis vivem todos dentro do mesmo arquivo do Figma. Então “estamos no Figma” não te diz nada sobre qual etapa você está olhando. Pergunte direto: isto é um wireframe, um mockup ou um protótipo? A resposta te diz qual feedback o estúdio realmente precisa de você agora.
O mesmo vale para as outras ferramentas que você pode ouvir citarem. O Balsamiq é feito para wireframes de baixa fidelidade, de propósito, com um visual de rascunho feito à mão para ninguém confundir com trabalho pronto. Sketch e Figma cobrem a faixa inteira. A ferramenta não é o ponto. A fidelidade é o ponto, e fidelidade é só uma palavra chique para o quão pronto algo parece. Baixa fidelidade significa caixas cinzas. Alta fidelidade significa que poderia passar pelo app de verdade. O motivo de os designers irem para a baixa fidelidade cedo é o mesmo motivo de o estúdio te mostrar wireframes primeiro: mantém você focado na decisão que está de fato em jogo.
Você precisa dos três?
Nem sempre, e um bom estúdio vai te dizer quando não precisa. O número certo depende do que você está construindo.
Se você está validando uma ideia ainda crua e as telas são simples, wireframes mais um protótipo leve podem bastar, e o mockup visual pode vir junto com o build. Se você está construindo algo em que confiança e acabamento são o produto, o portal do paciente de uma clínica premium, um dashboard de fintech mexendo com dinheiro de verdade, você quer os três e quer gastar atenção real no mockup, porque a camada visual está fazendo um trabalho que sustenta o resto. Se você está estendendo um produto que já existe e já tem um design system, você pode ir direto para os mockups, porque as decisões estruturais e visuais foram resolvidas há muito tempo e reaproveitá-las é o objetivo.
Do que você deve desconfiar é de um estúdio que quer pular o wireframe por completo num build do zero e ir direto para telas polidas. Às vezes tudo bem, para um escopo minúsculo. Muitas vezes significa que o pensamento estrutural está sendo pulado, e você vai pagar por esse pulo depois, no build, onde as mudanças são mais caras. A ordem existe para proteger o seu orçamento. Comprimi-la é uma decisão, não um acidente, e você tem o direito de perguntar por quê.
Nada disso exige que você aprenda design. Exige que você saiba qual pergunta está sendo feita e responda a essa pergunta em vez da que por acaso chamou a sua atenção. Acerte isso e a fase de design vira o que ela deveria ser: o lugar mais barato de estar errado antes do build, onde estar errado fica caro. É essa a razão de existirem esses três artefatos, e a razão de um estúdio te levar por eles em ordem. O plano, depois a aparência, depois a prova de que funciona, cada um uma chance de mudar de ideia enquanto mudar ainda custa quase nada.
FAQ
Qual é a diferença entre mockup e wireframe?
Um wireframe é a planta estrutural: caixas cinzas e rótulos mostrando o que vai onde e como as telas se conectam, sem cor nem marca. Um mockup são as mesmas telas com o design visual real aplicado, incluindo cores, fontes, espaçamento e o seu logo. O wireframe resolve a estrutura; o mockup resolve a aparência. Os estúdios fazem o wireframe primeiro porque mudanças estruturais são baratas ali e caras em todas as etapas seguintes.
Qual é a diferença entre wireframe e protótipo?
Um wireframe é um layout estático que você lê. Um protótipo é interativo: telas ligadas de forma que você consegue clicar pelo produto e sentir o fluxo, mesmo que os botões ainda não façam nada de verdade. O wireframe te mostra a estrutura de uma tela por vez. O protótipo te mostra se passar de uma tela para outra faz sentido para uma pessoa real tentando completar uma tarefa.
O Figma é um wireframe?
Não. O Figma é uma ferramenta de design que produz wireframes, mockups e protótipos clicáveis, todos dentro do mesmo arquivo. Então ouvir “está no Figma” não te diz qual etapa você está revisando. Pergunte ao estúdio direto se você está olhando um wireframe, um mockup ou um protótipo, porque cada um precisa de um tipo diferente de feedback.
Quais são os tipos de protótipo?
Os protótipos costumam ser descritos por fidelidade, ou seja, o quão prontos eles parecem. Um protótipo de baixa fidelidade navega por telas cinzas de wireframe para testar o fluxo; um de alta fidelidade navega pelos mockups polidos e pode passar pelo app de verdade numa demo. Para a maioria dos fundadores, a distinção útil é simplesmente baixa versus alta fidelidade: use um de baixa para testar se o fluxo funciona e um de alta quando precisar de uma demo que pareça real para um investidor ou cliente.