Otimizando a experiência do usuário na etapa de Quality Assurance (QA)

QA, ou Quality Assurance (Controle de Qualidade) é uma prática comum nas etapas finais do processo de construção de produtos digitais. Em algumas empresas essa etapa pode receber um nome diferente, mas para o propósito desse post vou me referir a ela simplesmente como “QA”.

Nessa etapa, os engenheiros de QA normalmente testam cada uma das funcionalidades que foram implementadas e verificam se elas estão funcionando corretamente e dentro do esperado. Se encontrarem algum erro, normalmente o encaminham para o time de Desenvolvedores (caso seja um problema técnico de implementação no front-end ou back-end) ou de Design (caso seja um problema visual, de redação ou no fluxo de navegação).

É como se nessa etapa você passasse um pente fino pelo produto, para verificar problemas tanto do ponto de vista criativo, quanto do ponto de vista técnico.

O problema é: nem sempre os engenheiros de QA são profissionais treinados para verificar a qualidade da experiência do usuário. Não porque sejam profissionais incapazes — longe disso –, mas porque para esse tipo de verificação é preciso ter um entendimento mais amplo do contexto no qual a experiência acontece.

O trabalho de UX não acaba na Tecnologia

Ainda é comum, no entanto, que profissionais de UX considerem que seu trabalho esteja terminado quando os desenvolvedores começam a construir o produto que foi desenhado. Talvez por herança das metodologias waterfall (em cascata), onde o trabalho de uma área termina quando os entregáveis são repassados para a área seguinte (como em uma linha de produção do período industrial).

“– Ah, nessa fase eu só acompanho com os desenvolvedores para ver se eles têm alguma dúvida, mas é bem mais tranquilo.”

Mas mesmo quando o produto já está 100% implementado, o trabalho de UX ainda não terminou.

Pausa para lembrar o significado de UX: “Experiência do Usuário”.

• Se o usuário clica em um botão que não funciona, isso causará um problema na experiência do usuário.
• De forma similar, se o usuário clica em um botão que não funciona da forma que ele espera que funcione, isso também causará um problema na experiência do usuário.

Essa linha é muito tênue, mas uma coisa é nítida nessa história: não dá para esperar que um engenheiro de QA deduza qual é a forma que o usuário espera que o botão funcione. Afinal, o engenheiro de QA não esteve presente no processo de design, não conversou com consumidores e muitas vezes não conseguem visualizar o contexto mais amplo onde aquela experiência está acontecendo — e convenhamos, nem é esse o foco do trabalho deles.

Por isso a parceria entre UX Designer e engenheiro de QA é tão importante nas etapas finais do projeto. O UX Designer pode (e deve) ajudar o time de QA e Desenvolvimento a sempre visualizar o contexto mais amplo onde as experiências estão acontecendo: de onde o usuário veio, o que ele tem em mente quando chega ali naquele ponto do fluxo, e o que vai acontecer a seguir.

QA precisa levar em conta o contexto

Pense nas user stories que QA leva em conta na hora de validar uma funcionalidade:

“Como um usuário que acabou de comprar um produto, eu quero avaliar a qualidade do produto com 1 a 5 estrelas”

Se você é um professional de QA, provavelmente vai começar o teste da seguinte forma: com uma página de produto aberta no seu navegador, vai testar se clicando nas estrelas o site irá computar a sua avaliação daquele produto, e se vai exibir uma mensagem de sucesso.

Se você é um UX Designer, pela própria natureza das habilidades que desenvolveu ao longo de sua profissão, você vai pensar de forma mais abrangente sobre como o usuário chega até ali. Provavelmente você vai abrir o email pós-compra que você recebe da loja virtual convidando você a avaliar o produto, vai clicar no link, cair na página do produto, e ali no topo da página vai tentar procurar o botão para fazer um review. Ou então você vai abrir a homepage do site, fazer login, tentar encontrar o link “Meus Produtos”, e ali sim tentar encontrar o link para fazer o review. Será que o fluxo todo está funcionando (do ponto de vista da experiência do usuário) para permitir que a pessoa deixe uma avaliação sobre o produto que comprou?

O teste fica muito mais amplo, certo?

E nessa hora é muito mais provável que vocês encontrem problemas ou bugs que não estariam visíveis caso testassem a funcionalidade em isolamento.

É claro que esse tipo de teste pode ser feito em protótipos navegáveis (ou até mesmo protótipos de papel) antes mesmo da implementação começar. Mas não é porque a usabilidade está boa no protótipo que ela necessariamente estará boa depois que o produto final foi implementado.

Existem vários fatores que ocorrem durante a implementação que terão impacto direto na experiência do usuário: lentidão para carregar as páginas, problemas de login, sessão e cookies, implementação das URLs, decisões sobre a integração entre front-end e back-end, testes de layout em breakpoints específicos para responsive design, mudanças de design nos últimos minutos do segundo tempo, etc.

Esperar que o produto final saia exatamente igual ao layout que você criou no Photoshop é de uma inocência quase imperdoável — a não ser que esse seja o primeiro projeto da sua vida. E culpar os desenvolvedores pelos problemas de implementação sem ter feito nada durante o projeto para melhorar isso é uma irresponsabilidade gritante para quem se proclama o defensor implacável da boa experiência do usuário. Está na hora de mudar isso :)