[Prototipação] Etapa 1: executando soluções para as violações de heurísticas. Reflexões sobre processo de prototipação

/*

Primeiro, um comentário: muitas vezes me perco, no processo do TCC, porque, ao invés de ver os passos de uma determinada tarefa ou etapa e segui-los à risca, sem pensar muito, começo a inventar firulas, ou tergiversar, ou, ou… e de repente me perco, ou faço mais do que preciso e menos do que devia, ou gastei um tempo danado fazendo coisas complicadas, sem alcançar o objetivo simples. Tudo isso atrapalha um bocado, mas ainda tenho dificuldade de evitar. É um pouco como o processo de leitura, quando de repente se está procurando um monte de artigos que já não estão realmente ligados ao que devíamos fazer, porque vamos saltando daqui pra lá e depois acolá, e não nos damos conta de como estamos nos afastando do objetivo inicial…

*/

Para prototipar, estou usando:

  • experimentações no HTML e CSS da página, através da ferramenta para desenvolvedor do navegador (no Chrome, o atalho pra ela é F12);
  • retoques ou ajustes mais livres utilizando o GIMP, uma ferramenta para edição e manipulação de imagens, de código livre.

Essa abordagem é porque não quero redesenhar a interface do zero, mas sim corrigir ou melhorar aspectos específicos. Se fosse fazer do zero, poderia utilizar ferramentas para criar primeiro protótipos em wire-frame e ir evoluindo a partir daí. Uma limitação que tenho é que não sei trabalhar com front end, ou seja, não tenho domínio de HTML e CSS, de modo que não consigo simplesmente abrir o código-fonte ou algum framework e sair editando tudo daí.

O que estou observando que deveria ter feito diferente, para essa fase de correção e prototipação – o ideal, parece-me agora, é:

  • pensar no conceito que se quer seguir;
  • ter a visão geral do todo – o que é preciso corrigir e onde, todas as correções para cada tela;
  • observar elementos que se repetirão em diferentes telas;
  • utilizar uma ferramenta que permita reaproveitar elementos – com camadas e elementos agrupados, por exemplo -, acredito que não terei problemas com isso no GIMP;
  • corrigir e prototipar a partir das peças menores, componentes, que se repetem em variados pontos do sistema;
  • executar a correção completa dos erros, por telas;
  • e, assim, ir realizando um trabalho de composição.

No momento isso parece um processo mais seguro para evitar retrabalho – por exemplo, eu não segui esses passos, até aqui, e estou mexendo em telas que listam itens de produtos, mas ainda não mexi nos produtos. Se e quando vier a mexer neles, precisarei alterar as telas novamente… O mesmo vale para a barra de busca, que aparece em várias telas (espero que essa seja mais simples de encaixar)… Mais grave ainda do que isso é que executei as correções para as violações de heurísticas e depois terei de fazer mudanças para as correções de testes de usuários, passando por telas em que já trabalhei.

Ah, amanhoje é: pensar e executar soluções para os problemas levantados nos testes de usuários. Ver se consigo seguir as etapas que falei acima. Daí precisarei gerar versões finais, fechadas, de cada tela, que agreguem as soluções das avaliações heurísticas e dos testes… Sim, idealmente, tudo no domingo.

Estou com sono e não revisei esse post. Um dia o releio e descubro barbaridades de escrita. Falta menos de uma semana para entregar a versão completa da monografia para a banca. /suspiro Eu vou sobreviver…

Advertisements

[Andamento] Soluções para os Problemas Identificados

Primeiro, uma observação: a palavra que passei os últimos dias tentando lembrar (até ontem, anyways), para descrever o que sinto que faltou na condução da etapa prática do TCC é… rigor. Sinto que fui pouco rigorosa, principalmente na etapa de testes de usuários como um todo. Tinha pouca (quase nenhuma) experiência prática nesse quesito, e ainda assim planejei e conduzi tudo muito sozinha, o que também não ajudou. =/
No último capítulo, comentei que estava em dúvida entre prototipar ou implementar as soluções pensadas para os problemas. Pedi orientação sobre isso para orientadores e alguns amigos. João Rocha disse que preferia que eu implementasse e fizesse os testes com usuários; EJ sugere que eu faça apenas prototipação e comparação das duas interfaces (porque implementar em si pode trazer complicações extras, erros etc, que tirariam o foco no projeto). Entendo e consigo concordar com os dois pontos de vista. Fazer a implementação mais testes deixaria o projeto mais completo, porque teria seguido todas as etapas previstas pela metodologia que eu mesma apresentei. Mas isso reduz meu tempo de trabalho na prototipação em si, o que também tira qualidade do projeto. Então estava meio “dilemética”.
Ontem então pensei em um meio termo assim:
  • v-1.0: corrigir coisas em protótipo. Possível abordagem mista: selecionar os 10 problemas mais prioritários das avaliações heurísticas, mais os problemas dos testes de usuários. Corrigir.
  • v-1.1: Tendo tempo, implementar e testar;
  • v-2.0: sobrando tempo: corrigir em protótipo demais violações de heurísticas.

