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.

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

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

Finding examples

Li a monografia de Claybony Souza Moraes, que se formou em Análise de Sistemas pela UNEB, com um trabalho também em IHC: Um estudo de usabilidade para software de prescrição de treinamento neuromuscular (Digital Trainer), 2010.

Como o título sugere, ele faz uma análise e melhoria do Digital Trainer, um software feito pela Polisystem, empresa dele e do irmão (pelo que me lembro), que oferece apoio na construção e manutenção de programas de exercícios em academias (para instrutores usarem).

Ele lista os aspectos de usabilidade a serem considerados de acordo com Nielsen, com a ISO 9241 (parte 11) e com alguns outros autores, como Preece, Rogers & Sharp (2005). Detalha também, um pouco, métodos para avaliar uma interface, de acordo com três abordagens: testes, inspeção e investigação.

Médotos de teste de usabilidade:

  • thinking aloud protocol
  • perfomance measurement
  • métodos empíricos
  • co-discovery method

Uma coisa que ele fala que não entendi bem é que

Netto et. al (2004), ressaltam que testes de usabilidade avaliam somente o produto em termos meramente quantitativos, enquanto testes de comunicabilidade produzem tanto dados quantitativos como qualitativos, sugerindo a aplicação de ambos os testes complementarmente para uma única interface.

A parte que não entendo é que, de minhas leituras que citam testes de usabilidade, nenhuma me deu a entender que eram avaliações meramente quantitativas. Talvez ler o que Netto et. al dizem ajude a entender isso e ver se faz sentido para meu contexto ou não.

Métodos de inspeção:

  • avaliação heurística
  • percurso cognitivo
  • inspeção de padrões
  • revisão de guidelines

métodos de investigação:

  • investigação contextual
  • estudos etnográficos ou de campo
  • entrevistas
  • questionários
  • grupos focais

Claybony utiliza testes de usabilidade (10 usuários, sendo 5 novatos e 5 experientes, em cada rodada de testes) e avaliação heurística (três pessoas que desenvolviam o software) para analisar o Digital Trainer. Assim ele contrabalançou a opinião dos especialistas (heurísticas) com a experiência relatada pelos usuários, e operou e comparou métricas quantitativas e qualitativas, conseguindo, por exemplo, avaliar que houve redução de tempo para execução de tarefas específicas e redução de quantidades de cliques por tarefa.

Há muitos livros e artigos citados, preciso olhar novamente com calma a lista de referências. De antemão, uma das coisas que ele cita que quero ler, pra variar, é Nielsen, sobre a quantidade de usuários necessária em um teste de usabilidade: http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/.

A referência de Netto et. al é: OLIVEIRA NETTO, Alvim Antônio de. IHC – Interação Humano Computador: modelagem e gerência de interfaces com o usuário. Florianópolis: Visual Books, 2004. 120 p. (ao menos, creio que seja, porque na parte das referências só aparece esta, e nenhum Netto et al.).

Para amanhã: voltar a escrever, ou ler a monografia de Jussi? Que tal ambas as coisas?

44 dias: detalhar problema, solução (e metodologia?)

Ok, eu preciso definir, com mais clareza, qual o problema do fazDelivery que pretendo resolver, no projeto de TCC. E também qual a solução que proponho. O que sei/sabemos no fazDelivery é que pessoas para quem divulgamos o site e que observamos (ou não) usando, com ou sem explicações do que se tratava o sistema, reportaram alguns problemas de compreensão de qual era o propósito do site, ou o que poderiam encontrar lá ou mesmo como buscar – temos as mais sérias desses reclamações guardadas, desconfio, neste momento, que posso – e devo – recuperá-las.

Para saber se poderia citar essas experiências, li o artigo de Nielsen sobre Discount Usability. Na verdade, uma espécie de auto-análise deste movimento, após 20 anos do artigo (que é de 1989) em que ele propõe esta metodologia: http://www.nngroup.com/articles/discount-usability-20-years/.

