Avaliações heurísticas – andamento e aprendizados

Quase no fim das sessões de avaliação heurística (esta semana foi reservada pra isso). O processo é legal, e teve dois pontos interessantes:

  1. Pessoas de áreas distintas. Convidei, além de pessoas com formação em Sistemas de Informação, dois Designers. Além do fato geral de que pessoas diferentes trazem olhares diferentes, obtive feedbacks mais específicos de estética que achei bacanas;
  2. Para me adequar à realidade dos avaliadores e não gastar muito tempo deles ou meu, a maioria das sessões foram remotas (apenas uma foi presencial, até o momento). Dessas, muitas foram acompanhadas sincronamente via alguma ferramenta de video conferência / chat por voz, e uma foi feita sem acompanhamento. Uma foi realizada presencialmente. Isso me permitiu ter uma ligeira noção de vantagens e desvantagens de cada abordagem. Da experiência, creio que optaria por sessões remotas com think aloud e conversa por voz. Dão mais espaço para o avaliador (e talvez usuário, até) se sentir mais à vontade, mas contam com a vantagem de acompanhar o processo que os leva a cada conclusão, o que permite entender melhor os pontos que levantam.

Acabei optando por seguir um modelo em que os avaliadores indicam os problemas, e eu posteriormente os categorizo, dentro das heurísticas. No processo de categorização, estou sentindo falta de acrescentar duas:

  • onboarding: sistemas devem ter baixa curva de aprendizado e interface intuitiva, especialmente se forem ferramentas com funcionalidades de algum modo inovadoras / incomuns;
  • estética: interface deve ser agradável e não cansativa ao usuário (por exemplo, não usar muitas fontes, ter contrastes corretos). Isso me parece diferente da heurística de design e estética minimalistas. Preciso pesquisar e/ou falar com os orientadores a respeito, para decidir o que fazer.

O roteiro evoluiu na medida em que as avaliações ocorreram, principalmente as primeiras. A moda de duração das sessões foi cerca de uma hora. E, de minha observação, os avaliadores tendem a notar mais problemas quando fazem a inspeção conversando com o observador.

Amanhã e sábado talvez acontecem as sessões de avaliação com os orientadores. Espero conseguir fazer ao menos com um deles, para mim enriqueceria bastante o trabalho. Depois das sessões concluídas, farei uma única lista com todos os problemas levantados, para que todos os avaliadores possam lê-la e avaliar o grau de severidade de cada problema, utilizando a escala com 5 níveis de severidade. Estou pensando em usar o google forms pra essa etapa, tenho de testar a legibilidade do resumo de respostas.

EDIT: esqueci de comentar, mas o processo das avaliações me fez pensar que preciso repensar o agendamento pros testes de usuário. Aspectos de tempo, de como farei pra encontrá-los etc. precisam ser melhor pensados.

Advertisements

Planejando e construindo as instruções para a avaliação heurística

Ok, consegui criar as instruções (já foram, também, devidamente revisadas e enviadas).

Elas são um misto de roteiro que explica o que vai acontecer e como os avaliadores devem proceder, com uma síntese dos conceitos abordados na sessão (o que e quais são as heurísticas, como classificá-las), para que as pessoas se sintam confortáveis com a tarefa que está por vir.

Consegui confirmação de 8 pessoas para participarem dessa etapa de inspeção, incluindo os dois orientadores. Comigo, serão 9 pessoas realizando a avaliação, sendo 2 delas designers formados (Yays para isso, quero ver se – e como – esse aspecto vai influenciar na percepção dos problemas de usabilidade). Meus próximos passos são:

  • acompanhar as sessões de avaliação
  • compilar os problemas identificados, repassar para que as pessoas classifiquem
  • revisar as classificações e gerar grau de severidade médio para cada problema

Ah, um post com exemplos de boas práticas para cada uma das dez heurísticas: 6 tips for a great flex design – review usability best practices. Bom para ajudar a visualizar as coisas. E explicando de um jeito legal cada heurística.

Abaixo, alguns destaques de artigos de Nielsen em que me baseei para construir as instruções. Relendo-os, lembrei que esqueci da possibilidade de criar um cenário de uso. Acho que vou aproveitar que tenho um tempo até a data das sessões e pensar em um, para repassar pras pessoas, mais a guiza de contextuação.

