Se acha que um bom design é caro, devia ver quanto custa um mau design.
Dr. Ralf Speth, CEO, Jaguar Land Rover
Na última década, a experiência do utilizador tornou-se o verdadeiro fator diferenciador entre boas aplicações e aplicações excelentes.
A vertente tecnológica da criação de software é, de certa forma, um problema resolvido. As verdadeiras possibilidades de alcançar um sucesso extraordinário com produtos de software residem na UX. A próxima aplicação revolucionária terá uma interface imediatamente utilizável. Isto conduziu a uma abordagem de desenvolvimento de produtos centrada na UX e baseada em investigação.
Os resultados deste foco falam por si.
Por exemplo, cada dólar investido em UX gera $100 de retorno, de acordo com um relatório da Forrester Research. Além disso, ao longo de um período de 10 anos, um estudo demonstra que o desempenho financeiro de empresas orientadas pelo design supera o do S&P em 219%.
Existe também a história lendária de como a simples alteração do texto de um botão acrescentou $300 milhões às vendas de uma empresa de comércio eletrónico num único ano!
No entanto, apesar de todo este entusiasmo e alarido, por cada aplicação com uma excelente experiência do utilizador, existem várias com uma experiência deficiente ou muito deficiente nesse aspeto. As terríveis são fáceis de identificar: fazem-nos querer abrir um buraco no ecrã do portátil ou atirar o dispositivo móvel pela janela. A seleção natural trata dessas aplicações.
O verdadeiro desafio são as aplicações com uma UX razoável. São aquelas experiências que constituem a proverbial “lasca na sua mente” e em relação às quais, por mais que tente, não consegue perceber por que razão não gosta delas!
Consigo ouvi-lo dizer: “Nós sabemos tudo isto; estou a ler sobre responsabilidade de QA, por amor de Deus, então o que é que isto tem que ver comigo?” Já lá vamos.
A importância da UX
Nos meus primeiros tempos a gerir equipas de engenharia, estávamos a trabalhar num grande projeto de solução de software para um dos nossos clientes. Este projeto fazia parte de uma estratégia mais abrangente de transformação digital que estava a ser implementada para esse cliente. Tratava-se de uma equipa de engenharia típica, constituída principalmente por programadores de software e engenheiros de QA, que utilizava Scrum com sprints de 2 semanas.
Havia uma pequena equipa de UX, mas, na maior parte do tempo, era partilhada entre vários projetos. Normalmente, os profissionais de UX participavam nas reuniões diárias da equipa durante as fases iniciais do projeto, mas, assim que o cliente aprovava o design visual, entregavam todos os modelos do design visual, bem como os fluxos, e passavam a trabalhar noutros projetos.
Durante a primeira demonstração do sprint, o cliente pareceu estar sobretudo preocupado com o facto de o design visual e a interface do utilizador não corresponderem exatamente aos modelos de design. Havia também uma diferença entre a funcionalidade proposta e o que tinha sido efetivamente implementado.
É importante salientar que a diferença não era grande, mas, por mais que tentássemos tranquilizar o cliente, dizendo-lhe que o aspeto de UX seria corrigido durante um dos sprints posteriores, a sua linguagem corporal demonstrava que não estava satisfeito com a situação.
Felizmente, a responsável de QA da nossa equipa interveio, afirmou que aquilo era uma anomalia e que não voltaria a acontecer. E depois fez algo incrível. Permitam-me descrevê-lo:
- Assumiu a responsabilidade de atualizar os seus conhecimentos de UX através de uma leitura intensiva.
- Depois, realizou ela própria uma revisão heurística básica de UX à funcionalidade entregue, falou com os profissionais de UX e obteve a sua ajuda sempre que necessário.
- Criou novas tarefas no JIRA para corrigir a diferença entre o que tinha sido prometido e o que tinha sido entregue — do ponto de vista da UX.
- Marcou uma chamada com o nosso responsável máximo de UX e obteve a sua aprovação para garantir a implementação de um novo processo, no qual os aspetos visuais da aplicação seriam corrigidos durante cada sprint e não apenas no final.
- Por fim, também fez com que os nossos profissionais de QA compreendessem os conceitos básicos de UX, para que pudessem identificar problemas evidentes e ajudar a equipa a resolvê-los atempadamente.
A cereja no topo do bolo? Durante a demonstração do sprint seguinte, o responsável pelo produto/cliente estava radiante e, alguns meses depois, a nossa responsável de QA foi promovida a gestora de QA! 😉
Perspetivas romântica e clássica da realidade
Todo este episódio fez-me pensar na enorme diferença entre a forma como nós, na área da engenharia, vemos uma aplicação e a forma como os clientes e os utilizadores a veem. Robert Pirsig, no seu livro seminal Zen e a Arte da Manutenção de Motociclos, fala de duas perspetivas da realidade: a clássica e a romântica.
Segundo Pirsig, aqueles cuja perspetiva dominante é romântica veem as coisas e avaliam-nas com base na forma como parecem. Estão principalmente interessados naquilo que as coisas são e não se preocupam com a forma como funcionam — a ordem subjacente. Esta é a metade artística da divisão entre arte e ciência.
Por outro lado, nós, engenheiros & cientistas, subscrevemos a perspetiva clássica, segundo a qual a beleza reside nos mecanismos subjacentes à forma exterior. Os engenheiros conseguem ver beleza em código Python ou sob o capô de um automóvel, algo que parece feio a quem se encontra do lado romântico.
Como tudo o resto, esta não é obviamente uma classificação binária, mas sim um contínuo em que a maioria de nós prefere predominantemente uma das perspetivas.
Existem algumas implicações interessantes desta forma de classificar o mundo:
1. A perspetiva dominante da maioria das pessoas é, por defeito, clássica ou romântica, não ambas.
2. As pessoas — pensemos nos clientes, internos ou externos — com uma perspetiva romântica ultrapassam largamente aquelas com uma perspetiva clássica. Se alguma vez teve de desempenhar o papel de suporte técnico para familiares e amigos, sabe do que estou a falar!
3. Muito poucas pessoas conseguem mudar de modo e, mesmo para essas, trata-se de uma atividade que exige esforço.
4. Realidade = clássico + romântico. Não são mutuamente exclusivos. Ambos são aspetos essenciais do todo. A beleza é funcional. A função pode ser bela.
Vejamos as flores, por exemplo. Têm padrões tão magníficos que parecem não ter qualquer função. No entanto, a beleza que vemos nas flores tem uma estrutura subjacente enraizada na matemática: a sequência de Fibonacci rege a estrutura e os padrões que vemos nas flores. A estrutura e a beleza etérea andam de mãos dadas na natureza.
E não se trata apenas de beleza. A disposição das sementes num girassol segue a sequência de Fibonacci e a proporção áurea, de modo a incluir o maior número possível de sementes na flor. Os mesmos princípios aplicam-se à engenharia e à experiência do utilizador.
Isto conduz-nos finalmente ao cerne deste artigo: os profissionais de engenharia da qualidade estão idealmente posicionados para tirar partido destas duas perspetivas aparentemente concorrentes.
Have an account? Log In
O papel da garantia da qualidade de software na UX / usabilidade
Enquanto profissional de testes, teve muito mais experiência com interfaces do que o programador ou utilizador médio.
Testou rigorosa e repetidamente (até à exaustão!) tantas aplicações que poderá ter atingido o nível do pensamento de ordem superior, também conhecido como pensamento 4D no que diz respeito à UX, tal como o proverbial grande mestre de xadrez que pensa em posições, ao contrário deste vosso humilde interlocutor, que tem dificuldade em perceber qual é a próxima peça a mover! ;-)
É por isso que, apesar do enorme avanço em direção à automatização — uma excelente evolução, sem dúvida — há algo a dizer a favor de alguns testes manuais. Afinal, se os seres humanos vão utilizar uma aplicação, faz sentido obter uma perspetiva humana durante os testes.
Como realizar uma análise de UX / usabilidade enquanto engenheiro de testes
Se a garantia da qualidade precisa de ter em conta a UX, deve começar em simultâneo com a fase de conceção, ou seja, no início do ciclo de vida. Eis os passos que pode seguir para incluir a análise de UX nos seus testes e tornar-se um polímata de QA!
Heurísticas de usabilidade para o design de interfaces de utilizador
Familiarize-se com os 10 princípios gerais de design de interação de Jakob Nielsen. Este conjunto de orientações é um ponto de referência fiável para qualquer análise de usabilidade. Tenha estes princípios em consideração nas suas discussões com a equipa de UX, bem como no seu plano de testes. Pode também consultar qualquer um dos vários cursos básicos sobre usabilidade e design de UX.
Aprenda os princípios da acessibilidade
Poderá ter realizado testes de acessibilidade como parte do seu plano de testes no passado, mas compreender os princípios subjacentes à acessibilidade—percetível, operável, compreensível, robusto—dar-lhe-á a capacidade de identificar o que outros poderão não detetar.
A Equipa de UX É o Seu Novo Ponto de Encontro
Não seja um estranho: conheça a equipa de UX do projeto. Colabore com ela. Partilhe o seu plano de testes e obtenha feedback sobre o que pode incluir do ponto de vista da UX.
Os benefícios desta interação funcionam nos dois sentidos, uma vez que o seu plano de testes dará à equipa de design uma visão sobre a viabilidade das funcionalidades de design que pretende propor. Como responsável de QA, a sua interação com a equipa de UX deve ser tão próxima como a que mantém com os programadores.
Inclua a Análise de Dados no Seu Plano de Testes
Os dados analíticos dos utilizadores do produto que está a testar são uma verdadeira mina de ouro de informação para os testadores. A análise de dados pode ajudá-lo a identificar áreas de risco e o comportamento dos utilizadores. Por sua vez, estes dados podem ajudá-lo a identificar e priorizar correções o mais cedo possível no ciclo de vida do produto.
Antecipe os Testes Até Não Poder Antecipar Mais
O produto que está a testar é como um bebé. Precisa de garantir que recebe a ajuda de que necessita desde a conceção do produto. Vá até ao início.
Antes do Desenvolvimento
Teste na fase de design assim que estiver disponível um protótipo. Utilize a sua experiência com aplicações e os seus conhecimentos sobre os princípios de usabilidade e as diretrizes de acessibilidade para verificar se é necessário efetuar alterações ANTES de o produto avançar para a fase de desenvolvimento.
Se a QA ainda não fizer parte da fase de design, faça com que isso aconteça, se possível.
More Articles
Testes Manuais Direcionados
Percorra toda a experiência de utilização do produto, do início ao fim, como parte dos testes manuais. Concentre-se em fazer as perguntas certas, pensando como um utilizador e também como um Engenheiro de QA.
Comece por recuar e observar o produto de uma perspetiva mais abrangente. Gosta da experiência?
Depois, observe-o mais de perto. É fácil de utilizar? Os fluxos são óbvios e intuitivos? São aborrecidos e lentos? Existem sobreposições ou duplicações de ações que possam ser incómodas para o utilizador? O design é utilizável em diferentes tamanhos de ecrã?
Por Fim
O futuro do trabalho pertence àqueles que possuem vários conjuntos de competências complementares que são quase impossíveis de substituir por máquinas (mas consulte o meu artigo sobre IA na automatização de testes para ter uma ideia do que estas podem fazer).
Tornar-se um polímata de QA com competências de UX pode ser uma excelente forma de tirar partido das suas capacidades e experiência naturais, acrescentar muito valor adicional sem despender demasiado esforço nem se afastar demasiado do seu campo de atuação.
É algo que o entusiasma? Ou considera que a UX é apenas tangencial a esta área? Diga-me o que pensa nos comentários abaixo.
Se está pronto para saber mais, aqui está um podcast que pode ler/ouvir: COMO O SOFTWARE DE CÓDIGO ABERTO SIMPLIFICA A INTEGRAÇÃO NA ENGENHARIA DE AUTOMAÇÃO (COM JAMES WALKER E SANJAY KUMAR)