Em linhas muito gerais, a ideia é que é possível conseguir resultados e melhorias de usabilidade muito boas com recursos simples, como prototipagem de papel; avaliação heurística e estudos qualitativos, com testes de usabilidade iterados com cerca de 5 usuários.

Um trecho que me chamou a atenção – porque posso tentar avaliar se tenho condições de conduzir testes de usabilidade com o limite de tempo que tenho – foi onde ele fala dos resultados que conseguiu, com essa abordagem, à epoca do artigo:

For the bank account project, I tested 8 different versions of the design; in the IRA project, I tested 11 different versions. These extensive iterations were completed in 90 hours in the first case and 60 hours in the second. Both projects had great results and were possible only with discount methods.

Discount usability often gives better results than deluxe usability because its methods drive an emphasis on early and rapid iteration with frequent usability input.

Creio que preciso perguntar aos orientadores se posso usar os feedbacks iniciais de nossos usuários como justificativa para o problema no fazDelivery – com base na sugestão de Discount Usability de Nielsen, por exemplo. E, a partir daí, avançar…

56 dias: metas atrasadas.

De acordo com o cronograma que tentei fazer, hoje e amanhã eu deveria focar em trabalhos relacionados. No entanto, ainda estou longe de terminar o referencial teórico…

Há alguns artigos do Nielsen que me parecem interessantes, mas que preciso avaliar quanto de fato poderão agregar ao TCC, para decidir se os leio agora ou não. Pensei em fazer uma priorização, mas não sei se farei algo de fato ou só os deixo para outra ocasião, tenho a sensação de que o TCC parecerá “pobre” se citar muitos artigos online desse tipo…

Outro dia sem render praticamente nada. Não posso fazer isso. >.<‘

Confesso: por incrível que pareça, estou perdida entre as leituras.

57 dias: Nielsen time!

Li alguns artigos no site do grupo Nielsen Norman ontem (por isso o post fala em 57 dias), há ainda outros a ler. Um resumo dos que considerei melhores par ao trabalho, até o momento:

Usability 101: Introduction to Usability (2012) – Outra boa introdução à usabilidade, em linguagem simples e direta, trazendo:

  • o que é: a usabilidade, como já falei aqui no blog, diz respeito à facilidade de uso de uma interface. Além das já conhecidas características (facilidade de aprendizado, eficiência, memorização, erros e satisfação), Nielsen lembra do aspecto da utilidade – não adianta ser fácil e satisfatório, se não atende às necessidades do usuário;
  • por que preocupar-se com ela: uma interface com uma usabilidade ruim, ou que não atenda às demandas de seus usuários, na web, os levará a abandonar o site em questão: há uma série de outras plataformas que podem lhes ajudar a resolver seus problemas e que estão concorrendo por sua atenção, afinal;
  • como melhorá-la: há diversas formas de fazê-lo, mas uma das mais básicas e funcionais são os testes de usabilidade, com usuários reais, observando como eles de fato interagem com o sistema;
  • quando trabalhá-la: ao longo de todo o projeto de construção ou reconstrução de um design, desde o início, de modo iterativo. Caso se trate de um redesign, deve-se primeiro testar a interface antiga, também, para entender o que funciona e o que não;
  • e onde realizar os testes: depende da frequência. Para projetos que realizam testes semanais, um laboratório de usabilidade pode ser bem vindo, mas em outros casos qualquer lugar em que seja possível sentar com um usuário e observá-lo usando o sistema sem distrações estará de bom tamanho.