In principle, the evaluators decide on their own how they want to proceed with evaluating the interface. A general recommendation would be that they go through the interface at least twice, however. The first pass would be intended to get a feel for the flow of the interaction and the general scope of the system. The second pass then allows the evaluator to focus on specific interface elements while knowing how they fit into the larger whole.

(…)

One approach that has been applied successfully is to supply the evaluators with a typical usage scenario, listing the various steps a user would take to perform a sample set of realistic tasks. Such a scenario should be constructed on the basis of a task analysis of the actual users and their work in order to be as representative as possible of the eventual use of the system. The output from using the heuristic evaluation method is a list of usability problems in the interface with references to those usability principles that were violated by the design in each case in the opinion of the evaluator. It is not sufficient for evaluators to simply say that they do not like something; they should explain why they do not like it with reference to the heuristics or to other usability results. The evaluators should try to be as specific as possible and should list each usability problem separately. For example, if there are three things wrong with a certain dialogue element, all three should be listed with reference to the various usability principles that explain why each particular aspect of the interface element is a usability problem. There are two main reasons to note each problem separately: First, there is a risk of repeating some problematic aspect of a dialogue element, even if it were to be completely replaced with a new design, unless one is aware of all its problems. Second, it may not be possible to fix all usability problems in an interface element or to replace it with a new design, but it could still be possible to fix some of the problems if they are all known.

Referências deste post:

Nielsen, Jakob. Ten Heuristics for User Interface Design.

____________. Severity Ratings for Usability Problems

____________. How to conduct a heuristic evaluation

Finding examples

Li a monografia de Claybony Souza Moraes, que se formou em Análise de Sistemas pela UNEB, com um trabalho também em IHC: Um estudo de usabilidade para software de prescrição de treinamento neuromuscular (Digital Trainer), 2010.

Como o título sugere, ele faz uma análise e melhoria do Digital Trainer, um software feito pela Polisystem, empresa dele e do irmão (pelo que me lembro), que oferece apoio na construção e manutenção de programas de exercícios em academias (para instrutores usarem).

Ele lista os aspectos de usabilidade a serem considerados de acordo com Nielsen, com a ISO 9241 (parte 11) e com alguns outros autores, como Preece, Rogers & Sharp (2005). Detalha também, um pouco, métodos para avaliar uma interface, de acordo com três abordagens: testes, inspeção e investigação.

Médotos de teste de usabilidade:

  • thinking aloud protocol
  • perfomance measurement
  • métodos empíricos
  • co-discovery method

Uma coisa que ele fala que não entendi bem é que

Netto et. al (2004), ressaltam que testes de usabilidade avaliam somente o produto em termos meramente quantitativos, enquanto testes de comunicabilidade produzem tanto dados quantitativos como qualitativos, sugerindo a aplicação de ambos os testes complementarmente para uma única interface.

A parte que não entendo é que, de minhas leituras que citam testes de usabilidade, nenhuma me deu a entender que eram avaliações meramente quantitativas. Talvez ler o que Netto et. al dizem ajude a entender isso e ver se faz sentido para meu contexto ou não.

Métodos de inspeção:

  • avaliação heurística
  • percurso cognitivo
  • inspeção de padrões
  • revisão de guidelines

métodos de investigação:

  • investigação contextual
  • estudos etnográficos ou de campo
  • entrevistas
  • questionários
  • grupos focais

Claybony utiliza testes de usabilidade (10 usuários, sendo 5 novatos e 5 experientes, em cada rodada de testes) e avaliação heurística (três pessoas que desenvolviam o software) para analisar o Digital Trainer. Assim ele contrabalançou a opinião dos especialistas (heurísticas) com a experiência relatada pelos usuários, e operou e comparou métricas quantitativas e qualitativas, conseguindo, por exemplo, avaliar que houve redução de tempo para execução de tarefas específicas e redução de quantidades de cliques por tarefa.

Há muitos livros e artigos citados, preciso olhar novamente com calma a lista de referências. De antemão, uma das coisas que ele cita que quero ler, pra variar, é Nielsen, sobre a quantidade de usuários necessária em um teste de usabilidade: http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/.

A referência de Netto et. al é: OLIVEIRA NETTO, Alvim Antônio de. IHC – Interação Humano Computador: modelagem e gerência de interfaces com o usuário. Florianópolis: Visual Books, 2004. 120 p. (ao menos, creio que seja, porque na parte das referências só aparece esta, e nenhum Netto et al.).

Para amanhã: voltar a escrever, ou ler a monografia de Jussi? Que tal ambas as coisas?