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.

As orientações de Marieke McCloskey, de 12 de janeiro de 2014, sobre cenários de tarefas explicam esta diferença: dê às pessoas um contexto significativo e um objetivo sem lhes revelar o percurso na interface.

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.

Poderá então aprovar a direção apoiada pelas tentativas, pedir uma revisão onde as pessoas tiveram dificuldades ou adiar uma decisão específica até haver evidências adequadas. Pode fazer as três coisas em diferentes partes do redesenho. Aprovar os ecrãs das encomendas não significa aceitar uma integração com a expedição que ainda não foi testada.

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.