Preparativos para a 1ª rodada de testes de usabilidade

Após o choque inicial de não ter reservado tempo suficiente para os testes de usabilidade, e estar com tarefas atrasadas, consegui me recuperar, reorganizar o cronograma e fazer uma lista com cerca de 20 pessoas que acredito que podem dispor de uma hora para participar dos testes de usabilidade.

Foquei principalmente em amigos e colegas de trabalho, e busquei situações em que pudesse tê-los todos juntos, para evitar gastar muito tempo entre cada teste. Estou planejando fazer 10 testes em cada rodada, mantendo, entre a primeira e a segunda, 5 pessoas, para ter uma noção de como quem usou antes das melhorias sente a segunda versão.

O ideal para testes de usabilidade é definir um perfil de usuário. Eu levantei as informações que tinha, das pesquisa de mercado que fizemos para o fazDelivery, a respeito disso. Idealmente seriam pessoas entre 25 e 44 anos, que morem sozinhas ou com companheir@, mas não tenham filhos. Entretanto, como alguns autores consideram que o conjunto e variedade das tarefas escolhidas são mais importantes do que a quantidade/ perfil de usuários, e os recursos desse projeto são limitados, o perfil original, pensado para equivaler ao público early adopter do fazDelivery, não está sendo seguido à risca.

Testes de usabilidade

Eu havia, por alguma razão, separado apenas um dia para cada rodada de testes de usabilidade. Parando pra planejar o roteiro dessas atividades, especialmente depois das avaliações heurísticas, ficou muito claro pra mim que isso não iria funcionar, porque eu preciso estar completamente dedicada a cada pessoa, uma por vez, e não necessariamente conseguirei reunir todas elas em um só lugar etc. E eu preciso testar o fazDelivery com pelo menos 5 pessoas de cada perfil que eu definir, idealmente. E o mínimo de perfis que consigo pensar são dois: que já usaram o fazDelivery e que nunca usaram. Então, 10 testes, com 10 pessoas, em cada rodada.

Gastei, então, um tempo ontem revendo o cronograma para encaixar essa mudança. Também pensando quem seriam as pessoas. E vendo o esboço/conteúdo do roteiro dos testes. Amanhoje vou dividir melhor quem acredito que pode/deve ficar em cada grupo e sessão, e dispararei os convites.

Espero que tudo corra bem. Estou com um atraso de uma semana e isso está me assustando um pouco.

Avaliação dos concorrentes

Há um tempo atrás estava em dúvida em relação a qual a melhor abordagem para avaliar os concorrentes. Na época já me parecia que as avaliações heurísticas não seriam o caminho.

Ainda assim, até hoje essa tarefa está lá no cronograma. Hoje, como a revi, pensei mais uma vez no assunto. E realmente, para o que quero, não faz sentido comparar e avaliar os concorrentes a partir dessa abordagem. Eu quero saber o que os concorrentes provêm em termos de funcionalidades e facilidades para os usuários, não quem tem mais problemas… Logo, avaliação heurística para concorrentes is no more.

Será que alguém precisa rever e atualizar alguns pontos de sua metodologia? >.<‘

Atrasos e percepções

Olhando o trello, noto que minha situação está mais apertada do que tinha me dado conta no sábado. Acho que estou com uma semana inteira de atraso, não planejei bem como iam ser as coisas durante as avaliações heurísticas nem fiz um cronograma muito à prova de furos no fim de semana. Ok, ainda consigo lidar, é ótimo conseguir ver no detalhe o que está errado e faltando, e onde.

Mesmo com outras tarefas em aberto, hoje preciso focar em definir perfil para os usuários que farão parte da primeira rodada de testes e convidá-los, para isso não ficar muito em cima. Precisarei fazer um balanço entre pessoas com o perfil previsto para o público do fazDelivery e pessoas que eu consiga acessar mais facilmente, senão posso ter muitas dificuldades com essa etapa, porque, diferentemente das avaliações heurísticas, eu não gostaria de fazê-la remotamente, então terei de, talvez, ir atrás das pessoas. Ou, bem, montar um esquema de acompanhar a tela das pessoas, mesmo, e paciência.

Para os testes de usuário Nielsen e outros sugerem pelo menos 5 representantes de cada perfil de público alvo. Isso me faz pensar que precisarei de umas 15 pessoas para essa rodada. Pensar em um número desses me dá um pouco de medo, primeiro porque não sei se encontro tantas pessoas disponíveis, segundo porque isso indica o tempo para concluir essa etapa será meio longo, e de uma forma que não tenho muito como controlar.

Mas, paciência, demorar não vai tornar nada mais fácil, e ainda pode impossibilitar completamente algumas atividades.

Avaliações heurísticas – andamento e aprendizados

