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.

Advertisements

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.