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?

Receios, Dúvidas y otras cositas más

Algumas observações meio soltas, após este dia de escrita.

Em relação aos testes com usuário que fiz até então, tenho receios de que sejam muito frágeis os pontos:

  • Perfil dos usuários;
  • Tamanho da amostra.

Estava em dúvida se deveria listar todos os problemas classificados em relação ao grau de severidade. Entretanto, após criar uma tabela com dez deles e ver o tamanho que ocupou, considerei que era melhor não fazê-lo. Acrescentei, no entanto, o resumo da classificação de severidade do questionário do docs, assim, as informações estão todas lá (e o processo que eu usei para chegar às médias também, então se alguém precisar, ou quiser, pode estendê-lo e ter todos os valores). Com isso, tenho uma primeira versão final da seção que descreve o percurso das avaliações heurísticas…

Observações soltas:

  • eu amo o Google Docs – muito bom ter opção de gerar impressão bonitinha de um formulário online…
  • às vezes me pergunto se o tempo que ganho não precisando formatar o documento no LaTeX não é todo perdido ajeitando tabelas no mesmo… >.<‘

Já comentei aqui que tenho receio de meu TCC estar fraco/ pobre? Caso não, estou comentando agora. Estou evitando pensar nisso, e só seguindo, e explicando meu processo e minhas decisões o melhor que posso, para agregar o máximo de valor possível. Mas, por vezes, a sensação volta, e é ruim. E, dito isto, me lembro que já falei disso, sim.

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.

Alguns pontos ainda confusos

Defini, para amanhã, realizar a avaliação heurística dos três concorrentes do fazDelivery escolhidos para comparação, no projeto: iFood, GuiaMais e TeleListas.

Cada vez mais pendo que essa não é a melhor forma de caracterizá-los, para fazer uma comparação, o que significa que ainda preciso pensar como avaliá-los, para ter uma comparação interessante. Por outro lado, como é razoável que eu tenha experiência com avaliação heurística antes de conduzir sessões com as pessoas convidadas para o projeto, creio que será bom mantê-las.

Para a comparação, estou pensando em pegar as funcionalidades principais que devem aparecer em uma interface de busca para apoiar o processo de busca, do ponto de vista do usuário, e então destacar como cada ferramenta favorece cada etapa… Como trazer soluções inovadoras era uma proposta inicial do projeto, também posso tentar destacar aspectos interessantes de cada uma.

Cronograma, Tarefas detalhadas e Reflexões sobre Metodologia (na prática e para a escrita)

Hoje coloquei no Trello as atividades que creio que faltam para concluir o TCC. Comecei colocando as atividades mais cruciais, do core, mas agora terminei por acrescentar algumas que são mais “burocráticas”. Quer dizer, que precisarão ser feitas, mas têm mais a ver com logística do que com conteúdo – como imprimir e entregar versões pra banca, entregar versão final em DVD, coisas assim.

Foi uma atividade interessante porque, por um lado, me deu a sensação de que de fato, hoje, já tenho uma percepção mais clara de quais os passos práticos para concluir o projeto e, por outro, porque me ajudou a lembrar ou levantar alguns detalhes, pensar subtarefas, coisas assim. Agora preciso encaixar essas atividades no cronograma da disciplina, que quero encurtar, pra evitar ter de trabalhar no TCC em junho (copa + fim de contrato de estágio) e para ter uma margem de manobra, caso ocorra algo que me impeça de apresentar no início de junho.

Uma das coisas que percebi quebrando as atividades foi que não sei se o modo como estruturei os capítulos finais da monografia (a parte de projeto e resultados) não ficarão muito quebrados ou misturados, com a metodologia que defini (vide a figura abaixo), porque não existe uma etapa “única” de construção da nova interface do fazDelivery, nem um único momento de testes.

Metodologia - prática

Metodologia para avaliação e melhoria do fazDelivery. Fonte: Reichow J., 2013.

Essa metodologia, desse modo como foi pensada, não permite fazer uma avaliação anterior da interface do fazDelivery (para fins de comparação), porque não “expõe” os usuários à interface original em momento algum… Preciso perguntar para os orientadores se isso é grave. Por um lado entendo que fica meio incompleta a comparação, mas, por outro, como Hearsti (ou Nielsen?) indicam, o melhor é fazer um processo de melhoria híbrido, e como não é simples conseguir usuários para realizar os testes, primeiro se deve realmente fazer uma avaliação heurística e primeira etapa de correções, antes de fazer testes de usabilidade (o que inviabiliza a comparação dos usuários com a interface original)…

Bom, por hoje é isso. Amanhã sem falta preciso casar tarefas e cronograma mais geral e ver quão grave é a situação temporal…

EDIT: estava pensando. Talvez uma forma mínima de realizar um comparativo seja pedir para pelo menos uma pessoa utilizar as quatro interfaces do fazDelivery e comparar seus resultados, mais para efeito ilustrativo, mesmo…

Reescritas e embasamentos

Começando a me sentir insegura de citar Nielsen, porque ele em si, às vezes, não cita nada. Talvez seja porque se trate de senso comum, mas torna tudo meio frágil para se construir sobre. Anyway, li The Mud-Throwing Theory of Usability, dele, buscando algum embasamento para explicar por que sites em geral costumam ter tantos problemas de usabilidade. A justificativa geral de Nielsen gira em torno do time to market (ou seja, da pressa de lançar logo), misturada com a ideia corrente de que, qualquer coisa, conserta-se o que estiver ruim depois. Nielsen é da opinião de que sai mais barato e menos custoso realizar alguns testes e prototipações antes de desenvolver, e, assim, lançar um produto com menos problemas de usabilidade.

(…)

Reescrevi minha introdução. Estava devendo deixá-la com duas páginas e mais objetiva desde antes de 20 de outubro. Agora, ela está com o tamanho adequado e, teoricamente, aborda, ainda que de forma primária, os três tópicos mais importantes: i) problema, ii) contribuições e iii) organização do trabalho. Sinto que, do que escrevi, há duas correntes brigando para ganhar espaço em meu trabalho:

  • uma compilação de heurísticas e inovações em usabilidade de buscadores;
  • uma avaliação e melhoria do fazDelivery, que poderia talvez ser extrapolada para melhoria de buscadores tipo catálogo.

O que eu sinto que quero e tenho como fazer é o segundo. Mas ao mesmo tempo parece que me falta estofo para falar com propriedade do que quer que seja. Sinto que nunca vou ter um trabalho bem amarrado e justificado. >.<‘

Mas, ok. Continuar.