Interface de aplicação confusa? Encontre onde a tarefa se perde

Para diagnosticar uma interface de aplicação confusa, observe os respetivos ecrãs, controlos e respostas enquanto alguém tenta realizar uma tarefa suportada pela aplicação. Procure o primeiro ponto em que a ação seguinte deixa de ser clara. Compare o que a pessoa espera com aquilo que a aplicação faz e comunica. Uma gravação falhada ou uma funcionalidade em falta exige uma correção diferente da necessária para um rótulo ou percurso pouco claro.

Imagine alguém a tentar alterar uma reserva já existente. Essa pessoa abre vários menus, regressa ao ecrã inicial e pede ajuda a um colega. Essa sequência é um ponto de partida para uma observação. Por si só, não permite explicar se a pessoa desinstala posteriormente a aplicação nem qual dos ecrãs precisa de ser reformulado.

Por que razão se perde o passo seguinte?

As pessoas podem compreender o objetivo e, ainda assim, não detetar uma ação ou resposta pouco clara. Procuramos a primeira divergência visível entre a tarefa pretendida e o ecrã encontrado. Mantenha a explicação em aberto até verificar a operação. Aquilo que parece ser um problema de navegação também pode ser um pedido falhado ou um resultado que o produto não suporta.

O texto sugere uma ação diferente. Uma pessoa pode esperar outro ecrã de revisão depois de tocar em Continuar, mas a aplicação envia imediatamente um pedido. As orientações da Apple para botões recomendam que a finalidade seja clara. Compare a expectativa com o efeito real antes de escolher um rótulo de substituição.

O resultado permanece incerto. Alguém volta a tocar porque não consegue perceber se a aplicação aceitou o pedido. Inspecione o que foi efetivamente guardado e o que o ecrã comunicou. Uma confirmação em falta e uma operação falhada exigem correções diferentes.

As orientações de introdução de dados surgem depois do erro. Verifique se o campo explica o valor de que precisa.

Para conteúdos Web, o critério do W3C relativo a rótulos ou instruções exige rótulos ou instruções quando o conteúdo requer a introdução de dados. Utilize essa referência para ecrãs Web dentro de uma aplicação. As aplicações nativas exigem uma análise de plataforma separada.

O percurso perde o contexto. Alguém regressa de um ecrã de detalhes e não consegue recuperar o elemento que estava a alterar. Registe esse ponto de partida, a ação escolhida e o ecrã resultante. Mantenha a primeira transição confusa suficientemente precisa para poder ser reproduzida.

Como diagnosticar uma interface de aplicação confusa?

Comece com um resultado suportado e um estado inicial comparável. Utilize uma conta de teste e dados de teste seguros para ações que enviem, cobrem, eliminem ou afetem outra pessoa. Escreva o objetivo sem mencionar o menu ou controlo que conduz até ele. Pretende descobrir o que a pessoa consegue encontrar e compreender antes de lhe fornecer uma explicação.

1. Defina a conclusão. Numa alteração de reserva, o resultado pretendido é um pedido enviado ou uma nova reserva confirmada? Verifique qual dos resultados esta versão e esta conta conseguem suportar.
2. Registe o estado inicial. Anote a versão da aplicação, o dispositivo, o idioma, as permissões e se a reserva já existe. A conta de um administrador pode apresentar um percurso diferente do apresentado pela conta de um cliente.
3. Observe sem indicar o controlo. Peça à pessoa que tente alcançar o objetivo. Registe o ecrã que escolhe, o rótulo que lê e aquilo que espera. Se prestar ajuda, registe-a. A conclusão posterior não apaga essa ajuda.
4. Verifique o resultado em separado. Compare a resposta visível com a reserva guardada. Volte a abri-la na conta de teste ou consulte o registo de teste do prestador. Um toque ou um ecrã com aparência de sucesso não comprova que a atualização pretendida ocorreu.

Se inspecionar a aplicação sem outra pessoa, registe aquilo que consegue reproduzir e mantenha essa limitação visível. O seu conhecimento do produto altera a tarefa. Uma observação posterior com alguém que não o conhece fornece provas diferentes.

Analise esta tarefa de reserva fictícia

Considere uma aplicação inventada para reservar aulas que permite pedir outra sessão. O prestador tem de aceitar esse pedido antes de a reserva mudar. As notas seguintes ilustram como investigar um mal-entendido. Não utilizámos uma aplicação, conta ou participante real neste exemplo e não testámos o texto proposto.

