O que deve testar antes de aprovar o redesenho de uma aplicação empresarial?

Imagine que os novos ecrãs têm bom aspeto. O seu fornecedor mostra-lhe como encontrar uma encomenda, alterá-la e guardá-la. Agora pedem-lhe que aprove o redesenho para que o desenvolvimento possa avançar.

Antes de concordar, deixe alguém que vai usar a aplicação realizar uma tarefa importante. Explique a situação e o resultado de que precisa, e observe o que acontece. Quem segue uma apresentação tem alguém a mostrar-lhe o caminho. Quem trata de um pedido de um cliente tem de o encontrar por si.

Comece pelo trabalho que importa

Escolha tarefas que as pessoas fazem com frequência ou em que um erro possa causar problemas. Se uma situação excecional alterar o que alguém precisa de fazer, inclua-a também. O âmbito adequado depende da sua aplicação e da decisão que precisa de tomar.

Considere um exemplo hipotético. Um funcionário que trata de encomendas recebe o pedido de um cliente para alterar a morada de entrega antes de a encomenda ser expedida. Precisa de encontrar a encomenda certa, corrigir a morada e perceber se a alteração foi aplicada.

Prepare encomendas de exemplo com dados fictícios de clientes. Dê ao funcionário uma mensagem credível do cliente e informação suficiente para identificar a encomenda. Não introduza dados reais de clientes nem da empresa num protótipo que não esteja preparado para os proteger.

Depois, peça-lhe que trate do pedido. Evite instruções como «abra Encomendas, escolha Editar e prima Guardar». Esses passos dão-lhe a resposta que está a tentar descobrir.

Deixe experimentar quem provavelmente vai usar a aplicação

Escolha alguém que faça este tipo de trabalho ou que provavelmente o venha a fazer. Se os funcionários corrigem encomendas, um gestor que já conhece os ecrãs propostos não os pode substituir. Inclua outras funções quando o trabalho delas levantar questões diferentes.

Use condições relevantes para a tarefa. Quem passa o dia à secretária pode depender do teclado. Quem consulta encomendas no telemóvel tem outro ecrã e outra forma de introduzir dados. Se as pessoas usam tecnologias de apoio, prepare a configuração relevante e confirme se o protótipo a suporta.

As orientações GOV.UK sobre testes de usabilidade moderados descrevem a observação de utilizadores reais ou prováveis a tentar realizar tarefas credíveis. Pode aplicar esse princípio ao trabalho específico que precisa de rever, sem reproduzir todo um programa governamental de investigação.

Observe para onde o funcionário olha, quando hesita, se escolhe um caminho errado ou não repara em alguma informação. Ouça o que pensa que aconteceu. Se tiver de ajudar, registe onde e como. Chegar ao fim com indicações diz-lhe algo diferente de chegar ao fim sem ajuda.

«Gosto do aspeto» é uma opinião útil sobre as preferências de alguém. «Pensei que a morada já estava guardada, mas ainda estava no modo de edição» indica um problema concreto que pode investigar.

Agora imagine que a encomenda já seguiu para expedição

No mesmo exemplo hipotético, o cliente pede a alteração demasiado tarde para uma correção normal. O funcionário consegue perceber o estado atual da encomenda e decidir o que fazer a seguir? Talvez precise da aprovação de um gestor ou de contactar a equipa de expedição.

Defina qual deve ser o passo seguinte na sua empresa e deixe o funcionário experimentá-lo. Inclua os ecrãs e as opções relevantes se o protótipo os conseguir mostrar. Procure um resultado claro: o funcionário sabe se a morada foi alterada, se outra pessoa tem de agir e que resposta pode dar ao cliente?

Um aviso simulado pode mostrar se o texto é compreensível. Não prova que a aplicação em funcionamento vai impedir uma alteração não autorizada nem enviar uma mensagem à equipa de expedição. Reserve essas perguntas para verificações que as possam responder.

Escolha um protótipo capaz de responder à sua pergunta

Um esboço pode ajudar a discutir o que deve aparecer num ecrã e se a ideia proposta faz sentido. Um protótipo interativo pode permitir que alguém encontre uma encomenda, passe de um ecrã para outro e interprete uma confirmação, desde que essas partes tenham sido preparadas. Explique a todos que partes funcionam e quais são simuladas.

Se quer perceber se o funcionário consegue encontrar o percurso para corrigir a encomenda, deixe-o experimentá-lo. Se está a decidir se um aviso é claro, mostre-o na situação em que apareceria. Perguntar se alguém pensa que conseguiria usar um ecrã dá-lhe uma previsão; observar uma tentativa mostra o que a pessoa realmente faz.

No seu relato de 27 de agosto de 2014 sobre a utilização de protótipos no GDS, Katherine Alsop descreveu a diferença entre uma demonstração estável para as partes interessadas e protótipos alterados durante a investigação. Também observou que a investigação num serviço em funcionamento pode revelar problemas de tempo de resposta e tratamento de erros que não aparecem num protótipo.

Isto é importante quando aprova o trabalho. Uma mensagem interativa «Guardado» pode ajudar a perceber se o funcionário compreende o resultado. Para verificar se os dados certos foram guardados, se os pedidos repetidos são tratados em segurança e se os sistemas ligados receberam a alteração, são necessárias verificações adequadas da implementação. A segurança, as permissões aplicadas pelo sistema e a velocidade também precisam de evidências nas partes relevantes da aplicação em funcionamento.

Observar pessoas com a configuração de apoio que usam habitualmente pode revelar barreiras práticas. Como explicam as orientações do W3C para envolver utilizadores na avaliação da acessibilidade, esta avaliação deve acompanhar a verificação face às normas de acessibilidade. Concluir estas tarefas não prova que a aplicação cumpre as normas de acessibilidade. Se o protótipo não suportar uma configuração necessária, registe essa limitação e planeie a verificação adequada mais tarde.

Saia da reunião com uma decisão que consiga explicar

Registe o que observou enquanto ainda está fresco. Mantenha o registo prático:

• Quem experimentou o quê: a função da pessoa, a tarefa, o dispositivo e a forma de introduzir dados, além das partes suportadas pelo protótipo.
• O que aconteceu: se chegou ao resultado pretendido, onde teve dificuldades e de que ajuda precisou. Separe as observações das suposições sobre a causa.
• O que alterar e voltar a testar: identifique o texto confuso, a informação em falta ou o passo seguinte pouco claro. Depois da alteração, deixe alguém voltar a tentar o trabalho afetado.
• O que ainda precisa de uma aplicação em funcionamento: registe as perguntas em aberto, quem as vai verificar e quando. No nosso exemplo, pode incluir quem pode aprovar uma alteração tardia e como a equipa de expedição recebe o aviso.

Se está a preparar o redesenho de uma aplicação empresarial, o nosso trabalho de design pode ser um ponto de partida para conversar sobre quem usa a aplicação, o que precisa de fazer e que decisões quer tomar.