Andamento, observações, redefinição de escopo…

Acabo de enviar uma versão parcial (semi-final) para os orientadores. Agora ficam faltando dois ou três capítulos, sendo que a prototipação das melhorias está nesse meio >.<‘

Algumas questões que ainda persistem, pra mim:

  • Devo apresentar todos os resultados dos testes? Sim, apresentei tanta coisa… O.o’ Precisarei compilar individualmente cada um e acrescentar nos apêndices, de algum modo;
  • Está fazendo falta ter uma listagem de todas as heurísticas violadas. Creio que eu mesma imporei como uma obrigação ter isso para a versão final;
  • Em relação aos testes com usuários, além das tarefas e tempos, tenho de acrescentar no tcc uma listagem dos problemas e dificuldades encontrados. Na verdade, no meu caso, isso é o mais importante, dos testes.

Após as dificuldades que tive hoje para sintetizar e descrever os resultados dos testes de usuários, estou pensando em reduzir o escopo do projeto, evitando implementar de fato a interface e, por conseguinte, a nova rodada de testes de usuários que eu precisaria fazer. EJ perguntou qual seria minha abordagem em relação a isso sábado passado e comentei que iria implementar, mas agora prefiro evitar, e visto que ele levantou a possibilidade, estou esperançosa com a resposta…

Eu acho que tinha mais alguma coisa pra dizer, mas esqueci. Ah, o título provisório está assim, agora: Inspeção e Evolução da Usabilidade de Buscadores Tipo Catálogo: Estudo de Caso com o fazDelivery.

Advertisements

Testes com Usuários – O que é importante sintetizar? D:

Ok, eu tenho uma cacetada de informação relacionada aos testes com usuários. E agora, eu uso o quê, o como? Calculei um bocado de médias, defini metas, fiz teste eu mesma, para servir de benchmarking. Mas agora é hora de descrever os testes, apresentar tais dados, extrair algo de valor deles. comofas/ >.<‘

Já descrevi a parte aberta, subjetiva dos testes. Ainda não caracterizei o perfil dos usuários, por outro lado, nem… consigo usar os números de um jeito que faça sentido. Vamos tentar aqui, primeiro. Menos pressão. Por exemplo, eu defini duas metas:

  • consultas não demorarem mais de 3 minutos;
  • 80% das consultas serem concluídas com sucesso (a definição de sucesso era conseguir encontrar um telefone para um estabelecimento que tivesse o produto pesquisado).

A partir dos dados coletados, é possível observar que aproximadamente 90% das consultas foi concluída em menos de 3 minutos (a média foi 1:29 minutos). Entretanto, isso não impediu que apenas 66% das tarefas fosse considerado concluído com sucesso, e em verdade as médias de duração de tarefas concluídas com sucesso ou abortadas porque o usuário chegou a seu limiar de frustração (1:31 minutos) teve uma diferença de 2 segundos, apenas. Isso pode sugerir duas coisas:

  1. o tempo de duração da consulta não é tão relevante para as pessoas, conquanto que elas não se sintam frustradas com o sistema;
  2. ou, seguindo uma linha oposta, que as pessoas têm uma expectativa de encontrar as coisas muito rápido, o que faria com que 2 segundos fosse um tempo significativo, aqui.

A segunda hipótese, entretanto, não é confirmada pelos dados, pois apenas uma das tarefas concluída sem sucesso de fato ultrapassou os três minutos. A partir disso fico inclinada a pensar que a primeira hipótese é a que faz mais sentido, e que, conquanto o sistema não pareça ser incapaz de atender às demandas dos usuários, o tempo de duração de uma consulta (pelo menos no intervalo de tempos destes testes, em que a consulta mais longa levou 4:10 para ser concluída – com sucesso, por sinal) não é tão relevante para a satisfação do usuário com a ferramenta.

Outro aspecto que observei a partir dos testes foi que algumas pessoas consideraram uma tarefa concluída, mesmo tendo encontrado um estabelecimento diferente do solicitado.

Como tais observações são úteis para o projeto?

  1. tenho mais maturidade para pensar as próximas metas;
  2. fica claro que devo observar, das sessões de testes, os aspectos que mais levaram a frustração, para tentar minimizá-los;
  3. a listagem de resultados não é exatamente eficiente para apresentar informações sobre os estabelecimentos (as marcas são pequenas, o nome tem pouco destaque).

Hm. Ok. Isso me ajuda a me sentir um pouco melhor. Essa é uma história que sinto que consigo contar, que faz sentido dentro de meu processo. Agora vou pedalar, pra ajeitar o juízo e as ideias, e volto pra terminar essa descrição da 1ª rodada de testes com usuários.

EDIT 1: ontem à noite, em algum momento, quando reli isso, não gostei muito do racional. Me pareceu precipitado e errôneo. Talvez não tanto por ele em si, mas porque analisei os dados em mais detalhes e vi que quando baixei a linha de corte para 1:29, que foi a média, o racional parou de fazer sentido at all. Acho que só por “diversão” vou calcular a mediana das durações, depois.

