é amanhã ‘-‘

às oito da manhã

estou nervosa

>.<‘

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…

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.

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…