Não há dúvidas entre os designers de interação, da importância dos testes de usabilidade em projetos de sistemas interativos. Popularizado por Krug, em "Não me faça pensar", os testes podem ser realizados em qualquer momento do ciclo de desenvolvimento de um produto, com custos relativamente baixos e independente do framework de desenvolvimento (ágil ou cascata).
Testes com usuários, realizados de forma ágil, auxiliam designers e desenvolvedores a validar suas idéias, verificando se o modelo conceitual e as soluções de interface condizem com o modelo mental de seus usuários, evitando problemas futuros e diminuido custos com retrabalhos. No entanto, apesar de relativamente fácil, algumas falhas podem comprometer seus resultados...
Falha 1. Tarefas tendenciadasUm ponto crítico e fundamental para um resultado satisfatório em testes de usabilidade é a escolha e especificação das tarefas que o usuário irá realizar. Um erro muito comum que venho observando, é a especificação errada das tarefas, o que pode comprometer por completo o resultado do teste. Exemplo: Imagine que uma equipe esteja avaliando uma ferramenta de blog e que, dentre outros objetivos, deseje avaliar a ferramenta de "widgets", que como no caso desse blog, são os componetes da interface que aparecem na coluna da direta, como busca, categorias, fotos do flickr, blogroll, etc. Neste caso, a equipe poderia avaliar:
Se os usuários novatos encontram esta função na interface do blog com facilidade;
Se os usuários sabem quais os passos necessários para editar um widget
Se o usuário compreende os termos desta função (se associa o termo ao que ele procura)
Quais as possíveis rupturas de interação podem ocorrer nesta tarefa, etc. Neste exemplo, uma falha comum, seria se a tarefa fosse especificada assim:
"Insira e salve o widget do Flickr nas configurações do seu blog" O que há de errado com esta tarefa? Consigo pensar em, pelo menos, três erros comuns, neste exemplo: 1. Falta de um cenário. Toda tarefa deve vir junto com um contexto de uso. O cenário auxilia o usuário se sentir "parte" do teste. Uma tarefa sem cenário é algo mecânico e por isso longe da realidade do usuário, o que prejudica os resultados dos testes. Uma pessoa ao interagir com produto/sistema, está em um contexto e possui objetivos na cabeça, deseja alcançar algo. Neste caso, um cenário seria algo como: "Você gostaria de mostrar suas fotos do Flickr no seu blog, como você faria isso?" 2. Neste exemplo a tarefa tem um nível muito operacional, muito técnico. Com uma tarefa, como esta, há uma limitação de COMO (ou qual a estratégia) o usuário utilizará para resolver o problema. Essa tarefa já indica para ele que ele deve "inserir" ou procurar pelo termo "widget" na interface, mas o modelo mental dele pode ser outro. Essa tarefa subentende que o usuário já tenha o modelo mental de "inserção" na cabeça. Ele pode pensar em "Conexão" ou "link" ou qualquer outro modelo. Perde-se a oportunidade de observar o que o usuário realmente espera ou pensa da interface, podendo tendenciar o teste. Segundo a Teoria da ação de Norman, de base cognitiva, uma ação humana passa pelo menos pelos estágios mostrados na figura acima: 1. formulação da intenção (que normalmente é um problema cotidiano, como "gostaria de mostrar as fotos do meu Flickr no meu blog); 2. especificação da sequência de ações (são os passos que o usuário formula para resolver o problema, é o "como" ele pretende resolver a questão. No exemplo, ele poderia pensar em "procurar link do Flickr nas opções do blog" "fazer meu login do Flickr" e "linkar minhas fotos", etc); 3. Execução (são os passos reais executados pelo usuário); 4. Percepção (feedback do sistema às ações executadas); 5. Interpretação e 6. Avaliação (O usuário verifica e compara se o que ele esperava realmente aconteceu, se deu algo errado, ele muda de estratégia). Entendendo esse modelo, fica mais claro observar que a tarefa "Insira e salve o widget do Flickr nas configurações do seu blog" pertence ao nível 2, da teoria da ação, ou seja, ela está no nível de especificação da sequência de ação. O ideal, em testes de usabilidade é que o avaliador recrie para o usuário o nível 1, ou seja, a formulação de um problema ou de uma intenção. No caso do nosso exemplo a intenção poderia ser algo como "gostaria de mostrar minhas fotos do Flickr, no meu blog". Esta é a intenção, é a necessidade do usuário, é algo que poderia passar na cabeça dele. Aí sim, no teste o avaliador observará como o usuário se comporta em suas estratégias de ação, quais são os passos realizados, sua interpretação e avaliação das ações realizadas. Foi bem sucedida? O que deu errado? E, mais importante: porque e onde ocorre a ruptura de interação? 3. Por fim, o terceiro erro, na tarefa do exemplo, é a mais comum e também mais simples de evitar. Não use termos técnicos como "widgets" "configuração" "Insira" etc. A tarefa deve ser independente dos termos usados na interface, não deixe que os elementos de interface tendencie a especificação da tarefa. Acredito que observando esses detalhes, a equipe extrai informações mais valiosas, extrai o uso mais próximo do real, evita resultados tendenciados, que podem pôr água abaixo, não só dinheiro investido, mas também tempo e esforço da equipe. E você, já vivenciou problemas ou dúvidas parecidas? Comentários e sugestões são sempre bem vindos... OBS.: Nos próximos posts falarei de outras falhas comuns nos testes, como o fato de muitas pessoas ignorarem o fato dos usuários serem novatos ou experientes e explicar como isso pode influenciar nos resultados dos problemas encontrados.