Encontrando problemas de usabilidade antes do lançamento do HandsUP

O desafio

O HandsUP possuía uma estrutura com módulos temáticos, níveis de dificuldade, missões e atividades.

O Product Manager solicitou a pesquisa antes do lançamento para responder uma pergunta principal:

As pessoas conseguem compreender a estrutura do HandsUP e concluir suas atividades sem dificuldades relevantes de usabilidade?

Uma interação exigia atenção especial: a atividade de reconhecimento de sinais.

Por utilizar uma tecnologia nova, o time ainda precisava entender se a sequência de ações e os feedbacks da interface eram suficientemente claros.

O estudo avaliou exclusivamente usabilidade, não aprendizagem ou qualidade pedagógica do conteúdo.

Meu papel e abordagem

Conduzi a pesquisa de ponta a ponta de forma individual.

Fui responsável pelo plano de pesquisa, roteiro, critérios e execução do recrutamento, moderação das sessões, análise, aplicação do SUS, classificação dos achados e apresentação dos resultados para Produto, Design e Engenharia.

Foram recrutadas 10 pessoas da própria empresa que:

• não estavam envolvidas no desenvolvimento do HandsUP;
• nunca haviam utilizado a funcionalidade;
• tinham interesse em aprender Libras.

O recrutamento interno permitiu testar uma funcionalidade ainda não lançada sem ampliar o acesso ao produto para participantes externos.

Pessoas surdas não participaram desta rodada porque o HandsUP tinha como foco pessoas em processo de aprendizagem de Libras, e o conhecimento prévio da língua poderia alterar a experiência nas atividades avaliadas.

Estrutura do teste

As sessões foram moderadas e remotas.

Como testar todo o HandsUP tornaria as sessões extensas, defini um recorte capaz de representar diferentes níveis de complexidade.

Foi testado:

• 1 módulo;
• 3 níveis de dificuldade;
• todas as missões do nível 1;
• 3 missões do nível 2;
• 2 missões do nível 3.

Durante as sessões, observei principalmente:

• compreensão da estrutura entre níveis, missões e atividades;
• navegação;
• entendimento das ações esperadas;
• clareza dos feedbacks;
• continuidade entre atividades;
• interação com o reconhecimento de sinais.

Ao final, apliquei o System Usability Scale (SUS) como indicador complementar.

Os achados foram classificados por tipo — como problema de usabilidade, bug, observação ou sugestão — e por severidade, facilitando o handoff para as equipes responsáveis.

Principais achados

1. Navegação entre missões e atividades

A estrutura:

nem sempre deixava claro para as pessoas onde estavam e como avançar.

Os testes indicaram necessidade de melhorar elementos de orientação e progressão dentro das trilhas.

2. Reconhecimento de sinais

A nova atividade concentrou alguns dos problemas mais relevantes.

Dois padrões apareceram:

Feedback insuficiente

As pessoas nem sempre entendiam se uma ação havia sido reconhecida ou qual era o resultado da interação.

Sequência de ações pouco clara

Em alguns momentos, não ficava evidente qual deveria ser o próximo passo para concluir a atividade.

Esses achados indicaram a necessidade de reestruturar o fluxo e aumentar os feedbacks da interface.

3. Bugs

As sessões também revelaram bugs na versão pré-lançamento, que foram registrados e encaminhados para Engenharia junto com os demais achados.

SUS como evidência complementar

O SUS ficou entre 68 e 70 pontos, classificado como bom dentro da interpretação adotada no projeto.

O resultado indicava uma percepção geral positiva, mas não eliminava os problemas específicos observados durante as sessões.

Por isso, utilizei o SUS como indicador complementar, enquanto a observação qualitativa mostrou onde estavam os principais pontos de melhoria.

Da pesquisa para o produto

Apresentei os resultados para Produto, Design e Engenharia com os achados classificados por tipo e severidade.

Minha atuação terminou no handoff. Não participei da priorização final nem do redesign, mas acompanhei posteriormente os Product Designers aplicando mudanças baseadas nos resultados da pesquisa.

Entre os principais desdobramentos:

• o fluxo de reconhecimento de sinais foi reestruturado;
• novos feedbacks foram adicionados à atividade;
• bugs encontrados nos testes foram corrigidos antes do lançamento;
• melhorias identificadas foram incorporadas ao roadmap.

Após as alterações, houve melhora na conclusão da atividade de reconhecimento de sinais, embora eu não tenha tido acesso às métricas quantitativas posteriores ao lançamento.

Impacto

O estudo reduziu riscos de usabilidade antes que uma funcionalidade baseada em tecnologia nova chegasse ao público.

Além de identificar problemas de navegação e bugs, a pesquisa evidenciou que o fluxo de reconhecimento de sinais precisava de mudanças antes do release.

A classificação dos achados por tipo e severidade também forneceu uma base estruturada para Produto, Design e Engenharia discutirem prioridades e implementação.

Limitações e aprendizados

O recrutamento interno reduziu a diversidade da amostra em relação ao público real do produto.

O estudo também utilizou apenas um recorte do HandsUP e não incluiu pessoas surdas, portanto seus resultados não representam a experiência desse público com a funcionalidade.

Minha participação terminou após o handoff, e não conduzi uma nova rodada formal após o redesign nem acompanhei métricas pós-lançamento.

Em uma nova rodada, adicionaria métricas por tarefa — como taxa de conclusão, erros e necessidade de ajuda — e realizaria um segundo teste depois das alterações para verificar se os principais problemas haviam sido resolvidos.