EDIT 2: ok, calculei a mediana de todas as tarefas de consulta: 78.5. A média é 89. O que eu deveria conseguir apreender, disso?

Menos de um mês >.<'

Dá pra saber quando eu estou perdida ou distante do TCC (e a essa altura do campeonato as duas coisas se tornam bem parecidas, porque se eu me distancio do TCC eu estou perdida) pela ausência de posts neste blog. =x

Então, depois de terminar os testes de usabilidade, tive um dos famosos momentos de mudança de contexto, que sempre me deixam desnorteada – não importa que eu tenha a %#$#@% do cronograma no Trello e saiba o que tenha de fazer, ainda não consigo evitar que isso ocorra. Enfim, isso me fez perder uns dias rendendo menos, mas “hoje” (ontem) convidei as pessoas pra segunda rodada de testes de usabilidade; fiz eu mesma o teste, para ter uma noção de tempo para servir de benchmark; e calculei as médias de tempo das tarefas realizadas. Quer dizer, calculei uma das médias. Acredito que como havia diferentes tarefas possíveis, o ideal seria eu também calcular a média de cada tarefa específica. Vou pensar sobre a relevância disso para o todo.

Bom, o que falta agora, grosso modo?

  • Sumarizar os erros e problemas encontrados (tanto da avaliação heurística – yeah, eu sei -; quanto dos testes de usabilidade)
  • Priorizar
  • Corrigir
  • Prototipar
  • Implementar
  • Escrever
  • Testar
  • Comparar
  • Concluir
  • Escrever
  • Preparar apresentação
  • Apresentar ( >___<‘ )

Let’s go for it.

Three, two, one. Let’s jam. Conclusão da primeira rodada de testes com usuários

Ok, considero a primeira rodada de testes de usuários concluída. Foram 6 pessoas entre os amigos da casa e mais 4 com amigos e colegas de trabalho. Seriam 5 lá, mas uma das pessoas não pôde ir hoje e eu realmente preciso ir concluindo tarefas, pois…

A data da banca está marcada. Tudo dando certo, e a UNEB funcionando durante a Copa, será dia 14/06, às 08:00.

Alguns dados sobre os testes realizados:

  • Em médida, as sessões duraram 19 minutos, contando tempos de aceitar o Termo de Consentimento, preencher o Questionário de Entrada, receber instruções, realizar teste e responder Questionário de encerramento.
  • Foram utilizadas as técnicas de observação e think aloud, para acompanhar como o usuário estava interagindo com o sistema. Busquei ser amigável, mas não fiz comentários ou dei explicações, exceto quando solicitada, ou no caso de o usuário estar preso porque o sistema estava em um erro e não oferecia qualquer feedback a respeito. Mas mesmo nesses casos, não o fiz antes de os usuários terem passado um certo tempo tentando lidar com a situação por eles mesmos;
  • Cada teste foi composto de 5 tarefas de busca e uma tarefa para mudança de endereço. Tentei fazer um formato que simulasse três cenários de busca:
    1. A pessoa sabe onde quer pedir (busca por estabelecimento – específico ou genérico);
    2. A pessoa sabe o quê quer pedir (busca por produto);
    3. A pessoa encontrou o sistema e está explorando (tarefa aberta).
  • Foram duas tarefas do tipo 1, duas do tipo 2 e uma do tipo três, esta última com ordem semi-aleatória (podia ser a 1ª, a 2ª ou a 3ª tarefa a ser realizada). Na maior parte dos casos, tarefas, endereço pré-definido e ordem da tarefa aberta foram sorteados pela pessoa, na hora do teste. Este sorteio sofreu interferências em algumas ocasiões para equilibrar a ocorrência das opções – não dei muitas, porque fiquei com medo de não saber analisar as combinações, depois, caso isso tivesse alguma implicação para os resultados.
  • As pessoas realizaram algumas tarefas com um endereço pré-definido, para garantir casos de sucesso de busca, e tiveram a liberdade de escolher tanto consulta a ser realizada quando endereço de entrega, para deixá-las mais livres, e oferecer mais espaço para experiência de frustração.
  • Havia dois critérios para conclusão de uma tarefa, considerados similares ao que ocorre em buscas reais:
    • encontrar um resultado satisfatório para a necessidade de busca existente;
    • atingir o limiar de frustração, para a dada busca, após tentar por um tempo sem sucesso.
  • As tarefas intencionalmente não induziram os usuários a interagir com filtros ou portfólio. Primeiro, porque o foco do projeto, como já comentei, será a página de listagem de resultados, então as outras telas, apesar de importantes, são mais complemento. Segundo, porque eu queria ver o quanto os elementos existentes ressaíam naturalmente, ao longo do processo, já que durante um caso de uso real isso seria o mais provável de acontecer. Por exemplo, quase ninguém comentou sobre as estrelas de avaliação e poucas pessoas navegaram espontaneamente pelas categorias, ainda que uma das tarefas tivesse um viés para este tipo de busca. E terceiro, talvez porque as Avaliações Heurísticas já haviam detectado uma série de problemas em vários elementos, que eu acabei não conseguindo corrigir antes dessa primeira etapa de testes de usuário, então eu preferi não levar os usuários a lidar com problemas já conhecidos, a menos que eles mesmos chegassem até eles.
  • Os testes não avaliaram o aspecto de facilidade de memorização. Entretanto, na segunda rodada de testes convidarei 5 pessoas desta primeira rodada, e espero que isso ajude nesse ponto. Talvez eu possa fazer alguma pergunta relacionada a isso no próximo questionário de entrada.

