Primeira sessão de testes com usuários

Ontem (10.05.2014), realizei a primeira sessão da primeira rodada de testes de usuários. Como uma forma de conseguir fazer o teste com muitas pessoas sem gastar muito tempo – o que acabaria acontecendo se eu tivesse de ir ao encontro de cada uma delas -, convidei amig@s para virem aqui pra casa, explicando que precisava conduzir testes de usabilidade com o fazDelivery e pedindo que alguns(umas) se disponibilizassem a participar. Nesse formato, consegui que 6 pessoas participassem dessa primeira parte, que além de contar para os testes, também serviu de treino, já que, por serem amigos, eles aceitariam melhor se eu estivesse nervosa.

ambiente de testes: parecido com o caso de uso normal? :P

ambiente de testes: parecido com o caso de uso normal? =P

Os testes foram feitos em meu quarto para evitar que as pessoas fossem interrompidas enquanto interagiam com a ferramenta. Se por um lado este é um ambiente pouco formal para um teste, considero que se aproxima bastante do que seria um cenário normal de uso do sistema, pessoas em casa, ou em uma festa, tentando encontrar algo para comer ou beber, então creio que funcione bem, há um elemento etnográfico em meus testes. =P

Para inserir algum elemento de variedade/ escolha e deixar um pouco mais lúdico o processo, das 5 tarefas de busca que pedi que cada pessoa realizasse, uma delas foi uma busca livre – isso poderia estimulá-las a testar diferentes buscas, por exemplo, por estarem mais motivadas, e acrescentaria o elemento de buscas estranhas – que não foram previstas pelas tarefas pré-definidas.

Eis o roteiro que segui nas sessões:

    1. Pequena introdução, explicando que o sistema estava sendo avaliado, não a pessoa, e que qualquer erro ou problema era culpa do site, ou má condução minha. Explicação da técnica pensar alto (think aloud) e do critério de encerramento de uma tarefa (qual seja, quando a pessoa tivesse encontrado um resultado satisfatório, ou quando seu limiar de frustração, no caso de não estar encontrando, fosse alcançado);
    2. Leitura e concordância com Termo de Consentimento;
    3. Preenchimento do Questionário de Entradada (dados demográficos, basicamente);
    4. Sortear ordem da tarefa aberta (esta podia ser a 1ª, 2ª ou 3ª a ser realizada);
Thinking aloud, observing, taking notes...

Thinking aloud, observing, taking notes…

  1. Pegar 2 tarefas do tipo encontrar produto;
  2. Pegar 2 tarefas do tipo encontrar estabelecimento;
  3. Pegar 1 endereço;
  4. Teste:
    1. Entrar no fazDelivery e realizar 3 tarefas, utilizando o endereço sorteado;
    2. Mudar o endereço para um a sua escolha;
    3. Realizar duas tarefas restantes.
  5. Responder ao quesitonário de saída.

Durante o teste, deixei os usuários realizarem as tarefas sem interferências, exceto quando ficavam muito calados ou perguntavam algo. O tempo total de cada teste foi medido (desde o passo 1 ao 9), e o tempo para realização de cada tarefa, cronometrado.

Era meu intuito inicial perguntar o grau de satisfação com cada resultado encontrado, ao fim de cada tarefa e tentar inferir se as pessoas saberiam encontrar o horário de funcionamento e o preço de cada produto ou serviço, mas esse passo não funcionou, realmente.

Acho que no geral não foi ruim, mas preciso ficar mais atenta à mensuração do tempo, que é um pouco complicada anotando e cuidando do cronômetro sozinha. O sistema também caiu umas três vezes, me levando a ter de pausar o teste. Preciso lembrar, para os próximos, de sempre checar se ele está rodando antes de começar a avaliação com uma nova pessoa.

Testes de usuário muito amigáveis. ^^

Testes de usuário muito amigáveis. ^^

A partir dos resultados extraídos dessa 1ª rodada de Testes com Usuários e das Avaliações Heurísticas, irei propor correções e melhorias na interface, e submeter as interface modificada a uma nova rodada de testes com usuários. Os resultados de ambos os testes serão comparados e utilizados para escrever minhas conclusões acerca do processo e da metodologia utilizados, além de que interface de fato foi mais amigável para os usuários. Só espero que estes testes de fato ajudem nisso, senão terei de refazer toda essa etapa.

Bom, foi isso! Segunda, terça e quarta ainda realizarei mais 5 testes, com um grupo de pessoas em meu trabalho, e só então a 1ª rodada de Testes de Usabilidade estará concluída. Nas fotos, uma espiada na condução do teste com Jéssica, minha colega de curso.

