Vamos voltar a Ana mais uma vez
Ana deixou o notebook e quer uma coisa muito simples: saber em que situação ele está. Ela não quer “navegar por um sistema”; quer resolver essa necessidade.
Antes da tela, pense no que Ana vive
Ana entrega o equipamento, espera, recebe um orçamento, decide e depois retira o notebook. Essa sequência de momentos forma a jornada do usuário.
| Momento | O que Ana tenta fazer | O problema atual |
|---|---|---|
| Entrega | Explicar o problema | Informação pode ficar espalhada. |
| Espera | Saber se houve avanço | Precisa telefonar ou mandar mensagem. |
| Orçamento | Decidir | A decisão pode ficar solta numa conversa. |
| Retirada | Confirmar o que foi feito | Nem sempre tudo está reunido. |
Chamamos isso de jornada porque estamos olhando a experiência inteira, e não apenas uma tela.
Agora aproxime a lupa de uma única tarefa
Vamos observar apenas a consulta da ordem. O caminho pode ser:
Essa sequência é o fluxo do usuário: os passos que a pessoa percorre para alcançar um objetivo.
Antes de caprichar no visual, rabisque a estrutura
Não precisamos começar escolhendo cor, fonte ou ícone. Primeiro queremos saber: o que Ana precisa enxergar e onde ela precisa agir?
Um esboço simples dessa estrutura é chamado de wireframe.
Consultar minha ordem
Acompanhe a situação do equipamento.
Aguardando aprovação do orçamento
É um desenho de baixa fidelidade: simples de propósito, porque ainda estamos discutindo organização e compreensão.
Protótipo: uma simulação que podemos experimentar
Agora queremos clicar, mudar a situação da ordem e observar o que acontece. Para isso usamos um protótipo: uma simulação da solução antes de construir o sistema completo.
Ele não precisa ter banco de dados real, segurança completa ou todas as integrações. Ele serve para responder perguntas sobre a experiência e o comportamento.
Wireframe × protótipo
O wireframe ajuda a discutir como a informação está organizada. O protótipo permite experimentar o que acontece quando alguém usa.
Não pergunte “você gostou?”
Se perguntarmos apenas se a pessoa gostou, podemos receber uma opinião educada e aprender pouco.
Dê uma tarefa real
Instrução ao participante: “Imagine que você deixou seu notebook na assistência ontem. Descubra em que situação está a ordem.”
Depois observe. Onde a pessoa para? O que tenta clicar? Qual palavra não entende? Que informação procura?
Não ensine o caminho durante o teste. Se você mostrar onde clicar, não saberá se a interface conseguiria orientar a pessoa sozinha.
Uma sugestão não vira requisito automaticamente
Se alguém disser “coloque um botão vermelho”, não anote imediatamente “botão vermelho” como requisito. Primeiro descubra o problema por trás da sugestão.
Talvez a pessoa esteja dizendo: “eu não consegui perceber onde deveria clicar”. Essa é a evidência que importa.
Acessibilidade também aparece na conversa com o usuário
Se a pessoa não consegue ler, distinguir ou acionar um elemento, a interface falhou para ela. Por isso devemos observar contraste, tamanho, rótulos claros, uso de teclado e mensagens compreensíveis desde cedo.
Exemplo simples
Não mostre apenas uma cor verde ou vermelha. Escreva também Aprovado ou Recusado. A cor reforça a informação; não deve ser a única forma de transmiti-la.
E se o protótipo mostrar que nossa ideia estava errada?
Ótimo: descobrimos antes de programar tudo. Se Ana não entende uma palavra ou não consegue localizar a situação da ordem, voltamos ao requisito, ao fluxo ou ao próprio texto da interface e corrigimos.
O protótipo não serve para provar que estávamos certos. Serve para aprender antes de gastar mais.
Faça agora
- Abra o protótipo da Conecta, leia a contextualização inicial e siga o roteiro principal da OS #1042 até “Pronto para retirada”.
- Teste os caminhos complementares: orçamento recusado e abertura de uma nova ordem.
- Conclua os três desafios da validação guiada, registrando evidência, artefato de origem, decisão justificada e forma de reteste.
- Agora volte ao seu próprio backlog e escolha uma história prioritária.
- Descreva a jornada e o fluxo do usuário dessa história.
- Crie um wireframe de baixa fidelidade.
- Defina uma tarefa realista para outra pessoa tentar executar sem receber instruções de uso.
- Observe o teste e registre pelo menos três evidências antes de decidir se algo precisa mudar.
- Faça uma revisão básica de acessibilidade e reteste o que foi alterado.
O que a pessoa tentou fazer
Registre o que aconteceu durante o teste, onde houve dificuldade e o que a evidência realmente justifica alterar.
Checkpoint 7 — A pessoa consegue sozinha?
Seu protótipo consegue orientar o usuário sem você explicar onde clicar? E, quando algo falha, você consegue voltar à origem e corrigir o entendimento?
O protótipo ainda não prova tudo
A interface pode parecer ótima e, mesmo assim, o sistema real ser lento, inseguro ou falhar ao conversar com outros serviços.