Sobre o papel de observadora: foi meio agoniante ver os problemas acontecendo e não poder ajudar as pessoas, mas eu precisava de tais situações para que os problemas do sistema de fato emergissem e os testes fossem mais parecidos com um uso real.

Bom, creio que seja isso. Agora preciso corrigir coisas e propôr soluções. E escrever um pouco na monografia em si! Espero que dê pra aproveitar bastante coisa daqui…

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. (=

Preparativos para a 1ª rodada de testes de usabilidade

Após o choque inicial de não ter reservado tempo suficiente para os testes de usabilidade, e estar com tarefas atrasadas, consegui me recuperar, reorganizar o cronograma e fazer uma lista com cerca de 20 pessoas que acredito que podem dispor de uma hora para participar dos testes de usabilidade.

Foquei principalmente em amigos e colegas de trabalho, e busquei situações em que pudesse tê-los todos juntos, para evitar gastar muito tempo entre cada teste. Estou planejando fazer 10 testes em cada rodada, mantendo, entre a primeira e a segunda, 5 pessoas, para ter uma noção de como quem usou antes das melhorias sente a segunda versão.

O ideal para testes de usabilidade é definir um perfil de usuário. Eu levantei as informações que tinha, das pesquisa de mercado que fizemos para o fazDelivery, a respeito disso. Idealmente seriam pessoas entre 25 e 44 anos, que morem sozinhas ou com companheir@, mas não tenham filhos. Entretanto, como alguns autores consideram que o conjunto e variedade das tarefas escolhidas são mais importantes do que a quantidade/ perfil de usuários, e os recursos desse projeto são limitados, o perfil original, pensado para equivaler ao público early adopter do fazDelivery, não está sendo seguido à risca.

Testes de usabilidade

Eu havia, por alguma razão, separado apenas um dia para cada rodada de testes de usabilidade. Parando pra planejar o roteiro dessas atividades, especialmente depois das avaliações heurísticas, ficou muito claro pra mim que isso não iria funcionar, porque eu preciso estar completamente dedicada a cada pessoa, uma por vez, e não necessariamente conseguirei reunir todas elas em um só lugar etc. E eu preciso testar o fazDelivery com pelo menos 5 pessoas de cada perfil que eu definir, idealmente. E o mínimo de perfis que consigo pensar são dois: que já usaram o fazDelivery e que nunca usaram. Então, 10 testes, com 10 pessoas, em cada rodada.

Gastei, então, um tempo ontem revendo o cronograma para encaixar essa mudança. Também pensando quem seriam as pessoas. E vendo o esboço/conteúdo do roteiro dos testes. Amanhoje vou dividir melhor quem acredito que pode/deve ficar em cada grupo e sessão, e dispararei os convites.

Espero que tudo corra bem. Estou com um atraso de uma semana e isso está me assustando um pouco.

E agora? – Próximos passos no caminho do tcc

  • Quinta (12/12/13) faço apresentação oral de tcc I, última entrega da disciplina;
  • Na sexta, dei entrada no pedido de prorrogação de prazo (pra terminar no semestre que vem);
  • Vou estruturar a parte prática do projeto neste fim de dezembro e uma ou duas semanas de janeiro, e de preferência começar os testes de usabilidade (dependerá de conseguir pessoas);
  • Na verdade, eu gostaria de primeiro fazer uma avaliação heurística, então vou procurar duas ou três pessoas que se disponham a avaliar a interface do fazDelivery e, depois de sua avaliação, buscar trabalhar em alguma melhoria, como Nielsen sugere, antes de realizar os testes de usabilidade.

Por falar em Nielsen, este artigo do Nielsen Norman Group parece bastante útil neste momento: How to Run a Usability Test with Users Who Are on Your Site Now

Para a prototipação que talvez precise fazer, sugeriram o Axure RP numa lista de profissionais de computação que eu acompanho. A ferramenta é para PC ou Mac, e é paga (mas tem trial), mas achei bacana que eles dizem que dão licença free para bons estudantes da área. Não me candidatei porque precisa ter boa nota no semestre anterior e, bem, isso, especificamente, eu sei que não tenho. =/

Em tempo: semana passada, pós entrega, descansei um pouquinho, estruturei a carta e documentos que seriam anexados ao processo, voltei à rotina de exercícios (como isso é bom e faz bem!). Sexta, como disse, entreguei. Sábado foi meu aniversário (yays para mim), e hoje estou retomando as atividades.

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?