Está se encaminhando para eu conseguir fazer a v-1.0. Hoje terminei de descrever como três ferramentas correlatas abordam aspectos considerados problemáticos no fazDelivery. A tabela abaixo mostra uma parte dessa listagem (os Ids servem para identificar a que problema cada linha da tabela se refere – ok, sei que está ruim visualizá-la). Hoje, então, parto pra selecionar as soluções que de fato usarei e prototipá-las…

Excerto do levantamento de soluções correlatas.

Excerto do levantamento de soluções correlatas.

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.

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?

Andamento: vamos que vamos

Nova possibilidade de título: Inspeção e Evolução da Usabilidade de Interfaces de Buscadores Tipo Catálogo, Estudo de Caso com uma Ferramenta Georreferenciada de Busca de Deliveries acho que é bem realista ‘-‘. Mas coloquei no TeX e compilei e ficou enorme e uma droga. Pensar em outra coisa.

Fui falar pessoalmente com EJ. Ele deu pontuou algumas coisas, fez contribuições realmente interessantes – gostaria que isso tivesse acontecido antes, mas paciência. Apesar das questões levantadas e de discordar de algumas decisões, considera que dá pra apresentar o TCC dia 14. Só preciso conseguir gerar uma versão da mono para ele e João revisarem, ainda essa semana, e corrigir a interface para poder testá-la entre quinta e domingo. E fazer o resto que falta.

Antes de ir lá tinha feito uma outra versão da metodologia, junto com uma descrição mais detalhada e atualizada, e mudei a figura. Após a conversa surigiram mais mudanças a serem feitas. Estou trabalhando nelas agora. Uma dúvida que me surgiu, é: com que granularidade devo (ou deveria) apresentar as coisas, na figura da metodologia?

Estou lutando com meu eu crítico me dizendo que o TCC está muito simples/ pobre… Se eu fosse postergar sua entrega, corrigiria os problemas que puxei para serem classificados na avaliação heurística, daí seguiria o processo primeiramente definido, aproveitando para filmar os testes, que foi algo que EJ pediu. E tentaria fazer mais apropriadamente o processo de prototipação e implementação. Vamos ver o que vai dar pra fazer, com o que tenho.

Ocorreu-me agora há pouco que posso justificar a escolha de problemas escolhidos nas avaliações heurísticas como um recorte da lista completa, para tornar o projeto mais factível dentro de suas limitações. O recorte escolhido, no caso, foi relacionado a aspectos que poderiam levar a erros no fluxo dos usuários, porque a ferramenta entrou em estágio de manutenção (i.e., saiu de evolução e desenvolvimento) ainda com muitas coisas a serem corrigidas.

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

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…

Pie detrás de pie…

Como é difícil seguir caminhando e fazer o que precisa ser feito, independentemente de ser divertido ou não, no matter what. Quando estou brigando comigo mesma por razões idiotas como ter dificuldade de seguir fazendo uma tarefa em relação à qual estou particularmente resistente, às vezes me lembro dos caras do acidente nos Andes, quando saem para buscar ajuda (pois era isso, ou a morte). Eles não tinham comida, nem muito senso de direção, nem energia, direito, tava frio pra caralho. Era força de vontade, e continuar ou continuar, um-passo-após-o-outro, seguindo o ritmo, ou acabariam parando no meio da neve, e então seria o fim – para eles, para os que haviam ficado.

Há tantas situações realmente tensas e limítrofes, que exigem tudo de nossos corpos e nervos. E eu estou aqui, sentada em um sofá, com mais de uma semana de atraso, porque não consigo concluir uma tarefa que, se eu simplesmente continuar fazendo, gostando ou não, uma hora irá acabar. Um passo após o outro, Juliana… Aproveitando que ainda há um certo tempo, que não é preciso fazer as coisas na correria e terrivelmente sobre pressão. >.< Preciso de disciplina, foco, maturidade e mais disciplina…