Da série: leituras interessantes não feitas

Mais coisas do Nielsen que eu gostaria de ler um dia:

http://www.nngroup.com/articles/unmoderated-user-testing-tools/

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? >.<‘

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

Mais indicações de Nielsen

Será que um dia conseguirei todos os materiais interessantes que chegam na newsletter do grupo NN? Chegou um hoje – First Principles Of Interaction Design (revised and expanded) que me parece um “must see”, pra mim. Acho que farei isso. Vou classificá-los por ordem de importância, e ver se com isso avanço nessas leituras “extras”.

Esse outro post do NN parece interessante porque aborda navegação por filtros vs. facetas, que são algo que a Hearst considera uma boa prática para buscas, então quero saber quais as contribuições de Whitenton (autora do post) sobre o assunto…

Revisar objetivos!

Seguindo a linha de repensar o título após o caminho percorrido, creio que precisarei reavaliar os objetivos. Nos idos de muitos meses atrás, quando escrevi meu anteprojeto, eram eles:

Objetivo Geral
Construir uma interface para SERPS de engenhos de busca, combinando técnicas de IHC e interfaces e ferramentas inovadoras já existentes. Pretende-se aproveitar o fato de que um buscador vertical, por ter um propósito específico, tende a ter um espectro de consultas e de fontes de resultados menos amplo que um buscador vertical horizontal para chegar a uma interface que ofereça uma interação mais ágil, eficiente e satisfatória para seus utilizadores.

Para apoiar a avaliação e validação de tais aspectos, serão utilizados métodos quantitativos, e.g. através de testes A/B com os usuários da plataforma de estudo de caso – o fazDelivery – e qualitativos, com testes de usabilidade conduzidos com usuários selecionados, para extrair observações mais detalhadas de sua experiência com o uso da interface proposta.

Objetivos específicos

• Realizar estudo comparativo das SERPs dos buscadores mais usados e conhecidos atualmente;
• Realizar estudo comparativo de inovações para SERPs;
• Fazer relatório e teste de usabilidade da SERP atual do fazDelivery;
• Propor nova SERP para o fazDelivery, a partir dos estudos realizados;
• Realizar testes de usabilidade com a nova SERP sugerida;
• Avaliar qual a SERP do fazDelivery mais eficiente, a partir dos testes feitos antes e depois.

Quando fiz a apresentação para TCC I, deixa de haver um objetivo geral explícito, e eles se transformam em:

Objetivos

• Propôr heurísticas de usabilidade para buscadores verticais como o fazDelivery;
• Comparar buscadores verticais de empresas em geral ou de delivery;
• Avaliar a interface de busca do fazDelivery (com heurísticas e testes de usabilidade);
• Propor uma nova interface para o fazDelivery, a partir das avaliações;
• Avaliar e comparar as diferentes versões de interfaces do fazDelivery.

Creio que estes últimos, pensados após ter escrito o referencial terórico, talvez estejam mais alinhados, mas, por outro lado, agora preciso: i) compará-los; ii) extrair um objetivo geral que embarque estes específicos e que descreve bem o que estou fazendo, para servir de apresentação e norte para o projeto.

EDIT: agora que reparei um erro no objetivo geral, repetindo buscador vertical nas duas partes da frase.

A quantidade de informações interessantes é “over nine thousand”

Uma vez imersa no processo bastante cíclico de tentar escrever, ler e, principalmente, sintetizar o que já foi ou é lido, uma das maiores angústias que surgem é: é muita informação no mundo.

Em um primeiro momento, isso é assustador e oprime, porque parece que não serei capaz de absorver o mínimo necessário para entender o tópico. Quando consigo vencer este medo e começo a ler, por um lado perco a sensação de que nunca serei capaz de entender aquilo, e fico feliz. Isto pode passar rapidamente, quando paro a etapa de descoberta e leitura de fontes, e volto ao processo de escrita. Então a quantidade de informação que absorvi me parece grande demais para que eu consiga concatenar e sumarizar satisfatória e logicamente. Eventualmente consigo ultrapassar essa barreira e escrevo algo – normalmente, para isso, preciso abandonar minhas expectativas acerca da qualidade e do estilo de escrita, e simplesmente me deixar dizer o que entendi. Quando termino, é novamente boa a sensação de ter conseguido vencer um tópico.

Então, novamente me vejo diante de um assunto relativamente desconhecido, e recomeça o ciclo.

Diretrizes para interfaces de busca para o usuário