p.s.: os créditos das fotos vão para Bruno. (=

Advertisements

Redução de Escopo, Priorização, Correção, ou Priorização, Correção, Redução de Escopo?

Não é um jogo de palavras, tampouco um trava línguas. Ao menos, não só. Mas tenho de pensar rápido, para que não se torne outro trava-tcc. Qual a questão? Eu decidi que irei realizar as melhorias em apenas uma tela do sistema, que seria escolhida a partir do levantamento da quantidade de problemas por interfaces (tendo como base os resultados das avaliações heurísticas).

Certo. Acabo de fazer esse levantamento. Confirmando minha intuição inicial (no anteprojeto, o escopo do trabalho era esse), a Página de Resultados concentra o maior número de problemas. Somando todos os problemas encontrados e dividindo a quantidade de problemas encontrados em cada tela pelo total (esse racional faz sentido? parece-me que sim), a Página de Resultados (~44% dos erros encontrados) tem quase 15% mais problemas do que o Portfólio (~29% dos erros), segunda interface com mais problemas. Está decidido que focarei nela para a correção dos erros.

Mas, o que faço com as outras interfaces? Não posso abandoná-las de todo, ou corro o risco de continuar com problemas que impeçam os usuários de seguir o fluxo dos testes. Parece-me que o razoável aqui será observar erros que fazem o sistema quebrar (por exemplo, erro na busca de endereço), até que chegue à página de resultados, ou seja, erros graves na Página Inicial (~15% dos erros). Ok, creio que consigo me sentir tranquila com esse caminho…

Falta fazer amanhã (lol, o dia tem 36 horas? 56? Acho que vou precisar):

  • definir erros a corrigir;
  • corrigi-los;
  • formular e construir questionário de entrada;
  • formular e construir questionário de saída dos testes de usuário;
  • formular roteiro do teste;
  • testar roteiro;
  • verificar se precisarei instalar alguma ferramenta na máquina;
  • decidir se usarei Windows ou Linux.

Amanhã é um grande dia. Sábado também. Talvez todos, acho, daqui até o fim dessa jornada…

Eureka – Escopo, escopo, escopo! – Reduzir para conquistar

Então eu continuo travada, como os últimos episódios da novela já contaram, na compilação dos problemas da avaliação heurística. Eu já havia pensado que precisava, além de priorizar os problemas, filtrá-los, para saber o que faz parte do escopo do projeto ou não. Quando comecei a fazer essa atividade, me dei conta de que, logo no início, eu havia me planejado para trabalhar apenas com a tela de listagem de resultados – que é conhecida como SERP – Search Engine Results Page, porque tinha uma sensação de que era o ponto do sistema que mais concentrava problemas.

Em algum ponto no meio do projeto isso saiu de meu foco, creio que porque decidi que valia a pena considerar o sistema como um todo, para posteriormente, a partir dos resultados das avaliações, decidir o ponto mais interessante a atacar. E, agora, na medida em que percorria a longa lista de problemas, me parece o momento ideal para voltar a essa ideia. Então, vou aproveitar que destaquei os pontos do sistema que apresentavam cada problema para avaliar qual tela está mais crítica e elegê-la para meu estudo de caso.

Além disso, enquanto escrevia também me lembrei que o principal da avaliação heurística ser feita antes dos testes de usabilidade é evitar que os usuários se deparem com muitos erros, que poderiam atrapalhar o andamento e o propósito original dos testes. Então, posso nessa etapa focar em corrigir os erros que atrapalham o fluxo de uso e, posteriormente, quando for atacar a interface a partir dos feedbacks da primeira rodada de testes, atacar coisas mais sutis como organização de informações, espaçamento etc. Isso também me permite ganhar tempo para que as pessoas façam a classificação dos problemas, já que não preciso ter essa informação, necessariamente, para corrigir os erros mais graves, mas ainda poderei usufruir dos benefícios da classificação na fase de realmente propor melhorias para a interface. Além disso, definindo apenas uma tela, a listagem de problemas também se reduz… *-*

Que. Bom. Ter. Pensado. Nisso. /respira aliviada. Acho que finalmente vou desempacar. /o/

Acho que até consigo dormir, agora.

Compilação dos Problemas de Heurísticas: a volta dos que não foram

Como ainda estou brigando com a maldita etapa das Avaliações Heurísticas, acho interessante compartilhar um aprendizado breve para quem está planejando realizá-las.

O que torna especialmente interessante trabalhar com especialistas nessa forma de inspeção, ou no mínimo pessoas que tenham as heurísticas mais claras na cabeça, é que elas conseguirão se ater com mais facilidade ao escopo da avaliação e apontarão problemas de violação de heurísticas, de fato. Isso torna a posterior compilação muito mais simples – do que está sendo pra mim neste momento, em oposição, já que eu não tenho prática ainda com as heurísticas e, desse modo, não percebo rapidamente onde cada problema se encaixa ou, por vezes, se uma coisa observada é uma violação de heurística ou uma funcionalidade interessante de constar…

EDIT: ou talvez eu só tenha estimado terrivelmente mal o esforço envolvido nessa tarefa…

Avaliação dos concorrentes

Há um tempo atrás estava em dúvida em relação a qual a melhor abordagem para avaliar os concorrentes. Na época já me parecia que as avaliações heurísticas não seriam o caminho.

Ainda assim, até hoje essa tarefa está lá no cronograma. Hoje, como a revi, pensei mais uma vez no assunto. E realmente, para o que quero, não faz sentido comparar e avaliar os concorrentes a partir dessa abordagem. Eu quero saber o que os concorrentes provêm em termos de funcionalidades e facilidades para os usuários, não quem tem mais problemas… Logo, avaliação heurística para concorrentes is no more.

Será que alguém precisa rever e atualizar alguns pontos de sua metodologia? >.<‘

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.