Top 10 Mistakes in Web Design (2011) – O site do grupo Nielsen Norman tem várias listas – erros e boas práticas em design, bizarrices de UI mostradas em filmes, há de tudo. Esta é a lista dos piores erros já listados por outras listas deles, quando o assunto é web design. Estrelando:

  • Busca ruim – buscas que levam tudo ao pé da letra ou não encontram produtos, definitivamente, não cumprem seu propósito;
  • PDFs para leituras online – se o material é curto, transforme-o em uma página, PDFs não são o melhor em termos de usabilidade;
  • Não mudar a cor de links já visitados (ou destacá-los de algum modo) – o que deixa os usuários perdidos em relação a sua naveção pelo site;
  • Blocos de texto – ou texto não “escaneável: a escrita para plataformas online não é a mesma que para textos escritos – é importante adaptar-se para melhorar a legibilidade;
  • Tamanho fixo de fonte – não permitir que os usuários reescalem as fontes do site, além de ser ruim para a usabilidade e acessibilidade, eventualmente impedindo que usuários com problemas de visão acessem seu conteúdo, ainda é uma afronta do ponto de vista de tirar do usuário um controle que ele habitualmente tem, através dos comandos de seu navegador;
  • Títulos de página que ficam ruins em busca – eles precisam ser curtos e informativos, para fazerem sentidos nas (famosas) SERPs;
  • Colocar elementos que pareçam propaganda – as pessoas aprenderam a ignorar anúncios, então, evite que elas ignorem coisas importantes em sua página só porque parecem com propagandas;
  • Violar convenções de design – se há padrões ou convenções, além de haver um bom embasamento para tal, ocorre o simples fato de que vários lugares o estarão usando, então é bem provável que seus usuários já estarão acostumados com eles – e esperando que funcionem como devem!
  • Abrir novas abas no navegador – para Nielsen, a questão é simples: seus usuários estão acostumados a navegador entre conteúdos utilizando o recurso de “voltar” do navegador. Então, esperam ir para outra página ao clicar em um link. Se eles quiserem voltar para sua página, eles voltam. Eu, particularmente, sempre abro em nova aba. Até usava esse padrão aqui no blog, me senti sem jeito lendo as observações de Nielsen. Talvez pesquise algo mais a respeito, para ver se todos concordam com ele;
  • Não responder às questões e demandas dos usuários – não listar preços, valores ou funcionalidades, ter informações difíceis de encontrar, tudo isso leva os visitantes a: irem embora, procurarem o que querem em outro lugar. Caso se trate de um sistema que eles precisam usar, então o que ocorre é uma perda em produtividade. Ou seja, isso não é bom em caso algum.

10 Good Deeds in Web Design (1999) – Mais dez sugestões importantes de aspectos de design para sites, incluindo: como devem ser seus títulos, importância de haver sempre marca da empresa, melhor forma de exibir miniaturas de imagens de produtos, importância de oferecer uma busca.

Um aspecto dito em vários artigos online de Nielsen ou que o citam é a Lei de Jakob da Experiência de Usuário para a Web: os usuários passam a maior parte de seu tempo em outros sites. Assim, eles esperarão que o seu se comporte como a maioria dos lugares que visita.

58 dias: Design of search user interfaces

Hearst, Marti. Capítulo 1 – The Design of Search User Interfaces.

Destaques interessantes (perdoem, estou fazendo fichamentos aqui):

The job of the search user interface is to aid users in the expression of their information needs, in the formulation of their queries, in the understanding of their search results, and in keeping track of the progress of their information seeking efforts.

Some important reasons for the relative simplicity and unchanging nature of the standard Web search interface are:

  • Search is a means towards some other end, rather than a goal in itself. When a person is looking for information, they are usually engaged in some larger task, and do not want their flow of thought interrupted by an intrusive interface.
  • Related to the first point, search is a mentally intensive task. When a person reads text, they are focused on that task; it is not possible to read and to think about something else at the same time. Thus, the fewer distractions while reading, the more usable the interface.
  • Since nearly everyone who uses the Web uses search, the interface design must be understandable and appealing to a wide variety of users of all ages, cultures and backgrounds, applied to an enormous variety of information needs.