Lendo Clarifying Search: A User-Interface Framework for Text Searches, de Ben Shneiderman, Don Byrd e W. Bruce Croft. Hearst cita ele como um artigo influente na área, e pela temática consigo entender. Entretanto, talvez por ser de janeiro de 1997, algumas das recomendações e descrições de funcionamento de mecanismos de busca parecem meio obsoletas hoje em dia. Creio que terminarei a leitura para poder fazer uma comparação mais embasada com as sugestões de Hearst (2009), e para entender de onde as diretrizes dela surgem, também.

Mercun cita um artigo mais recente de Shneiderman, publicado em 2008, que aborda uma temática mais específica, mas que, dado o contexto do fazDelivery, talvez seja útil: Users can change their web search tactics: Design guidelines for categorized overviews (Bill Kules, Ben Shneiderman).

Preciso concluir hoje a parte de usabilidade, para haver tempo hábil para os capítulos sobre Engenhos de Busca e o descritivo do fazDelivery.

(…)

O artigo de Shneiderman de 1997 apresenta um framework com quatro partes para apoiar quem projeta interfaces de sistemas para recuperação da informação:

  1. Formulação da consulta – a ideia é prover controle ao usuário para que ele possa decidir e escolher, ou, no mínimo tomar conhecimento de como se processam:
    • Fontes: onde realizar a pesquisa, no caso de haver diferentes bases de dados, ou diferentes coleções possíveis;
    • Campos: sobre que campos dos documentos da coleção será realizada a consulta;
    • O que buscar: deve ser possível prover o texto para pesquisa, separando-o em mais de uma frases, se necessário; stop lists devem ser conhecidas (e, como dito, preferencialmente o usuário deve ter controle sobre elas);
    • Variantes: diferenciação de maiúsculas ou minúsculas, radicais extraídos e escolhidos, aproximações fonéticas ou de sinônimos devem ser mostrados como opções, se existirem, ou no mínimo informados, mesmo que não possam ser alterados.
  2. Ação – como a busca é iniciada: a ideia aqui é que isto pode ser feito de forma explícita, com um enter ou um clique, ou como uma consulta dinâmica;
  3. Revisão dos resultados – permitir, por exemplo, que os usuários limitem o número de resultados retornado, estilo de ordenamento (e.g., alfabético, índice de relevância), e o que compõem os resumos dos documentos;
  4. Refinamento – Shneiderman sugere que se mantenham um histórico de pesquisa, para que os usuários possam reutilizar esforços anteriores. Isso pode significar tanto manter o histórico de pesquisa dentro de uma sessão quanto ao longo de sessões (por exemplo, permitindo que o usuário salve conjuntos de resultado e query para mandar por e-mail ou consultas posteriores). Feedback útil sobre o set de resultados também pode ajudar.

Ok, além deste framework, o autor adapta oito diretrizes para construção de interfaces em geral para o contexto da recuperação de informação. Já as postei aqui anteriormente, porque Hearst as cita em seu livro.

A parte final do artigo são dois estudos de caso em que, similar a uma análise de usabilidade a partir de heurísticas, os autores apresentam duas interfaces (uma web, outra para desktop), avaliam onde precisam melhorar, com base em seu framework e diretrizes, e depois apresentam alterações feitas com o intuito de torná-las melhores (dã, péssima frase).

Eles são especialistas, então creio que isto baste, mas dos trabalhos que tenho visto, senti falta de eles fazerem testes com usuários com as duas interfaces (ou quatro, já que foram dois estudos de caso) para dizer como cada uma se saiu, para além das avaliações heurísticas.

What is usability, in Usability Engineering (Nielsen, 1993)

Para definir usabilidade no Referencial Teórico, mesmo já havendo lido a respeito, senti necessidade de buscar o Usability Engineering, de Jakob Nielsen (1993).

Alguns destaques, por hora:

Clarifying the measurable aspects of usability is much better than aiming at a warm, fuzzy feeling of “user friendliness” [ShackelI991]. (mas não fica claro pra mim se ele quer dizer que está parafraseando Shackel, ou se Shackel falava em almejar a essa sensação difusa de “amigável”).

“(…) usability is measured relative to certain users and certain tasks. It could well be the case that the same system would be measured as having different usability characteristics if used by different users for different tasks.”

É engraçado ler algumas coisas desse livro de Nielsen, porque em 1993 a popularidade dos computadores era muito diferente do que temos hoje em dia, então ele ainda precisava entrar em tópicos como, por exemplo, como o entusiasmo (ou não) em relação a computadores poderia afetar a noção geral de satisfação com o uso de um sistema. Apesar de, em alguns contextos, esta observação ainda ser válida, na realidade da maioria dos desenvolvedores de software, hoje em dia, seu público-alvo será usuário contumaz não apenas de computadores, mas muitas vezes de smartphones e tablets – o que os torna bem diferentes dos usuários descritos por Nielsen, há 20 anos atrás.

