MeasuringU: Avaliando a Gravidade dos Problemas de Usabilidade

Se apenas um em cada 1000 usuários encontra um problema com um site, então é um problema menor.

Se essa frase o incomodou, deveria.

Pode ser que esse único problema tenha resultado na publicação inadvertida de informações financeiras de um visitante no site para o mundo ver.

Or poderia ser uma ligeira hesitação com um rótulo numa parte obscura de um website.

É parte da responsabilidade dos profissionais de experiência do utilizador ajudar os programadores a tomar decisões sobre o que corrigir.

A contabilização da frequência e gravidade do problema são dois ingredientes críticos ao comunicar a importância dos problemas de usabilidade. Eles também são dois dos inputs necessários para uma Análise de Efeitos de Modos de Falha (FMEA), um processo de priorização mais estruturado.

Freqüência do Problema

Medir a freqüência de um problema é geralmente simples. Pegue o número de usuários que encontram um problema dividido pelo número total de usuários. Por exemplo, se 1 em cada 5 usuários encontrar um problema, a frequência do problema é .20, ou 20%. A freqüência do problema pode então ser apresentada em uma matriz de usuário por problema. Ela também pode ser usada para estimar o tamanho da amostra necessária para descobrir uma certa porcentagem dos problemas.

Severidade do problema

Avaliar a gravidade de um problema é menos objetivo do que encontrar a freqüência do problema. Há uma série de maneiras de atribuir classificações de gravidade. Eu selecionei algumas das abordagens mais populares descritas na literatura, e vou contrastar essas com o método que usamos em Measuring Usability.

Embora existam diferenças nas abordagens, em geral cada método propõe uma estrutura similar: um conjunto de categorias ordenadas refletindo o impacto que o problema tem sobre o usuário, de menor para maior.

Jakob Nielsen

Jakob Nielsen propôs a seguinte escala de quatro passos há algumas décadas:

0 = Não concordo que este seja um problema de usabilidade
1 = Somente problema cosmético: não precisa ser corrigido a menos que haja tempo extra disponível no projeto
2 = Problema de usabilidade menor: a correção deve ter baixa prioridade
3 = Grande problema de usabilidade: importante de corrigir, portanto deve ter alta prioridade
4 = Catástrofe de usabilidade: imperativo para corrigir isso antes que o produto possa ser lançado

Jeff Rubin

No influente livro de Jeff de 1994, ele delineou a seguinte escala para a gravidade do problema:

4: Inutilizável: O usuário não pode ou não quer usar uma determinada parte do produto devido à forma como o produto foi projetado e implementado.
3: Severa: O usuário provavelmente usará ou tentará usar o produto aqui, mas será severamente limitado em sua capacidade de fazê-lo.
2: Moderado: O usuário será capaz de usar o produto na maioria dos casos, mas terá que realizar algum esforço moderado para contornar o problema.
1: Irritante: O problema ocorre apenas intermitentemente, pode ser contornado facilmente, ou depende de um padrão que está fora dos limites do produto. Também pode ser um problema cosmético.

Dumas e Redish

Joe Dumas e Ginny Redish, em seu livro seminal, A Practical Guide to Usability Testing, oferecem uma categorização similar a Rubin e Nielsen, mas adicionam uma dimensão global versus local aos problemas. A idéia é que se um problema afeta a navegação global de um site, ele se torna mais crítico do que um problema local afetando apenas, digamos, uma página.

Nível 1: Impede a conclusão da tarefa
Nível 2: Cria atraso significativo e frustração
Nível 3: Os problemas têm um efeito menor na usabilidade
Nível 4: Melhorias/sugestões sutis e possíveis

Chauncey Wilson

Chauncey Wilson sugere que as escalas de severidade de usabilidade devem corresponder à classificação de severidade dos sistemas de rastreamento de bugs em uma empresa. Ele oferece uma escala de cinco pontos com os seguintes níveis. Anteriormente, ele usou uma variante similar de quatro pontos.

Nível 1: Erro catastrófico causando perda irrevogável de dados ou danos ao hardware ou software. O problema pode resultar em falhas em larga escala que impedem muitas pessoas de fazer o seu trabalho. O desempenho é tão ruim que o sistema não consegue atingir os objetivos do negócio.
Nível 2: Problema grave, causando possível perda de dados. O usuário não tem nenhuma solução para o problema. O desempenho é tão ruim que o sistema é universalmente considerado ‘lamentável’.
Nível 3: Problema moderado, não causando perda permanente de dados, mas desperdiçando tempo. Há uma solução para o problema. As inconsistências internas resultam em um aumento da aprendizagem ou das taxas de erro. Uma função ou característica importante não funciona como esperado.
Nível 4: Problema menor mas irritante. Geralmente causa perda de dados, mas o problema torna os usuários um pouco mais lentos. Há violações mínimas das diretrizes que afetam a aparência ou percepção, e erros que são recuperáveis.
Nível 5: Erro mínimo. O problema é raro e não causa perda de dados ou grande perda de tempo. Menor problema estético ou de consistência.