A divergência observada diz respeito ao significado da ação. Um rótulo diferente é uma hipótese a testar em relação à operação real. Se o pedido nunca chegar ao prestador, investigue também a operação falhada. Se a confirmação imediata for essencial para o produto, essa é uma decisão de produto distinta, não algo que um rótulo de botão possa proporcionar.

Escreva uma observação antes da respetiva interpretação. “Abriu a reserva, tocou em Alterar reserva e esperou uma confirmação” descreve um comportamento neste exercício fictício. “A interface é má” ignora a pergunta a que ainda tem de responder.

Faça a menor alteração que responda à observação

Escolha uma correção que resolva a divergência registada e preserve a operação pretendida. Comece pelo texto, pelas instruções ou pelo feedback quando estes forem os aspetos incertos. Uma estrutura de navegação alterada ou uma reformulação mais ampla exige uma razão fundamentada na tarefa. Mantenha as falhas funcionais visíveis para que uma explicação mais clara não oculte uma operação que continua a falhar.

1. Experimente uma proposta focada. Para a reserva fictícia, mostre um rótulo de ação proposto e o estado resultante num protótipo clicável. As nossas auditorias e protótipos de UX para aplicações seguem esta sequência da tarefa ao protótipo. Compare aquilo que a pessoa espera antes de tocar com o estado que reconhece depois. Não descreva o rótulo proposto como uma melhoria comprovada.

2. Verifique um percurso de erro. O critério de identificação de erros do W3C para conteúdos Web exige que um erro de introdução de dados detetado automaticamente identifique o elemento afetado e descreva o erro em texto. Um contorno colorido, por si só, deixa essa explicação em falta. Os controlos nativos e uma análise completa de acessibilidade exigem verificações próprias da respetiva plataforma.

3. Verifique a resposta no ecrã e com tecnologia de apoio. Para conteúdos Web, o critério do W3C relativo a mensagens de estado aborda a disponibilização de alterações de estado definidas às tecnologias de apoio sem deslocar o foco do controlo atual. Verifique o que aparece no ecrã e aquilo que as ferramentas de apoio conseguem detetar. Um leitor de ecrã, por exemplo, é um programa que pode ler em voz alta o conteúdo da interface. Este critério selecionado não certifica a aplicação, não define um objetivo de tempo de resposta nem repara uma operação lenta.

4. Acompanhe a transição para a Web. Quando a mesma conta ou o mesmo percurso de reserva passa para uma página Web, inclua essa transição no teste. O desenvolvimento de sites e aplicações Web deve preservar o texto da tarefa e o seu estado real nessa passagem.

O que deve verificar depois da alteração?

Repita a mesma tarefa pretendida a partir de um estado comparável e registe o que aconteceu. Mantenha a versão da aplicação, o dispositivo, o idioma e a ajuda visíveis junto do resultado. Uma comparação útil diz respeito à tarefa observada: se a pessoa encontrou a ação, compreendeu o respetivo efeito e reconheceu o resultado real. Mantenha qualquer conclusão empresarial mais abrangente em aberto até dispor de provas que a sustentem.

Registe em conjunto a conclusão e a ajuda, o primeiro desvio errado, os erros de introdução de dados que a pessoa não conseguiu interpretar e se confundiu um pedido com uma confirmação. Repita as verificações relevantes com o idioma e a configuração de acessibilidade em análise. Inspecione rótulos mais longos e as informações disponíveis através dessa configuração, em vez de pressupor que o ecrã em inglês representa todas as versões.

Se já registar ações da aplicação, como o início de um pedido de alteração de reserva ou a sua chegada ao prestador, verifique se os registos correspondem a esses estados reais. Acompanhe as alterações nas perguntas ao apoio relativas ao mesmo percurso. A falta de transferências da aplicação é um problema de aquisição separado. O nosso guia para uma aplicação que não recebe transferências começa antes de alguém abrir o produto.

Uma repetição bem-sucedida pode descrever essa observação. Não permite determinar por que razão as pessoas desinstalam a aplicação nem atribuir à correção uma alteração na retenção. Registe a próxima questão por resolver junto da pessoa responsável por a verificar.

Onde intervimos

Começamos pela tarefa suportada, pela primeira transição pouco clara e pelas provas necessárias para escolher uma correção. Podemos transformar esses elementos num protótipo, verificar o percurso implementado e incluir o seu equivalente Web. Leve uma descrição da tarefa e do ponto onde esta parou para uma conversa sobre o projeto. Remova os nomes dos clientes e outras informações pessoais de qualquer exemplo que partilhe.

← Todos os artigos