(…)

Em comparação com minhas leituras anteriores de cada aspecto em que se costuma caracterizar a usabilidade, tenho a impressão de que Nielsen explica melhor a função de cada um destes atributos (facilidade de aprendizado; eficiência; memorização; ausência de erros graves / capacidade de recuperação de erros; satisfação subjetiva) também porque, em alguma medida, ele os relaciona a perfis específicos de usuários – ou ao que se quer mensurar. Algumas das considerações que ele faz não são difíceis de se chegar a partir de cada aspecto, mas tenho a sensação de que é possível passar em branco por esses desdobramentos se não se para pra pensar a respeito. Assim, por exemplo, do mesmo modo que capacidade de aprendizado irá se relacionar melhor com a usabilidade para usuários novatos do sistema, eficiência mede mais a interação de usuários que já têm um certo domínio da ferramenta, e a memorização avalia melhor a interação de usuários que, apesar de usarem repetidamente o sistema, passam intervalos de tempo significativos sem fazê-lo (seja devido a uma característica do sistema – digamos, por exemplo, o software para declaração do imposto de renda), ou do usuário (digamos, uma pessoa que não tenha o costume de checar e-mails e passe dias sem fazê-lo).

Reescritas e embasamentos

Começando a me sentir insegura de citar Nielsen, porque ele em si, às vezes, não cita nada. Talvez seja porque se trate de senso comum, mas torna tudo meio frágil para se construir sobre. Anyway, li The Mud-Throwing Theory of Usability, dele, buscando algum embasamento para explicar por que sites em geral costumam ter tantos problemas de usabilidade. A justificativa geral de Nielsen gira em torno do time to market (ou seja, da pressa de lançar logo), misturada com a ideia corrente de que, qualquer coisa, conserta-se o que estiver ruim depois. Nielsen é da opinião de que sai mais barato e menos custoso realizar alguns testes e prototipações antes de desenvolver, e, assim, lançar um produto com menos problemas de usabilidade.

(…)

Reescrevi minha introdução. Estava devendo deixá-la com duas páginas e mais objetiva desde antes de 20 de outubro. Agora, ela está com o tamanho adequado e, teoricamente, aborda, ainda que de forma primária, os três tópicos mais importantes: i) problema, ii) contribuições e iii) organização do trabalho. Sinto que, do que escrevi, há duas correntes brigando para ganhar espaço em meu trabalho:

  • uma compilação de heurísticas e inovações em usabilidade de buscadores;
  • uma avaliação e melhoria do fazDelivery, que poderia talvez ser extrapolada para melhoria de buscadores tipo catálogo.

O que eu sinto que quero e tenho como fazer é o segundo. Mas ao mesmo tempo parece que me falta estofo para falar com propriedade do que quer que seja. Sinto que nunca vou ter um trabalho bem amarrado e justificado. >.<‘

Mas, ok. Continuar.

Estudo Comparativo da Usabilidade de Interfaces para Dispositivos Móveis

O trabalho de Jussi faz uma comparação entre a produtividade de interfaces rasas vs. profundas em dispositivos móveis tipo touchscreen. Para realizar a comparação ela criou uma ferramenta para simular tarefas comuns a um gerenciador de arquivos, que ao mesmo tempo mensurava tempo e quantidade de cliques gastos em cada tarefa.

É uma monografia bem detalhada do ponto de vista do percurso seguido, e me soou bem embasada – com um bom diálogo entre as fontes, e cada referência parece bem justificada ou encaixada no conjunto do trabalho.

Para seguir de exemplo: mesmo roteiro para as duas interfaces – Claybony teve a mesma abordagem (do contrário, como comparar?). Jussi também define claramente critérios de comparação.

Achei particularmente interessantes as referências:

FAULKNER, L. Beyond the five-user assumption: Benefits of increased sample sizes in usability testing. Austin, Texas, 2003. => aprofunda a discussão em torno da quantidade ideal de pessoas para um teste de usabilidade (para contrabalançar o ponto de vista de Nielsen).

PORTER, J. Testing the three-click rule. User Interface Engineering, 2003. => Não há correlação direta entre número de cliques e abandono de página ou sucesso para completar uma tarefa, na web.

WEINSCHENCK, S. 100 Things Every Designer Needs to Know About People. USA: New Riders, 2011. => outra fonte que fala sobre os modelos mentais dos usuários serem baseados em experiências prévias com outros produtos (similar à Lei de Jakob, em alguma medida, certo?) e que o stress pode fazer tarefas parecerem mais complicadas do que são.