O Wilson e Dumas &As escalas de tons vermelhos têm o problema mais grave com números mais baixos. Isso porque nos primeiros tempos da computação, os bugs severos eram chamados de “bugs de nível 1” e aqueles tinham que ser corrigidos antes do lançamento do produto (Dumas, Personal Communication 2013). Nesta escala, os problemas são definidos em termos de perda de dados em vez de seu impacto no desempenho ou estado emocional dos usuários.

Molich & Jeffries

Rolf Molich é famoso por sua série de avaliações comparativas de usabilidade (CUE). Ele também é famoso por rever e escrever (muitas vezes de forma crítica) sobre a qualidade dos relatórios de usabilidade. Ele e Robin Jeffries ofereceram uma escala de três pontos.

1. Menor: atrasa o usuário brevemente.
2. Sério: atrasa o usuário significativamente mas eventualmente permite que ele complete a tarefa.
3. Catastrófico: impede que o usuário complete sua tarefa.

Esta abordagem de três pontos é mais simples do que outras, mas tende a depender fortemente de como o problema impacta o tempo na tarefa.

Nossa abordagem

Originalmente, começamos com uma escala de classificação de 7 pontos onde os avaliadores atribuíram à gravidade do problema um valor de cosmético (1) a catastrófico (7), mas descobrimos que era difícil distinguir facilmente entre os níveis 2 e 6. Reduzimos isso para uma escala de quatro pontos semelhante a Rubin, Nielsen e Dumas/Redish acima e os tratamos mais como categorias do que como um continuum.

Embora houvesse muito menos ambiguidade com quatro pontos, ainda encontramos uma distinção obscura entre os dois níveis médios, tanto na atribuição da gravidade como no relato dos níveis de problemas aos clientes.

Então reduzimos nossa escala de severidade para apenas três níveis, juntamente com um para insights, sugestões de usuários ou atributos positivos.

1. Menor: Causa alguma hesitação ou ligeira irritação.
2. Moderado: Causa ocasional falha de tarefa para alguns usuários; causa atrasos e irritação moderada.
3. Crítico: Leva à falha da tarefa. Causa irritação extrema do usuário.

Insight/Suggestion/Positive: Os usuários mencionam uma idéia ou observação que faz ou poderia melhorar a experiência geral.

Resumo

Pus abaixo versões abreviadas destas escalas na tabela para mostrar as semelhanças em alguns dos termos e níveis. Eu também alinhei as escalas de modo que números mais altos indicam problemas mais graves.

Algumas lições desses níveis de gravidade do problema:

1. Não fique obcecado em encontrar o número certo de categorias ou rótulos: Três categorias é provavelmente suficiente, mas fundir escalas com níveis de rastreamento de bugs ou ter mais níveis para gerar mais pontos internos são ambas razões legítimas para ter mais pontos. Uma vez que você escolher um sistema, tente ficar com ele para permitir a comparação ao longo do tempo.
2. Ainda haverá desacordo entre os avaliadores e chamadas de julgamento: Estes são guias grosseiros, não instrumentos precisos. Avaliadores diferentes irão discordar, apesar da clareza dos níveis de severidade. Uma das melhores abordagens é ter múltiplos avaliadores avaliando a gravidade independentemente, calculando a concordância e depois calculando a média das classificações.
3. Os números atribuídos a cada nível são um pouco arbitrários: Não se obcecar muito sobre se os problemas de severidade mais altos devem ter números mais altos ou mais baixos. Prefiro este último, mas é a ordem que tem significado. Embora os intervalos entre as severidades de 1, 2 e 3 sejam provavelmente diferentes, as classificações podem ser usadas para análises adicionais quando se comparam diferentes avaliadores ou severidade e frequência de problemas.
4. Não se esqueça dos pontos positivos: Dumas, Molich & Jeffries escreveu um artigo persuasivo falando sobre a necessidade de apontar resultados positivos. Enquanto um teste de usabilidade é normalmente destinado a descobrir problemas, a compreensão dos positivos encoraja os desenvolvedores e não faz com que você ou sua equipe se deparem como os presságios constantes de más notícias.
5. Trate a freqüência separadamente da severidade: Nós relatamos a frequência de um problema juntamente com a sua severidade. Quando possível, temos um analista separado para avaliar a gravidade de um problema sem saber sua freqüência – um tópico para um blog futuro.