Quase no fim das sessões de avaliação heurística (esta semana foi reservada pra isso). O processo é legal, e teve dois pontos interessantes:

  1. Pessoas de áreas distintas. Convidei, além de pessoas com formação em Sistemas de Informação, dois Designers. Além do fato geral de que pessoas diferentes trazem olhares diferentes, obtive feedbacks mais específicos de estética que achei bacanas;
  2. Para me adequar à realidade dos avaliadores e não gastar muito tempo deles ou meu, a maioria das sessões foram remotas (apenas uma foi presencial, até o momento). Dessas, muitas foram acompanhadas sincronamente via alguma ferramenta de video conferência / chat por voz, e uma foi feita sem acompanhamento. Uma foi realizada presencialmente. Isso me permitiu ter uma ligeira noção de vantagens e desvantagens de cada abordagem. Da experiência, creio que optaria por sessões remotas com think aloud e conversa por voz. Dão mais espaço para o avaliador (e talvez usuário, até) se sentir mais à vontade, mas contam com a vantagem de acompanhar o processo que os leva a cada conclusão, o que permite entender melhor os pontos que levantam.

Acabei optando por seguir um modelo em que os avaliadores indicam os problemas, e eu posteriormente os categorizo, dentro das heurísticas. No processo de categorização, estou sentindo falta de acrescentar duas:

  • onboarding: sistemas devem ter baixa curva de aprendizado e interface intuitiva, especialmente se forem ferramentas com funcionalidades de algum modo inovadoras / incomuns;
  • estética: interface deve ser agradável e não cansativa ao usuário (por exemplo, não usar muitas fontes, ter contrastes corretos). Isso me parece diferente da heurística de design e estética minimalistas. Preciso pesquisar e/ou falar com os orientadores a respeito, para decidir o que fazer.

O roteiro evoluiu na medida em que as avaliações ocorreram, principalmente as primeiras. A moda de duração das sessões foi cerca de uma hora. E, de minha observação, os avaliadores tendem a notar mais problemas quando fazem a inspeção conversando com o observador.

Amanhã e sábado talvez acontecem as sessões de avaliação com os orientadores. Espero conseguir fazer ao menos com um deles, para mim enriqueceria bastante o trabalho. Depois das sessões concluídas, farei uma única lista com todos os problemas levantados, para que todos os avaliadores possam lê-la e avaliar o grau de severidade de cada problema, utilizando a escala com 5 níveis de severidade. Estou pensando em usar o google forms pra essa etapa, tenho de testar a legibilidade do resumo de respostas.

EDIT: esqueci de comentar, mas o processo das avaliações me fez pensar que preciso repensar o agendamento pros testes de usuário. Aspectos de tempo, de como farei pra encontrá-los etc. precisam ser melhor pensados.

Evolução da tecnologia e usabilidade

Achei interessante. Quando não há outras opções, acho que encaramos os problemas / dificuldades com outra disposição. Há níveis diferentes de “fetishe” e análise, e algumas coisas de fato se tornam muito estranhas quando surgem soluções mais simples (rebobinar e avançar pra achar uma música? zilhões de fitas? ew…).

Para além disso, é legal ver as reações das “crianças”…

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.

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

Dúvidas acerca dos objetivos e resultados de avaliações heurísticas e testes de usuário

Às vezes, quando vejo alguns comentários / metas esperadas para os testes de usabilidade e/ou avaliações heurísticas, fico com a sensação de que uma parte minha não tem completa clareza do que cada método de inspeção irá gerar…

Após terminar isso, talvez seja interessante fazer uma pequena tabela comparando as duas abordagens e mostrando pontos fortes e fracos de cada uma. É possível que Nielsen tenha algo para amparar isso, até.

[LaTeX] Referenciando itens de uma lista ou enumeração

Este não tem mistério. Se você já pensou em fazer isso enquanto estava com a mão na massa, provavelmente simplesmente fez como a intuição mandou e acertou. Contudo, porém e entretanto, vai que não, vai que você tá começando com LaTeX e simplesmente correu pro Google. Vai saber, né.

Então, para você que não soube/sabe como fazer, o lance é… Acrescentar o famoso label, e depois usar \ref (ou \autoref, que testei e também funcionou, aqui). Psé. Como em…

\begin{enumerate}
 \item \label{it:def} definição das interfaces a serem inspecionadas;
 \item \label{it:heu}levantamento de heurísticas de usabilidade para buscadores;
 \item os itens \ref{it:def} e \ref{it:heu} são utilizados como entradas para as avaliações.
\end{enumerate}

O resultado fica tipo isso:

1. definição das interfaces a serem inspecionadas;
2. levantamento de heurísticas de usabilidade para buscadores;
3. os itens 1 e 2 são utilizados como entradas para as avaliações.

Eu fiz, e enquanto compilava já tava abrindo aba no navegador e pesquisando como era. Aí vi que funcionou, mas também acabei chegando num post (em inglês) explicando em mais detalhes, então fica de referência para quem gosta de ler, e porque parece um blog legal de conhecer, pra quem usa LaTeX: Cross referencing list items.