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

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.

Planejando e construindo as instruções para a avaliação heurística

Ok, consegui criar as instruções (já foram, também, devidamente revisadas e enviadas).

Elas são um misto de roteiro que explica o que vai acontecer e como os avaliadores devem proceder, com uma síntese dos conceitos abordados na sessão (o que e quais são as heurísticas, como classificá-las), para que as pessoas se sintam confortáveis com a tarefa que está por vir.

Consegui confirmação de 8 pessoas para participarem dessa etapa de inspeção, incluindo os dois orientadores. Comigo, serão 9 pessoas realizando a avaliação, sendo 2 delas designers formados (Yays para isso, quero ver se – e como – esse aspecto vai influenciar na percepção dos problemas de usabilidade). Meus próximos passos são:

  • acompanhar as sessões de avaliação
  • compilar os problemas identificados, repassar para que as pessoas classifiquem
  • revisar as classificações e gerar grau de severidade médio para cada problema

Ah, um post com exemplos de boas práticas para cada uma das dez heurísticas: 6 tips for a great flex design – review usability best practices. Bom para ajudar a visualizar as coisas. E explicando de um jeito legal cada heurística.

Abaixo, alguns destaques de artigos de Nielsen em que me baseei para construir as instruções. Relendo-os, lembrei que esqueci da possibilidade de criar um cenário de uso. Acho que vou aproveitar que tenho um tempo até a data das sessões e pensar em um, para repassar pras pessoas, mais a guiza de contextuação.

In principle, the evaluators decide on their own how they want to proceed with evaluating the interface. A general recommendation would be that they go through the interface at least twice, however. The first pass would be intended to get a feel for the flow of the interaction and the general scope of the system. The second pass then allows the evaluator to focus on specific interface elements while knowing how they fit into the larger whole.

(…)

One approach that has been applied successfully is to supply the evaluators with a typical usage scenario, listing the various steps a user would take to perform a sample set of realistic tasks. Such a scenario should be constructed on the basis of a task analysis of the actual users and their work in order to be as representative as possible of the eventual use of the system. The output from using the heuristic evaluation method is a list of usability problems in the interface with references to those usability principles that were violated by the design in each case in the opinion of the evaluator. It is not sufficient for evaluators to simply say that they do not like something; they should explain why they do not like it with reference to the heuristics or to other usability results. The evaluators should try to be as specific as possible and should list each usability problem separately. For example, if there are three things wrong with a certain dialogue element, all three should be listed with reference to the various usability principles that explain why each particular aspect of the interface element is a usability problem. There are two main reasons to note each problem separately: First, there is a risk of repeating some problematic aspect of a dialogue element, even if it were to be completely replaced with a new design, unless one is aware of all its problems. Second, it may not be possible to fix all usability problems in an interface element or to replace it with a new design, but it could still be possible to fix some of the problems if they are all known.

Referências deste post:

Nielsen, Jakob. Ten Heuristics for User Interface Design.

____________. Severity Ratings for Usability Problems

____________. How to conduct a heuristic evaluation