Observe uma tarefa do começo ao fim.
Para encontrar atritos, acompanhe o caminho entre uma intenção e sua conclusão. Observe onde a pessoa hesita, volta, pede ajuda ou abandona. A aparência da tela é parte da experiência; a capacidade de realizar a tarefa também depende da sequência, da linguagem e das respostas do sistema.
Escolha uma situação realista, como solicitar um serviço ou atualizar um cadastro. Apresente o objetivo sem ensinar o caminho. Registre o que aconteceu e o que a pessoa disse, mantendo suas interpretações separadas dessas observações.
Exemplo hipotético. Uma pessoa preenche uma solicitação e chega a um botão escrito “Continuar”. Ela não sabe se verá uma revisão ou se o pedido será enviado. A dúvida está na consequência da ação, mesmo que o botão tenha tamanho e contraste adequados.
Confira o que a interface permite entender.
Antes de adicionar instruções, revise o que já aparece na tela. O título situa a tarefa? Os campos explicam o que pedem? A ação descreve o próximo passo? Informações importantes devem estar próximas da decisão a que se referem.
Formulários são um bom ponto de observação. As orientações da W3C para formulários acessíveis tratam de rótulos, instruções e agrupamento de controles. Esses elementos ajudam a estabelecer uma relação clara entre o pedido e a informação esperada.
No exemplo, “Revisar solicitação” comunica uma ação diferente de “Enviar solicitação”. A escolha do texto precisa corresponder ao comportamento real. Uma confirmação só deve aparecer quando o sistema puder sustentar o que está afirmando.
Cuide de quando a tarefa sai do caminho esperado.
Explore também situações em que há dados ausentes, erro ou interrupção. A mensagem deve permitir localizar o problema e entender como corrigi-lo. Verifique se a pessoa mantém o que já preencheu e consegue retomar sem repetir trabalho desnecessário.
A W3C recomenda identificar os campos com erro e fornecer orientação para a correção. Essa informação também precisa ser acessível a quem navega por teclado ou usa tecnologia assistiva.
Observe o mobile como uma situação de uso própria. O teclado pode ocupar boa parte da tela, uma mensagem pode ficar fora da área visível e um elemento fixo pode cobrir a ação principal. Teste a tarefa nessas condições.
Escolha o ajuste pela consequência do atrito.
Nem todo desconforto tem o mesmo peso. Registre se o problema impede a conclusão, provoca erro ou apenas exige mais esforço. Considere também em quais situações aparece e quanta evidência você tem antes de generalizar.
Faça uma mudança com uma intenção clara e observe novamente. Se a hipótese era tornar a consequência de uma ação compreensível, a verificação deve olhar para essa compreensão. Uma nova aparência, sozinha, não demonstra que o problema foi resolvido.
Registre o atrito de um jeito que ajude a corrigi-lo.
Um comentário como “a tela confunde” não explica a decisão que o time precisa tomar. Para transformar a observação em trabalho de produto, sugerimos manter juntos a situação, o comportamento e sua consequência.
- Intenção
- Qual tarefa a pessoa estava tentando concluir e que informação tinha naquele momento.
- O que aconteceu
- A ação, a fala ou a interrupção observada. Diferencie “voltou à tela anterior” de “não entendeu o formulário”, que ainda é uma interpretação.
- Consequência
- Se houve impedimento, erro, necessidade de ajuda ou esforço adicional. Registre também como a pessoa conseguiu continuar.
- Hipótese e verificação
- O que mudaria na interface e qual comportamento indicaria que a mudança ajudou. Verifique novamente com uma tarefa comparável.
No exemplo do botão, o ajuste pode começar pelo rótulo e pela tela de revisão. A verificação seria observar se a pessoa prevê corretamente o próximo passo, sem receber essa explicação de quem conduz a sessão.
Uma sessão revela possibilidades de melhoria, mas não determina a frequência de um problema em toda a base. Cruze as observações com outras situações e com dados disponíveis antes de dimensionar o impacto. Priorize a gravidade e a evidência, sem transformar cada preferência individual em uma regra de interface.
Essa leitura alimenta a evolução contínua do produto. Quando o problema ainda está pouco definido, comece por entender o que vale resolver.
Referências consultadas
W3C WAI: Forms Tutorial e Validating Input. Referências para rótulos, instruções e recuperação de erros. O roteiro de observação é uma proposta da Antídra; o exemplo é hipotético.
