Introdução
Imagine que uma empresa precisa incluir uma nova funcionalidade no aplicativo. A equipe já sabe o que pretende oferecer, mas ainda existem dúvidas: em qual parte do fluxo o usuário terá acesso a esse recurso? Como organizar a interface para facilitar seu uso? Como ajudar a pessoa a encontrar valor nessa funcionalidade e realizar o que precisa?
O protótipo tira as ideias do campo da abstração e torna essas ideias visíveis. Com ele, podemos percorrer os caminhos propostos, discutir as decisões e identificar dificuldades antes de investir na implementação.
Uma tela pode parecer bem resolvida quando observada sozinha, mas apresentar problemas quando faz parte de um fluxo. A pessoa pode não entender o conteúdo ou não encontrar os recursos de que precisa.
Esses problemas podem causar fricção e insatisfação, prejudicar as métricas de sucesso do produto e gerar prejuízos ao negócio.
Por isso, a prototipagem considera tanto a organização de cada tela quanto a relação entre elas. O objetivo é representar como as pessoas poderão utilizar os recursos do produto e o que a interface precisa para proporcionar uma boa experiência ao usuário.
Esse trabalho pode acontecer na criação de um produto, no planejamento de uma nova funcionalidade ou na melhoria de uma experiência existente.
Como faço
Começo analisando quais os recursos que precisamos prototipar, quais decisões de UX já foram tomadas, quais hipóteses temos, quais dúvidas precisam ser esclarecidas e se já há alguma organização de UI pré-estabelecida (como design system, fluxos de telas, diretrizes etc). Considero as necessidades dos usuários, os objetivos do negócio e as condições de implementação.
A partir dessa base, organizo os fluxos, desenvolvo as telas e represento as interações necessárias no Figma. Quando o produto já possui um design system, utilizo seus componentes e avalio se atendem às situações previstas.
O nível de detalhe depende do objetivo do trabalho. Algumas telas podem ser exploradas com estruturas simples; outras precisam de conteúdo, aparência e comportamentos mais próximos do produto final.
As etapas abaixo mostram como organizo esse processo. Elas podem ser retomadas conforme surgem novos aprendizados.
Etapa 1 — Definição dos fluxos e cenários
Começo identificando quais tarefas as pessoas precisam realizar e quais caminhos estarão disponíveis para isso. Analiso onde cada tarefa começa, quais decisões aparecem durante o percurso e como a pessoa entende que chegou ao resultado esperado.
Em um agendamento, por exemplo, o usuário pode precisar escolher um serviço, consultar horários, informar seus dados e confirmar a reserva. Mas o que acontece se não houver horários disponíveis? E se ele quiser voltar e trocar o serviço?
Essas situações ajudam a definir quais telas, estados e alternativas precisam ser representados.
Caminhos principais e alternativos
Organizo o caminho principal da tarefa e as variações relevantes para o projeto. Considero situações como voltar a uma etapa, corrigir informações, cancelar uma ação ou continuar depois de encontrar um impedimento.
A intenção é compreender o percurso antes de detalhar cada tela, evitando que partes importantes da experiência sejam percebidas apenas durante o desenvolvimento.
Alinhamento com a equipe
Compartilho os fluxos com o cliente e com os profissionais envolvidos para esclarecer regras do negócio e restrições técnicas.
Ainda no exemplo do agendamento: uma opção de reagendamento, por exemplo, pode depender de um prazo mínimo definido pela empresa. Essa regra precisa ser considerada na interface para que o produto não ofereça uma ação que depois não poderá cumprir.
Etapa 2 — Organização das telas
Com os fluxos definidos, organizo as informações e os recursos de cada tela. Analiso o que a pessoa precisa compreender naquele momento, quais ações estão disponíveis e o que deve receber mais destaque.
Quando necessário, começo com wireframes: representações simplificadas que ajudam a discutir a estrutura antes de detalhar a aparência.
É como um desenhista fazer um esboço antes de começar a pintar e dar profundidade ao desenho. Primeiro precisamos entender se o conceito atende ao uso e depois nos aprofundamos em decisões de estilo.
Hierarquia das informações
Defino a ordem e o destaque dos conteúdos considerando a tarefa do usuário.
Na confirmação de um agendamento, por exemplo, serviço, data, horário e local precisam estar fáceis de encontrar. Uma informação secundária não deve disputar a mesma atenção com aquilo que a pessoa precisa conferir antes de confirmar.
Conteúdo da interface
Também considero os textos que orientam a interação, algo que toca em UX Writing: títulos, rótulos dos campos, botões, instruções e mensagens.
“Continuar” pode funcionar em uma etapa intermediária, mas “Confirmar agendamento” explica melhor uma ação que conclui a reserva. Essas escolhas ajudam a pessoa a antecipar o que acontecerá ao interagir com a interface.
Etapa 3 — Prototipagem das telas
Com a estrutura organizada, desenvolvo o protótipo das telas. Aplico cores, tipografia, espaçamentos, imagens e componentes considerando a identidade da marca e as necessidades de uso.
Quando existe um design system, utilizo essa base para manter a consistência. Se uma situação exigir um componente novo ou uma variação, avalio como essa necessidade pode ser atendida sem criar diferenças desnecessárias no produto.
Consistência e clareza
Elementos com a mesma função devem apresentar padrões que ajudem o usuário a reconhecê-los. Isso envolve tanto a aparência quanto a forma de nomear e organizar as ações.
Se o botão principal muda de estilo sem motivo a cada tela, por exemplo, a pessoa precisa interpretar novamente qual ação merece sua atenção. Isso pode criar uma carga cognitiva desnecessária as pessoa e pode gerar insatisfação no usuário por achar, por exemplo, que o produto é muito difícil.
No fim das contas a falta de consistência e clareza da interface, pode causar uma grande perda na sua base de usuários e prejuízos ao negócio.
Também considero aspectos de acessibilidade aplicáveis ao design, como contraste, identificação dos campos e indicação visual de foco. Essas definições precisam ser preservadas e verificadas durante a implementação.
Adaptação aos tamanhos de tela
Organizo as interfaces para os tamanhos de tela previstos no projeto, considerando como o conteúdo deve se reorganizar.
Uma tabela que funciona bem no computador pode precisar de outra apresentação no celular. O importante é manter as informações e ações necessárias acessíveis, mesmo quando o espaço disponível muda.
Etapa 4 — Protótipo navegável
Depois de organizar as telas, conecto os caminhos e represento as interações necessárias para demonstrar o funcionamento proposto com um protótipo navegável utilizando o recurso de prototipagem do Figma.
No protótipo navegável, a equipe pode acompanhar o que acontece ao selecionar uma opção, abrir um menu, avançar em um formulário ou concluir uma tarefa.
Respostas às ações do usuário
A interface precisa comunicar o que está acontecendo. Após tocar em “Confirmar agendamento”, por exemplo, a pessoa deve conseguir perceber se a solicitação está sendo processada, se foi concluída ou se encontrou algum problema.
Conforme a necessidade do projeto e as possibilidades de simulação no Figma, represento situações como:
Carregamento de informações. Confirmação de uma ação. Erro no preenchimento. Ausência de resultados. Indisponibilidade de uma opção. Cancelamento ou retorno a uma etapa anterior.
Esses estados ajudam a explicar a experiência além do cenário em que tudo acontece como esperado.
Limites da simulação
O protótipo navegável representa os comportamentos necessários para compreender e avaliar a proposta. Quando uma interação não pode ser demonstrada fielmente nos recursos de prototipagem do Figma, registro como ela deve funcionar para orientar a equipe.
Também deixo claro quais caminhos estão disponíveis na simulação. Assim, as pessoas que revisam o trabalho conseguem distinguir uma limitação do protótipo de uma decisão sobre o produto.
Etapa 5 — Revisão e ajustes
Com os fluxos representados, percorro as tarefas e reviso a relação entre telas, conteúdos e interações. Confiro se as ações levam aos destinos esperados, se as mensagens estão claras e se os cenários previstos foram considerados.
Apresento o protótipo navegável ao cliente e à equipe, explicando as decisões e discutindo os pontos que precisam de ajuste.
Avaliação com usuários
Quando os testes com usuários fazem parte do escopo, o protótipo pode ser utilizado para observar como as pessoas realizam tarefas e onde encontram dificuldades.
No exemplo do agendamento, podemos verificar se a pessoa encontra um horário, entende as condições da reserva e percebe que conseguiu confirmar.
A avaliação considera o que acontece durante a tarefa. Gostar da aparência da tela, por si só, não demonstra que a experiência está clara.
Ajustes a partir dos aprendizados
Os problemas identificados ajudam a orientar as revisões. Conforme o caso, pode ser necessário alterar um texto, reorganizar informações ou reconsiderar parte do fluxo.
Após os ajustes, confiro novamente as situações afetadas. Quando necessário e previsto no projeto, a proposta pode passar por uma nova rodada de avaliação.
Etapa 6 — Handoff: preparação para o desenvolvimento
Organizo as telas, os fluxos e as orientações para que a equipe de desenvolvimento consiga compreender o que precisa ser implementado.
Além da aparência, registro comportamentos que podem não ficar evidentes ao observar uma tela isolada: o que acontece depois de uma ação, quais estados precisam existir e como a interface deve se adaptar.
Esclareço as dúvidas da equipe e sinalizo as definições que ainda dependem de alinhamento. Essa troca ajuda a reduzir interpretações diferentes entre o que foi projetado e o que será desenvolvido.
Depois da implementação, é importante conferir a experiência no produto em funcionamento. O protótipo orienta esse trabalho, mas questões como desempenho, integração com dados e acessibilidade no código precisam ser avaliadas em homologação e acompanhadas após o lançamento.
O que entrego
Os entregáveis variam conforme o escopo e as necessidades do projeto. Podem incluir:
Fluxos das tarefas e cenários previstos. Wireframes, quando necessários. Interfaces organizadas no Figma. Adaptações para os tamanhos de tela combinados. Protótipo navegável com os caminhos e as interações definidos. Estados de carregamento, erro, confirmação e outras situações relevantes. Orientações sobre comportamentos e regras da interface. Registro dos achados e ajustes dos testes, quando contratados. Informações para apoiar a implementação.
Organizo esse material para que o cliente e a equipe consigam consultar as decisões e utilizar o trabalho nas próximas etapas.
A entrega do protótipo não inclui automaticamente a condução de um Discovery ou a criação de um design system. Esses trabalhos dependem do escopo combinado para o projeto.
Nesta frente, a entrega contempla as interfaces, o protótipo e as orientações para desenvolvimento.
Perguntas frequentes
Qual é a diferença entre wireframe e protótipo?
O wireframe é uma representação simplificada da estrutura de uma tela. O protótipo representa uma proposta para explorar ou avaliar aspectos do produto e pode utilizar wireframes ou interfaces mais detalhadas. Portanto, um conjunto de wireframes também pode servir de base para um protótipo.
Todo projeto precisa começar com wireframes?
Não. Utilizo esse recurso quando ele ajuda a resolver dúvidas sobre a estrutura. Se o produto já possui padrões bem definidos e a necessidade está clara, pode fazer sentido trabalhar diretamente com interfaces mais detalhadas.
Preciso ter um design system antes de prototipar?
Não. Um design system pode facilitar o trabalho e manter a consistência, mas não é um pré- requisito para começar. Também é possível explorar uma solução com elementos simples ou utilizar os padrões que o produto já possui.
O protótipo funciona como o produto final?
Ele simula os caminhos e comportamentos definidos para o trabalho. Isso não significa que tenha todas as funcionalidades, integrações ou regras implementadas. As limitações da simulação precisam estar claras para quem utiliza o protótipo.
É possível prototipar apenas uma funcionalidade?
Sim. O trabalho pode se concentrar em uma parte do produto, considerando também os pontos em que ela se conecta à experiência existente.
Os testes com usuários estão incluídos?
A realização dos testes depende do escopo combinado. Quando fazem parte do projeto, é necessário definir o que será investigado, quem participará e quais situações o protótipo precisa representar.
Um protótipo aprovado garante que o produto será fácil de usar?
Não. A aprovação do cliente ajuda a alinhar a proposta, mas não substitui a avaliação com usuários nem as verificações após a implementação. Mesmo quando o protótipo é testado, o produto em funcionamento pode revelar novas necessidades de ajuste.
A entrega inclui a programação das interfaces?
Não. A entrega descrita nesta página contempla as interfaces, o protótipo e as orientações para o desenvolvimento.
Quanto tempo leva para criar o protótipo?
O prazo depende da quantidade e da complexidade dos fluxos, dos materiais disponíveis, dos cenários necessários e das revisões previstas. Analiso esses pontos antes de definir a proposta.