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.