Although today’s standard search is a big improvement in usability over older command-line based Boolean systems, there is evidence that keyword querying is not initially intuitive. In fact, the literature suggests that people who are new to using search engines tend to start by asking a natural language question (Bilal, 2000Schacter et al., 1998). Novice searchers must learn to expect that a query will not yield immediately usable results, and that they must scan search results lists, navigate through Web sites and read through Web pages to try to find the information they seek. A study by Pollock and Hockley, 1997 found that, for novice searchers, the notion of iterative searching was unfamiliar. Some study participants assumed that if their first attempt failed then either they were incapable of searching or the system did not contain information relevant to their interest.

“The job of the search user interface is to aid users in the expression of their information needs, in the formulation of their queries, in the understanding of their search results, and in keeping track of the progress of their information seeking efforts.” “An important quality of a user interface (UI) is its usability, a term which refers to those properties of the interface that determine how easy it is to use. Shneiderman and Plaisant, 2004 identify five components of usability, restated by Nielsen, 2003b as:”

  • Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the interface?
  • Efficiency: How quickly can users accomplish their tasks after they learn how to use the interface?
  • Memorability: After a period of non-use, how long does it take users to reestablish proficiency?
  • Errors: How many errors do users make, how severe are these errors, and how easy is it for users to recover from these errors?
  • Satisfaction: How pleasant or satisfying is it to use the interface?

Serra, Raquel cita as mesmas.

In user-centered design, decisions are made based on responses obtained from target users of the system.

Needs assessment; task analysis; scenarios.

There are usually several good solutions within the interface design space, and the task of the designers is to navigate through the design space until reaching some “local optimum.” The iterative process allows study participants to help the designers make decisions about which paths to explore in that space. Experienced designers often can begin the design near a good part of the solution space; less experienced designers need to do more exploration. Designing for an entirely novel interaction paradigm often requires more iteration and experimentation. Evaluation is part of every cycle of the user-centered design process.

Hearst cita um artigo de Nielsen de 1989 em que ele apresenta a ideia de tais testes de usabilidade feitos com poucos usuários. Pesquisei e encontrei dois artigos mais recentes de Nielsen em que ele discute tal ideia, acho que vale a pena lê-los:

Discount usability for the web (1997)

Discount Usability: 20 Years (2009)

Shneiderman et al., 1997 specifies eight design desiderata for search user interfaces generally (re-ordered below):

  • Offer informative feedback.
  • Support user control.
  • Reduce short-term memory load.
  • Provide shortcuts for skilled users.
  • Reduce errors; offer simple error handling.
  • Strive for consistency.
  • Permit easy reversal of actions.
  • Design for closure.

Detalhamento desses pontos:

