O erro mais caro num projeto digital costuma começar por parecer barato.
Uma ideia parece simples. Desenvolve-se “só uma primeira versão”. Acrescenta-se uma página, depois uma área reservada, depois uma integração, depois uma funcionalidade que alguém se lembrou de incluir numa reunião.
Quando se dá por isso, já existe código, design detalhado, decisões técnicas e horas de trabalho investidas numa solução que talvez nunca tenha sido devidamente discutida.
O problema não é mudar de ideias. Mudar de ideias faz parte de qualquer projeto sério.
O problema é descobrir que era preciso mudar depois de a ideia já estar transformada em código.
É por isso que uma maquete ou um wireframe deve aparecer antes do resultado final. Não para tornar o projeto mais lento, nem para criar burocracia. Serve para tornar visível aquilo que ainda está ambíguo, antes de essa ambiguidade começar a consumir dinheiro, prazo e margem.
O que são wireframes, maquetes e protótipos?
Embora os termos sejam muitas vezes usados como se fossem a mesma coisa, representam níveis diferentes de detalhe.
Wireframe: a estrutura antes da decoração
Um wireframe é uma representação simples da estrutura de uma página, aplicação ou sistema.
Mostra, por exemplo:
- Onde fica o menu;
- Que informação aparece primeiro;
- Onde estão os botões principais;
- Como se organizam os blocos de conteúdo;
- Que passos o utilizador tem de seguir;
- Como se passa de um ecrã para o seguinte.
Normalmente, não se preocupa demasiado com cores, imagens, tipografia ou pormenores gráficos. O objetivo é discutir a organização e o fluxo.
É como fazer a planta de uma casa antes de escolher os móveis. Primeiro decides onde ficam as divisões e como se circula. Só depois escolhes os acabamentos.
Maquete: uma visão mais próxima do resultado
A maquete, ou mockup, aproxima-se mais da aparência final.
Permite avaliar:
- Cores;
- Tipografia;
- Espaçamentos;
- Hierarquia visual;
- Estilo dos botões;
- Apresentação de imagens;
- Perceção de qualidade;
- Coerência com a identidade da marca.
Uma maquete ajuda a responder a uma pergunta diferente: “É isto que queremos que o utilizador veja e sinta?”
O Miro explica esta diferença entre wireframes e mockups de forma clara: o wireframe ajuda a validar a estrutura; a maquete permite avaliar mais concretamente o aspeto visual.
Protótipo interativo: experimentar antes de programar
Um protótipo interativo simula cliques e percursos.
Podes clicar num botão, abrir um menu, avançar para outro ecrã ou testar o caminho de uma compra, sem que a aplicação esteja realmente desenvolvida.
É particularmente útil quando há dúvidas sobre:
- O processo de inscrição;
- A compra de um produto;
- O preenchimento de um formulário;
- A área reservada de um cliente;
- Um sistema interno;
- Uma aplicação com vários perfis de utilizador.
Quanto maior for o risco de uma decisão, mais útil é poder experimentá-la antes de a construir.
As principais vantagens de trabalhar com maquetes
1. Encontras erros quando ainda são baratos
Alterar um bloco num wireframe pode demorar minutos.
Alterar a mesma decisão depois de desenvolvida pode implicar:
- Refazer o design;
- Alterar a estrutura de dados;
- Rever o código;
- Corrigir comportamentos em várias páginas;
- Repetir testes;
- Atualizar documentação;
- Adiar outras tarefas.
A diferença não está apenas no tempo de desenvolvimento. Uma alteração tardia pode afetar várias partes do projeto que dependem daquela decisão.
Se percebes numa maquete que o botão principal está no lugar errado, mudas o botão.
Se percebes isso depois de uma aplicação estar construída, talvez tenhas de rever o fluxo completo.
A regra é simples: quanto mais cedo detetas um problema, mais barato é corrigi-lo.
2. Alinhas expectativas antes de haver frustração
Muitos conflitos em projetos digitais não acontecem por falta de competência técnica. Acontecem porque cada pessoa imaginou uma solução diferente.
O cliente pensa numa área reservada simples. O desenvolvimento interpreta uma plataforma completa.
O dono do negócio imagina três passos. O utilizador acaba com sete.
A direção espera que a informação mais importante esteja no topo. O design dá-lhe pouco destaque.
Uma maquete põe a discussão em cima da mesa. Deixa de se falar em frases vagas como “queria algo mais simples” ou “a navegação devia ser mais intuitiva” e passa a ser possível apontar para um ecrã concreto.
A conversa torna-se mais objetiva:
- Este botão deve estar aqui ou ali?
- Esta informação é mesmo necessária?
- O utilizador percebe o que deve fazer?
- Esta página é indispensável?
- O que acontece depois de clicar?
Cliente, design e desenvolvimento passam a discutir a mesma coisa, em vez de discutirem interpretações.
3. Testas a experiência antes de investir no resultado final
Uma interface pode estar visualmente bonita e continuar a ser difícil de usar.
O utilizador pode não saber:
- Onde começar;
- Qual é o próximo passo;
- Que botão deve escolher;
- O que significa determinado campo;
- Se a operação ficou concluída;
- Onde encontrar uma informação importante.
Um wireframe simples já permite testar muitas destas questões. Não é preciso ter animações, fotografias perfeitas ou todos os textos finais para perceber se o fluxo faz sentido.
Pede a alguém que não participou na criação para realizar uma tarefa. Observa onde hesita. Repara nas perguntas que faz. Vê se procura um botão que não está onde esperava.
É melhor descobrir a confusão numa sessão de teste do que depois de o sistema estar disponível para centenas de clientes.
4. Controlas melhor o âmbito do projeto
Uma maquete obriga a decidir o que entra e o que fica de fora.
Isto é importante porque quase todos os projetos começam com um objetivo e acabam a tentar resolver dez problemas diferentes.
Se estás a criar uma landing page, talvez o essencial seja:
- Explicar a oferta;
- Mostrar os benefícios;
- Responder às principais dúvidas;
- Apresentar prova;
- Permitir o contacto ou a compra.
O sistema de membros, a área de relatórios, o simulador avançado e a integração com cinco plataformas podem ficar para uma segunda fase.
Ao ver a estrutura, torna-se mais fácil separar:
- O que é essencial;
- O que melhora a experiência;
- O que pode esperar;
- O que está apenas a ser acrescentado porque parece interessante.
Esta disciplina ajuda a evitar o scope creep e o trabalho extra que não foi devidamente definido.
5. Melhoras as estimativas de prazo e custo
É difícil estimar um projeto que ainda existe apenas em conversas.
Quando há wireframes e fluxos definidos, já é possível identificar:
- Quantas páginas ou ecrãs existem;
- Que componentes são necessários;
- Que áreas têm lógica personalizada;
- Que integrações podem ser complexas;
- Onde existem dependências;
- Que funcionalidades pertencem à primeira versão.
Isto não elimina todas as incertezas, mas reduz bastante o espaço para adivinhação.
Uma estrutura clara ajuda-te a tomar decisões financeiras mais realistas. Também torna mais fácil perceber o custo de acrescentar uma nova funcionalidade antes de ela ser prometida.
6. Aceleras as decisões
As pessoas têm mais facilidade em reagir a algo visível do que a uma descrição abstrata.
É difícil decidir com base numa frase como “terá uma navegação simples e moderna”.
É muito mais fácil olhar para um ecrã e dizer:
“Este menu tem demasiadas opções.”
Ou:
“O botão de pedido de orçamento não está suficientemente destacado.”
Ou ainda:
“Esta informação devia aparecer antes do formulário.”
Uma boa maquete não serve para impressionar. Serve para provocar decisões concretas.
O custo de saltar esta etapa
Quando um projeto avança diretamente para o desenvolvimento, fica dependente de suposições.
E as suposições acumulam-se rapidamente.
O resultado pode ser:
- Desenvolvimento baseado em requisitos incompletos;
- Alterações tardias;
- Funcionalidades acrescentadas sem controlo;
- Discussões sobre “não era isso que eu tinha imaginado”;
- Interfaces bonitas, mas pouco práticas;
- Atrasos no lançamento;
- Retrabalho;
- Perda de margem;
- Desgaste entre as pessoas envolvidas.
Por vezes, o projeto até é entregue. Mas a solução exige demasiadas explicações, o cliente não a utiliza como esperado e a equipa continua a corrigir problemas que podiam ter sido detetados antes.
O custo real não está apenas no dinheiro gasto a corrigir. Está também no custo de oportunidade: enquanto corriges uma decisão errada, deixas de trabalhar noutras oportunidades.
Como usar maquetes sem criar burocracia
Fazer wireframes não significa passar semanas a desenhar todos os ecrãs possíveis.
Começa pelo fluxo crítico.
Se tens um website, começa pela página que gera contactos ou vendas. Se tens uma aplicação, começa pela tarefa principal que o utilizador precisa de concluir. Se tens um sistema interno, começa pelo processo que mais tempo ou erros provoca.
Para cada ecrã, define:
- Qual é o objetivo desta página?
- O que precisa de perceber o utilizador?
- Que ação deve realizar?
- Que informação é obrigatória?
- O que acontece a seguir?
Depois cria uma versão suficientemente concreta para gerar reação, mas não tão acabada que todos tenham medo de sugerir alterações.
Testa com pessoas que não participaram na criação. Regista as decisões. Define o que fica fora do âmbito. E estabelece um momento de aprovação antes de o desenvolvimento começar.
A partir daí, a maquete passa a ser uma referência. Se surgir uma alteração, ela pode ser avaliada com base no impacto no prazo, no custo e no objetivo do projeto.
O papel da inteligência artificial
A inteligência artificial pode acelerar bastante esta fase.
Pode ajudar-te a:
- Explorar diferentes estruturas de uma página;
- Criar variações de um fluxo;
- Transformar requisitos num primeiro wireframe;
- Identificar perguntas que devem ser testadas;
- Sugerir conteúdos para diferentes estados de uma interface;
- Comparar alternativas de navegação;
- Encontrar casos que ainda não foram considerados.
Mas a IA não sabe automaticamente o que faz sentido para o teu negócio. Também não substitui o contacto com utilizadores reais.
Pode gerar três soluções visualmente convincentes e todas podem estar erradas para o teu contexto.
Usa-a para explorar mais depressa. Não uses a velocidade da IA como desculpa para deixar de validar decisões. O objetivo é reduzir o tempo entre uma hipótese e a sua avaliação, não trocar uma decisão precipitada por outra produzida automaticamente.
Podes encontrar outros exemplos práticos sobre a utilização da IA em negócio no artigo A IA está a ajudar a tua equipa ou a criar mais trabalho?.
Nem todos os projetos precisam do mesmo nível de detalhe
Uma landing page simples pode precisar apenas de um wireframe rápido e de uma revisão conjunta.
Uma loja online pode beneficiar de maquetes para a página de produto, carrinho e checkout.
Uma aplicação complexa deve provavelmente testar os fluxos principais com um protótipo interativo antes de se iniciar o desenvolvimento.
O nível de detalhe deve acompanhar o risco da decisão, não o gosto pela ferramenta.
Se uma alteração for barata, reversível e pouco importante, não precisas de criar um processo pesado. Se uma decisão afetar meses de desenvolvimento, pagamentos, dados de clientes ou a operação diária do negócio, vale a pena validá-la com mais cuidado.
Primeiro torna a ideia visível
Uma maquete não é tempo perdido antes do trabalho.
É trabalho de redução de risco.
Permite encontrar erros cedo, alinhar expectativas, controlar o âmbito, testar a experiência e estimar melhor o esforço necessário. Mais importante ainda: ajuda-te a descobrir se estás a construir a solução certa, e não apenas a construir bem a solução errada.
O objetivo não é desenhar o resultado final. É descobrir o resultado certo antes de pagares para o construir.
Primeiro torna a ideia visível. Depois decide se vale a pena torná-la real.