Reflexões: escrever aos poucos, ao longo do processo

O fato de eu ir escrevendo na medida em que vou decidindo o que fazer, mesmo que por vezes me faça pensar que estou evitando entrar em algumas tarefas, geralmente me ajuda a refletir muito mais sobre o que estou fazendo, de modo que consigo entender mais o que estou planejando, e tenho mais chances, assim, de avaliar se estou fazendo a coisa certa, tomando as decisões certas, seguindo o caminho certo…

Ou, mesmo que eu não consiga seguir o melhor caminho, ao menos eu posso tentar entender por que não estou seguindo. Se a justificativa for razoável, então eu sigo (:

Exemplo desse processo, hoje: mais cedo, comentei que começaria a prototipar hoje. Entretanto, no processo de analisar como iFood, GuiaMais e TeleListas resolviam as coisas que estava com problemas no fazDelivery, gerei umas tabelas que queria passar logo pro LaTeX. Quando fiz isso, percebi que precisava reestruturar o capítulo sobre prototipação, para encaixar cada coisa em seu devido lugar e dar uma noção da ordem lógica que segui. E, quando fiz isso, percebi que eu não podia já ter proposto soluções antes de ter olhado os concorrentes – mas foi o que aconteceu. Então, amanhã vou revisar as soluções que tinha proposto, comparando com as das outras ferramentas.

[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: 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.

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.

Refinamento de Objetivos Geral e Específico

Hoje (ontem) fiz a primeira versão de meu capítulo sobre a metodologia de inspeção e melhoria de usabilidade utilizada no projeto. Como o orientador sugeriu que eu desse mais destaque a ela no trabalho, pareceu-me adequado inserir um espaço para explicá-la melhor. O capítulo por enquanto só tem uma página, mas não pretendo que seja grande, só quero realmente conseguir apresentar a metodologia híbrida a partir da figura que criei para ilustrá-la.

Avancei um pouco na questão dos objetivos. Creio que o geral, principalmente, ainda precisa ser melhor trabalhado. Por enquanto, sua nova versão está assim:

Aplicar heurísticas e boas práticas propostas para a usabilidade de engenhos de busca a uma ferramenta de busca vertical do tipo diretório (ou catálogo), visando a uma IHC mais satisfatória e eficiente, tendo como base a definição de Nielsen (2012) de tais termos. A metodologia de inspeção de interfaces proposta e as melhorias propostas serão aplicadas e testadas no fazDelivery, um buscador geolocalizado de serviços de delivery de Salvador.

Os específicos não mudaram muito dos que apareceram na apresentação final de TCC I. Aproveitei que mexi nos objetivos e já os coloquei na apresentação no Prezi, para ir mantendo-a atualizada e ir lhe dando forma, aos poucos.

Ainda estou devendo revisar a distribuição de tarefas no cronograma, mas estou focando nessas atividades porque me coloquei uma entrega para esta sexta, dia 04/04, e preciso avançar para conseguir alcançar esta meta…

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…

39 dias: HCI e – qual é o meu problema?

Comecei um curso de Interação Humano Computador pela UC San Diego (https://class.coursera.org/hci-004/class/index), no Coursera. Inscrevi-me porque considerei que seria uma abordagem interessante para aumentar os conhecimentos necessários pro projeto de TCC. O curso termina dia 9 de dezembro. Creio que valéra.

Algumas anotações, das vídeo-aulas das duas primeiras semanas:

A meta da prototipação é… feedback.

Focus on goals. Evolve the design.

What do prototypes prototype?

Feel

Implementation

Role

Se protótipos são perguntas, faça muitas!!

——————————————————

Aspectos a considerar no momento de escolher o(s) método(s) de avaliação de interface:

  • confiabilidade / precisão
  • generalização
  • realismo
  • capacidade de comparação
  • quantidade de trabalho envolvido

=> O que você quer aprender?

——————————————————

O que se pode aprender através da observação participativa (participant observation)?

  1. What do people do now?
  2. What values and goals do people have?
  3. How are these particular activities embedded in a larger ecology?
  4. Similarities and differences across people?
  5. … And other types of context, like time of the day

To learn more: Kuniavsky – Observing the user experience. Beyer and Holtzblatt – Contextual design

——————————————————

Entrevistas:

Escolha dos participantes

  • representantes dos usuários-alvo
  • podem ser usuários de um sistema similar (caso, por exemplo, se esteja querendo criar uma versão melhor de algo)
  • podem ser não usuários, caso a ideia seja aumentar o público alvo de um determinado tipo de software

——————————————————

Outcome of activity analysis:

  • what are the steps?
  • what are the artifacts?
  • what are the goals (how you’ll measure success)?
  • what are the pain points (or opportunities)?

——————————————————

O tradicional “projeto final” do curso, que foca em avaliar na prática os estudantes, é para desenvolver um protótipo de interface funcional, para um software baseado na web ou mobile, desde o momento de observar usuários para encontrar um problema real, passando por diversos níveis de prototipação, avaliação com usuários e iterações. Estou pensando em mesclar os direcionamentos do projeto lá para me ajudar na metodologia de melhoria da interface do fazDelivery, também.

Enquanto isso, preciso repensar e refinar meu problema de pesquisa, voltar a escrever a monografia e começar a prototipar e/ou avaliar as interfaces atuais, porque sei que haverá muito feedback dos orientadores neste ponto também…