Because the search task is so cognitively intensive, feedback about query formulation, about the reasons the particular results were retrieved, and about next steps to be taken is critically important.

  • Offer efficient and informative feedback
    • show search results immediately – at least a few initial results should be shown. This helps searchers understand if they are on the right track or not, and also provides them with suggestions of related words that they might use for query reformulation. Many experimental systems make the mistake of requiring the user to look at large amounts of helper information, such as query refinement suggestions or category labels, before viewing results directly.
    • show informative document surrogates; highlight query terms – information about the document and why it was retrieved, such as the title, the URL, and a textual summary; this information is referred to as the document surrogate. (…) An important form of feedback in search results listings is to include the terms from the query in the document surrogates in order to show how the retrieved document relates to the concepts expressed in the query. (…) Research shows that summaries are most informative if they contain the query terms shown in their context from the document (Tombros and Sanderson, 1998White et al., 2003a). […] Term highlighting refers to altering the appearance of portions of text in order to make them more visually salient, or “eye-catching” (…) This helps draw the searcher’s attention to the parts of the document most likely to be relevant to the query, and to show how closely the query terms appear to one another in the text. However, it is important not to highlight too many terms, as the positive effects of highlighting will be lost (Kickmeier and Albert, 2003). […] There is an inherent tradeoff between showing long, informative summaries and minimizing the screen space required by each search hit. ((Ela diz isso, mas não entra em mais detalhes, nem cita fontes. Entretanto, sinto a mesma coisa em relação ao fazDelivery, mesmo como usuária: gostaria de ver mais resultados de uma única vez.)). Hearst cita o BioText para mostrar uma interface de document surrogate rica. Tive duas ideias para a interface do FD a partir disto – tornar a expansão da descrição de cada item opcional; e mostrar sugestão de termos para busca – podem ser termos mais populares ou que queiramos destacar;
    • allow sorting of results by various criteria – Como esta é a parte que mais me interessa, e ela fala pouco, copio todo o trecho (grifos meus): Another effective form of feedback in the display of search results allows for the dynamic sorting of search results according to different ranking criteria (e.g., recency, relevance, author, price, etc.). An effective interface for displaying results sortable along several dimensions at once uses a sortable columns format, as seen in email search interfaces, some product search, and some bibliographic search (see Figure 1.3). With this view, users can sort results according to different criteria, while being able to visually compare those criteria, because the changes are directly visible (Reiterer et al., 2000Cutrell et al., 2006b). This kind of view is typically more effective than showing choices hidden behind drop-down menus. Grouping search results by categories is also an effective form of feedback, as discussed in the section below on integrating navigation and search.;
    • Show query term suggestions – ela fala muito em sugestões para refinar busca, tanto dinâmicas quanto pós busca realizada. Não sei quanto poderei fazer isso com o fazDelivery, já que não pretendo mexer no algoritmo do motor de busca em si, mas talvez seja um bom trabalho futuro incluir algo do gênero;
    • Use relevance indicators sparingly – no geral, a ordem vertical de aparecimento dos resultados já passa ao usuário uma boa ideia de relevância de documentos, de modo que é bom ser cuidadoso com outros tipos de indicadores de relevância (e, em especial, com o entendimento que usuários farão deles). Por outro lado, informações visuais sobre avaliações de outros usuários – como estrelas – podem ser úteis.
    • Support rapid response – para sistemas de propósito geral, especialmente quando há sugestões dinâmicas, busca exploratória e muita interação, é importante que o tempo de resposta seja curto, permitindo ao usuário fazer mais buscas até se aproximar dos resultados desejados, por exemplo, sem interromper o fluxo de pensamentos do usuário enquanto ele faz sua pesquisa. Por outro lado, para sistemas mais especializados, em que normalmente o resultado final já é a resposta desejada pelo o usuário, este se mostra mais disposto a esperar. Neste caso, é importante, entretanto, dar algum tipo de feedback que indique que o sistema está processando a requisição feita.
  • Balance user control with automated actions – há dois aspectos que se relacionam mais fortemente com esse balanço:
    • Rank ordering in web search (ordenamento de resultados em buscas feitas na web) – torna-se difícil exigir que os usuários entendam em detalhes o funcionamento de um motor de buscas, para que possam calibrar suas opções de acordo com suas necessidades. Nesse caso talvez o fazDelivery esteja até bem, pois, por se tratar de uma coleção mais específica, é mais fácil entender os pesos do que é relevante – e.g., peso, distância, tempo de entrega. Ainda assim, atualmente a apresentação de tais filtros de reordenamento não está muito boa.
    • Query transformations –  Hearst discute a questão das adaptações aos termos de consulta feitas automaticamente pelos motores de busca. Elas costumas ajudar, (…) But if the system consistently overrules the user’s intention, the user may become justifiably frustrated. — Ainda assim, como aqui provavelmente entraria um caso de mexer no motor da busca em si, não devo trabalhar com este ponto.
  • Reduce short-term memory load
    • Suggest the search action in the entry form – esta é uma prática que nem sempre funciona bem no design de formulários extensos (especialmente quando se omite títulos dos campos, substituindo-se pelos termos escritos em seus próprios campos – mais detalhes em vários links na internet, como neste da Pardot: Placeholders are not Substitutes for Labels), mas que pode funcionar bem
    • Support simple history mechanisms – mostrar pesquisas recentes ou páginas recentemente visitadas, por exemplo, é uma forma de auxiliar isto
    • Integrate navigation and search – A well-established principle of human memory is that it is often easier to recognize a word or name than it is to think up that word. (…) Browsable information structures, such as links on a Web site or a table of contents for a book, give an overview of the contents of a collection, allowing the searcher to navigate to the information of interest by following links or narrowing by selecting categories. Information structures can also impose an organization on the results of search. To be fully effective, navigation interfaces should allow the user to interleave keyword queries within existing information structures, smoothly integrating navigation with search. This means that after a keyword search, results should be organized into the navigation structure, and that after navigation steps, keyword search should be available over the current subset of information items. [categories] can also be used for ordering and sorting search results. Hearst também cita a navegação por categorias multifacetadas como um bom approach para dar um bom controle e refinamento para os usuários, mas não sei se conseguiria implementar algo assim para o fazdelivery trabalhando apenas do ponto de vista da interface…
  • Provide shortcuts
    • Além dos tradicionais atalhos de teclado, para buscas são comuns outras formas de atalhos, por assim dizer, como mostrar outros sub-domínios para links mostrados entre os resultados, ou, por exemplo, no caso do fazDelivery, quando sugerimos diretamente um estabelecimento, quando o termo buscado coincide com o nome do mesmo. In a sense, this kind of intention prediction is a form of shortcut, eliminating the need for the user to know precisely how to specify a command, and also reducing the need to navigate to external Web pages to find the desired information.
  • Reduce errors
    • Avoid empty results sets – uma forma de evitar isto é prover previsão de resultados para consultas (por exemplo, no caso das navegações multifacetadas, funciona bem), ou oferecer sugestão de correção para termos escritos erroneamente.
    • Address the vocabulary problem – Hearst explica que um estudo feito por Furnas apontou que, para pessoas dentro de uma mesma área de atuação, objetos ou tarefas comuns têm uma probabilidade bastante pequenas de serem nomeados da mesma forma. Isto significa que o autor de um determinado documento ou site pode não usar os mesmos termos para se referir ao seu conteúdo que a pessoa buscando por ele. Expansão de termo (term expansion), no caso de buscas, e card sorting para escolha de “rótulos” para ícones, categorias e botões podem ser técnicas úteis para endereçar tal problema.
  • Recognize the importance of small details – coisas como tamanho de frases de dicas ou sugestões ou pré-concepções acerca do funcionamento da busca podem alterar muito como os usuários entendem e reagem a uma busca. Por exemplo, quando a sugestão para termos escritos incorretamente do google era muito grande, poucas pessoas a notavam. Também observa-se que, atualmente, as pessoas naturalmente esperam que os primeiros resultados retornados sejam mais relevantes para sua consulta.
  • Recognize the importance of aesthetics in design – vários estudos sugerem que as pessoas tendem a ter uma melhor experiência com interfaces que são melhor planejadas esteticamente, tanto do ponto de vista de satisfação com interface quanto em relação a tempo para realização das buscas ou avaliação da relevância dos resultados: “Nakarada-Kordic and Lobb, 2005 report that viewers persevere longer in a search task on Web sites whose design appeals to them.”

Diretrizes importantes, exemplos úteis e uma série que referências, que ainda me levaram para outros lugares. Anotei algumas ideias para trabalhos futuros ou para a interface do fazDelivery em si – ou que creio que já fazemos de um modo legal. Acho que destaquei coisa demais e tenho medo de só me basear em Hearst, mas é uma leitura que vale a pena para quem quer começar a mexer com interfaces de busca.