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.

Descrição da Metodologia e Pequenos Ajustes na Monografia

Hoje fechei de fato uma primeira versão do capítulo de metodologia. Considero que funciona como uma primeira versão porque, mesmo tendo apenas duas páginas, fiz uma descrição do que cada etapa e produto ou subproduto significa, então creio que supre a necessidade inicial.

Fiz alguns ajustes na monografia, acrescentando referência ao capítulo de metodologia na introdução e, também nela, alterando o objetivo geral. Acho que foi basicamente isso…

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…

Passinhos de formiga… v1 Cronograma feita

Ok, encaixei as atividades que quebrei dentro dos marcos da disciplina de TCC II, até as datas de banca e entrega da versão final. No processo, pra variar, percebi que algumas poucas coisas tinham ficado de fora, então houve mais detalhamentos e atividades.

Mas acho que ficou meio desequilibrado, intervalos grandes no início e tudo meio atropelado no fim. Amanhoje irei revisar, com a cabeça descansada e buscando uma visão mais global da coisa. E aí tentar rebalancear, avaliando melhor a carga de trabalho das atividades, também.

É isso. Muito trabalho a ser feito. Sentindo-me um tanto angustiada, mas mais focada e menos perdida. Por incrível que pareça.

Alinhando e andando e buscando orientação

Hoje fui encontrar EJ para nos alinharmos. Ele me passou um modelo de relatório de usabilidade, e enquanto conversávamos fui lembrando coisas (tarefas, detalhamentos) que precisavam estar presentes no Trello. Consegui acrescentar tais coisas, mas não cheguei a terminar a tarefa de colocar datas em todas as atividades que precisam ser feitas. Preciso respirar um pouco mais no assunto para conseguir visualizar o que cabe onde, e como…

Que título horrível. É o que dá fazer as coisas com sono. O cérebro já não funciona tão bem.

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…

Follow

Get every new post delivered to your Inbox.