Sobre a necessidade de testes de usuário

E o rigor de sua execução.

Encontrei esse artigo sobre isso: http://www.lits.dei.uminho.pt/tu.pdf

Quero ler, acho que é interessante também pelas dificuldades que tive com essa etapa.

Dias mais de descanso…

Advertisements

Prototipando SERP e Document Surrogate

Passei os últimos… Dois dias? Talvez isso, talvez três, me sentindo meio empacada na Página de Resultados. Me sentia andando em círculos, ou desfocada, ou perdida, ou tudo junto. Cheguei a rascunhar:

Acho que… mexer no html direto às vezes faz perder o tempo e me desfoca. É possível que isso seja porque desvio de planejamentos, e fico apenas experimentando, sem metas claras. Os objetivos precisam ser claros, do contrário dá pra passar muito tempo mexendo semi aleatoriamente em interfaces e elementos =x

Ontem ficou evidente que eu precisava mudar alguma coisa na abordagem, pois o tempo está se esgotando e preciso ter alguma versão da Página de Resultados. Uma versão meia-boca me ajuda, pois posso prosseguir com as outras atividades e terminar o TCC em tempo. Nenhuma versão me leva a lugar algum e coloca em risco meu cronograma, de modo perigoso. Então decidi tentar escrever não apenas as correções que queria fazer, mas o meu objetivo pra página, ou tudo o que queria fazer nela, e em que ordem fazer, e quando usaria que ferramenta – para evitar, como comentei acima, ficar vagando pelo HTML.

Isso de algum modo ajudou. Ainda gastei um tempo danado, e me enrosquei um bocado até conseguir perceber que estava avançando. Mas, no processo, me dei conta de outra coisa que também deveria estar influenciando minha dificuldade com essa etapa e essa página – de algum modo, acho que sinto que essa é a culminância da parte prática do projeto.

O que me fez querer trabalhar com a usabilidade do fazDelivery foi justamente a página de resultados da ferramenta. Os itens de resultado espalhados etc, me incomodavam e eu queria mexer naquilo. E então trouxe isso para o TCC e desde o anteprojeto indiquei que o objetivo principal seria melhorar a SERP do FD. Então entrei de fato nas etapas do projeto, fui seguir os passos formais de resolver problemas de interfaces e muitos meses se passaram. rs. Referencial Teórico, Planejamentos, Adaptações, Cronogramas, Reduções de Escopo, Sessões de Avaliação Heurística, de Testes com Usuários, compilar todos os dados que daí surgem, ver os problemas que as pessoas apontaram (ao invés de sair mexendo a partir do que eu gostaria), mais reduções de escopo… E tudo isso “de repente” finalmente me leva para o que eu queria fazer lá atrás.

Ufa, ok, então, que houvesse tanta ansiedade no resultado dessa tarefa específica… Tudo isso só aconteceu porque queria fazer algo legal aqui. rsrs. Bueno, ao menos me sinto aliviada porque consegui ultrapassar as barreiras e entender quais eram, e elas faziam sentido.

Post its, ativar! Como ter uma comparação "rápida e simples" de posições de elementos de vários sites.

Post its, ativar! Como ter uma comparação “rápida e simples” de posições de elementos de vários sites.

E o que saiu daí? Fiz duas versões de Item de Resultado (Document Surrogate), tentando separar as informações do estabelecimento das informações do produto, deixando o item como um todo mais compacto e tentando dar mais destaque para algumas informações (além de tirar algumas coisas que pareceram não estar fazendo muita diferença, nos testes com usuários).

Tenho uma versão semi-pronta da página de resultados, que estava esperando ter resultados para irem nela. Fiz análises do Google, GuiaMais, iFood e TeleListas, para comparar onde posicionavam a opção de refinamento de busca (e como a apresentavam), além de quantos resultados exibiam antes da dobra (above the fold), e como estavam centralizados na tela. Usei isso para basear minhas definições de novo layout da SERP do fazDelivery, sempre colocando como restrição pra mim que eu focaria em trabalhar com os elementos já existentes, evitando criar funcionalidades ou elementos novos, e me guiando pelos resultados das avaliações heurísticas, testes com usuários e priorização de problemas que decidi.

Agora preciso encaixar a Busca Avançada na Página de Resultados, resolver Botão de Voltar ou Breadcrumbs – em suma, oferecer uma solução de Controle de Navegação -, e creio que a SERP estará pronta. Aí fica faltando a Página de Listagem de Categorias, na qual já dei uma pensada, e que será mais simples, uma vez que o item de resultado já está pronto.

Bueno! É isso! Vou dormir e voltar pra terminar essa parte. Ainda há um tanto razoável de coisas a fazer e depois precisarei descrever tudo mais formalmente, na mono. E ainda tenho de revisar tudo.

Woooo!

Estamos, meu bem, por um triz para o dia nascer feliz.

[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…

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?

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.

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 Heurística] Compilação dos problemas e construção do questionário para classificá-los

Continuo travada na porcaria da atividade para priorizar os problemas encontrados na avaliação heurística. Foram muitos (algumas pessoas encontraram mais de 40, para se ter uma ideia), e me parece pouco factível colocar as pessoas pra classificar todos os problemas que todos encontraram, dentro do contexto do projeto – elas não estão sendo pagas, nem nada.

Também é um trabalho chato e, pra mim, difícil, juntar tudo o que todos pensaram em um conjunto coerente, que eu considere que as outras pessoas entenderão e conseguirão classificar. E isso tudo está me deixando emperrada. Empacada. Já perdi muito mais tempo do que devia, nessa etapa. Eu devia estar fazendo os questionários de usuários, e pensando como irei conduzir/gravar os testes de usuário de uma forma que seja razoável, depois, recuperar os dados necessários para o projeto.

Seja como for, tenho de encontrar uma solução para esses dilemas hoje, pois daqui a 5 dias os principais problemas precisam estar corrigidos, para que as pessoas possam testar a versão menos bugada do fazDelivery. Precisarei ser objetiva e criativa. Talvez não tenha como correr do questionário, nem que seja para eu mesma usar, pois alguma classificação e priorização se fazem necessárias, para saber o que atacar…

@#*@%#! Esse questionário é ilegível. Saco.

EDIT: dei-me conta, agora, que há pelo menos duas coisas que tenho de fazer, independentemente das classificações: i) destacar o que são erros (pois não posso apresentar erros graves para os usuários, se já os conheço); ii) percorrer todos os problemas, observando quais estão no escopo do que posso e pretendo fazer nesse projeto, pois é bem provável que algumas coisas escapem à ideia inicial e, tenho de ter claro – para mim, para o projeto – até onde irei…

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…