O preço da boa legibilidade | Arquitetura de Informação

O preço da boa legibilidade

Posted on outubro 1, 2010 by Fabricio Teixeira

As placas de ruas da cidade de Nova Iorque serão trocadas de caixa alta para caixa baixa.

Estudos mostraram que é mais difícil ler placas em caixa alta, e que esses milisegundos gastos olhando para fora da rua aumentam as chances de acontecer acidentes – especialmente entre os motoristas mais velhos.

“Mudar de BROADWAY para Broadway salvará vidas”, afirma a nova versão do Manual on Uniform Traffic Control Devices.

O tipo utilizado nas placas também mudou para o Clearview, uma fonte especialmente desenhada para esse propósito.

“These new and updated standards will help make our nation’s roads and bridges safer for drivers, construction workers and pedestrians alike.”, afirma o Secretário de Transportes da cidade.

O custo? US$110 por placa, US$ 27 milhões para toda a cidade.

viaO preço da boa legibilidade | Arquitetura de Informação.

Frustração catalogável | Arquitetura de Informação

Frustração catalogável

Posted on setembro 28, 2010 by Fabricio Teixeira

A caixa de buscas do Google é um universo à parte no que tange ao comportamento do usuário. Há algum tempo ela deixou de ser apenas um campo texto e passou a representar o ponto de partida de grande parte das tarefas realizadas na web. Com o tempo, passou a corrigir erros ortográficos, sugerir buscas relacionadas e – com o recente Google Instant – inclusive prever o que você está digitando.

Ainda assim, a busca do Google não está isenta de causar frustração nos usuários.

Usuária loucamente frustrada.

Agora imagine um mecanismo de busca que detecte essa frustação em tempo real e já sugira uma solução para o problema. É isso que o time de User Experience do Google vem tentando fazer e compartilha em seu blog.

“We gave users search tasks, some of which we knew to be difficult. The first couple of searches always looked pretty much the same independent of task difficulty: users formulated a query, quickly scanned the results and either clicked on a result or refined the query. However, after a couple of unsuccessful searches, we started noticing interesting changes in behavior. In addition to many of them sighing or starting to bite their nails, users sometimes started to type their searches as natural language questions, they sometimes spent a very long time simply staring at the results page, and they sometimes completely changed their approach to the task.”

Segundo o Google, além de mudanças faciais e corporais nos usuários que estão com dificuldades, ocorrem mudanças também na navegação.

“…those signals were: use of question queries, use of advanced operators, spending more time on the search results page, formulating the longest query in the middle of the session, and spending a larger proportion of the time on the search results page.”

Esses são os primeiros sinais de que sim, é possível que, no futuro, o computador identifique que o usuário está tendo dificuldades. É como se a frustração pudesse ser “catalogada” e identificada por uma inteligência artificial.

Sabemos que esse tipo de pesquisa monitorada (ou teste de usabilidade) é fundamental para que uma empresa tente entender melhor como as pessoas se comportam ao utilizar determinado serviço. Mas para o Google esse tipo de resultado deve ter um sabor especial.

Afinal, como ser inovador em um serviço que já está bem estabelecido e que as pessoas já sabem utilizar? Como evoluir a busca, que já é um processo tão simples, sem torná-lo complicado demais?

Não tem momento melhor para extrair esses insights do que ao observar pessoas.

viaFrustração catalogável | Arquitetura de Informação.

O tempo que se perde perdendo tempo | Arquitetura de Informação

O tempo que se perde perdendo tempo

Posted on fevereiro 22, 2010 by Fabricio Teixeira

Esse é o nome de uma nova série de vídeos que a revista Superinteressante lançou esses dias em seu canal no YouTube. Nos vídeos, um cronômetro mostra quanto tempo perdemos em pequenas tarefas rotineiras que, somadas, acabam tomando um tempo considerável do nosso dia. Interessante que muitos dos exemplos têm ligação direta com a usabilidade do objeto, interface ou sistema que foi desenhado.

Ainda hoje li um artigo do Marco Gomes no Webinsider que questionava o quanto a evolução dos gadgets os transformou em objetos complicados e muitas vezes prolixos. O artigo cita exemplos de gadgets que, ao adquirirem novas funcionalidades, foram ganhando também novos botões, atalhos e funcionalidades que acabaram deixando de lado a simplicidade de uso que possuíam em sua essência.

Segundo Marco Gomes: “Quem treme um pouco ou não enxerga bem não pode usar este aparelho.”

Um dos exemplos do artigo é o dos telefones. “Havia um disco, você tirava o fone do gancho, girava o disco na sequência de discagem, a ligação acontecia. Hoje precisamos desbloquear o aparelho e abrir a aplicação ‘telefone’. Muitas vezes nos digladiamos com um touch-screen que nem sempre se comporta como esperamos. Além disso, é preciso ter muito cuidado para não interromper a ligação ao esbarrar em microbotõezinhos escondidos em todos os lados.”

O caixa eletrônico do meu banco, por exemplo, sempre pede que eu insira e retire o cartão para iniciar. Só depois disso é que a máquina percebe que meu cartão possui chip e pede que eu o insira novamente e mantenha na leitora para continuar. Oi?

Quanto tempo estamos fazendo nossos usuários perderem? Será que estamos observando corretamente o contexto de uso de nossas aplicações?

Ou ainda, como questiona Marco Gomes em seu artigo: “Estamos ficando mais estúpidos pra projetar as interfaces do dia-a-dia?”

viaO tempo que se perde perdendo tempo | Arquitetura de Informação.

Lições de teatro aplicadas ao desenvolvimento de sites | Arquitetura de Informação

Lições de teatro aplicadas ao desenvolvimento de sites

Posted on março 25, 2010 by Fabricio Teixeira

Li ontem um artigo cujo título me chamou a atenção: 5 Lessons From Theatre You Can Apply to Web Site Design. Isso porque nas horas vagas participo de um grupo de teatro amador aqui em São Paulo, e porque já há algum tempo havia traçado esses mesmos paralelos que a autora – mas nunca me empenhado em documentá-los. Adaptei abaixo essas 5 lições e incluí mais algumas.

É um trabalho coletivo.

Para colocar o espetáculo (ou um site) de pé, é preciso de um time inteiro. Claro que existem todos os atores, mas existem também os músicos, iluminadores, bilheteiros, diretor etc. No palco você aprende a dar valor a cada uma dessas funções com o mesmo peso. A quantidade é importante. Grandes projetos raramente ficam prontos quando dependem de uma pessoa só. E mais: todo o charme está justamente em ser um trabalho coletivo. Um grande time gosta de ser um grande time.

É preciso distribuir bem os papéis.

Cada pessoa ali tem sua habilidade. Uns são afinados cantores, outros são talentosos atores, outros dançam esplendidamente. Essa pluralidade é essencial. Saber explorar o melhor de cada um, mais ainda. Não adianta o grupo possuir dez excelentes cantores, se durante o espetáculos eles apenas dançam. Não adianta um projeto contar com os melhores designers do mundo, se eles são obrigados a gastar tempo programando ou redigindo textos.

Você vai precisar de um diretor.

Por mais talentoso que seja o elenco, é preciso ter alguém que desça do palco e enxergue o espetáculo lá de fora – tendo sempre em mente o objetivo inicial daquilo tudo. É importante ter alguém que se distancie do furor do palco e garanta que o público está vendo aquilo que realmente quer ver. É comum o elenco se apaixonar pelo projeto e fechar os olhos para erros e inconsistências que não são visíveis pelo lado de dentro.

Você vai precisar de uma data de estreia.

O bom dos espetáculos é que eles têm uma data de estreia. Não dá para adiar, porque os convites são vendidos antecipadamente. Esteja bom ou ruim, o espetáculo estreia no mesmo dia, e a repercussão da peça é impactada diretamente pelo desempenho dessa primeira sessão. Se a plateia sai da estreia com uma boa impressão, compartilhará espontaneamente a experiência com outras pessoas, que preencherão as poltronas das sessões subsequentes. Se a impressão não for boa, nada feito.

Ensaios e mais ensaios.

A primeira noite de ensaios é terrível. A qualidade não chega nem perto daquela que é apresentada no dia da estreia. Muita coisa muda no meio do caminho. Muitas cenas são cortadas, muitos diálogos são simplificados, muitas músicas ganham novas versões e muitas coreografias são aperfeiçoadas. Nada disso é possível sem muito ensaio. O ensaio é importante para que todos saibam de tudo o que está sendo mudado na peça. Por mais que o assistente de direção se empenhe em documentar as mudanças no roteiro, há coisas que são “indocumentáveis”. Se alguém falta ao ensaio, certamente fica defasado.

O importante é ter convicção.

No palco, ao errar uma fala, erre com convicção. Nem a plateia (e nem o usuário) sabem como era a frase original que você deveria ter dito de acordo com o roteiro. Ele nem sabe que você errou. O importante é manter a coerência naquilo que está sendo dito. No palco, aprende-se que existem infinitas maneiras de se dizer a mesma coisa. Inclusive não só com palavras.

Um ator só é aplaudido porque os outros atores prepararam o terreno para isso.

Uma cena, por si só, não ganha o espetáculo. Somente quando o espectador imerge em uma sucessão de boas cenas é que ele se encanta a ponto de aplaudir a próxima cena. Mas o mérito não é dos atores da cena que foi aplaudida, e sim de todos os outros que vieram antes e que prepararam o terreno para aqueles aplausos. No trabalho de desenvolvimento de sites é a mesma coisa: um bom design não ganha aplausos sozinho, se antes dele não houve uma bom trabalho de arquitetura de informação e usabilidade. Uma animação em flash, por mais incrível que seja, não funciona bem se o processamento do site está baleiando. Por isso, ao sair do palco, agradeça os elogios e divida-os por 30, ou mais.

Perder o carisma é algo irrecuperável, cá ou lá.

No palco, uma cena mal apresentada é suficiente para deixar o espectador decepcionado. Em um site, um link que não funciona ou um simples erro ortográfico podem fazer o usuário esquecer tudo de bom que você já apresentou para ele. Por isso é preciso ter atenção a todos os detalhes – e isso não é só uma frase de efeito.

É isso. Alguns pontos são um tanto óbvios, mas nem por isso menos importantes. Procurar links entre o que você faz dentro e fora do trabalho é um exercício bem interessante. Se alguém mais tentou fazer isso, conte na caixa de comentários =]

viaLições de teatro aplicadas ao desenvolvimento de sites | Arquitetura de Informação.

O cliente dos sonhos | Arquitetura de Informação

O cliente dos sonhos

Posted on setembro 26, 2008 by Silvia Melo

Achei interessante essa tirinha da POPsickleSTRIP que a Elisa Volpato mandou por e-mail hoje cedo. O personagem descreve o cliente dos sonhos. Entre outras coisas, ele paga adiantado, entende as limitações técnicas e deixa a criatividade para o desenvolvedor.

Fiquei pensando nisso e acho que todos acabamos tendo um ideal de cliente, não? O meu, por exemplo, planeja as ações com antecedência, conhece as necessidades de seu consumidor e gosta de testar soluções. Além de trabalhar junto com o time de desenvolvedores também é um bom ouvinte e sabe o que é um prazo justo para o projeto.

E para você, como é o cliente dos sonhos?

viaO cliente dos sonhos | Arquitetura de Informação.

O excesso de informação para o bem ou para o mal | Arquitetura de Informação

O excesso de informação para o bem ou para o mal

Posted on setembro 14, 2009 by Fabricio Teixeira

Dois infográficos de fontes diferentes chamaram minha atenção essa semana. Apesar do formato similar dos dois gráficos, eles trazem óticas bastante distintas sobre a mudança de comportamento do novo consumidor digital.

O primeiro deles, publicado pela Wired, mostra como o consumidor está lidando com a nova “dieta de consumo de mídia” dentro das 24 horas de seu dia. Segundo o artigo, tão importante quanto manter uma alimentação balanceada ao longo do dia, é manter um consumo saudável de mídia, mesclando quantidade e qualidade de informações e percorrendo diferentes telas. O excesso de informação aqui é controlado, diversificado, producente.

A dieta de mídia no novo consumidor digital

O segundo gráfico, publicado no Information is Beautiful, hierarquiza em diferentes níveis as distrações digitais às quais estamos sujeitos ao longo do dia, e mostra como o acúmulo de alertas acaba nos distanciando das tarefas que realmente precisamos executar.

Hierarquia das distrações digitais

Ao mesmo tempo em que o excesso do consumo de mídia permite aos AIs explorarem novas plataformas, novas interfaces e novas situações de consumo, também exige que tudo seja projetado com cautela redobrada. A quantidade de distrações é perturbadora. Foi-se o tempo onde o usuário navegava em seu site sujeito a ruídos apenas externos ao digital. O ruído agora está na própria máquina e vem do próprio usuário. Navegação multi-abas, plugins nos navegadores, alertas de aplicativos e notificações de redes sociais – além dos gadgets que ficam sempre à mesa, vibrando e apitando freneticamente ao longo do dia. Quantas vezes você já não se pegou com o browser aberto tentando lembrar o que iria fazer?

viaO excesso de informação para o bem ou para o mal | Arquitetura de Informação.

O lorem ipsum pode atrapalhar sua vida | Arquitetura de Informação

O lorem ipsum pode atrapalhar sua vida

Posted on maio 13, 2010 by Fabricio Teixeira

Esses dias li mais um daqueles artigos que criticam o uso do lorem ipsum e mostram exemplos de como os textos de marcação podem comprometer a implementação de determinada tela.

Segundo o artigo, quando usamos lorem ipsum perdemos a referência da quantidade de texto necessária para explicar uma ideia. Este artigo de Thomas Baekdal dá um ótimo exemplo de mau uso do lorem ipsum.

Vejam como fica a tela:

1. No fantasioso mundo do lorem ipsum

2. Na hora em que o conteúdo real é aplicado

3. Depois daquela gambiarra feita de última hora

Se pensarmos apenas na praticidade e na questão estética, realmente o lorem ipsum é a melhor solução. É rápido, visualmente muito próximo de um texto real em português e excelente quando não se tem ideia de qual será o conteúdo final do site. Mas em projetos onde o conteúdo é o protagonista, não dá pra confiar plenamente no “olhômetro” na hora de reservar o espaço para o texto.

By adding Lorem Ipsum to the design you are essentially dressing your king before you know his size.

(daqui)

Mas então, o que fazer?

Cada um tem sua opinião sobre o tal lorem ipsum. Pelo sim, pelo não, ficam aqui algumas recomendações baseadas em experiências anteriores:

Escreva textos reais

Em 10 minutos você escreve alguns bons parágrafos sobre o assunto que aparecerá na página. Não é difícil. Primeiro porque você já está com o assunto na cabeça. Segundo porque o texto não precisa ser bonito, consistente, gramaticalmente revisado e nem conter rimas ricas e/ou preciosas. E claro, você sempre pode usar uma ou duas linhas de lorem ipsum quando der aquela travada.

Dê três exemplos diferentes

Se o template que você está desenhando conterá um texto dinâmico, vale a pena gastar mais uns 15 minutos e criar outros exemplos de aplicação de texto. Se está desenhando uma página de notícias, escreva três exemplos distintos, com tamanhos diferentes entre si e com variações nos conteúdos multimídia.

Seja sincero

Porque convenhamos, é fácil roubar no jogo e fingir que todas as notícias do seu portal terão três parágrafos de quatro linhas cada. E que todas terão duas imagens horizontais de 500 pixels de largura. Então é melhor ser sincero com você mesmo e com sua equipe de desenvolvimento e já prever, logo de cara, os cenários mais absurdos possíveis.

Acompanhe o trabalho do redator

Nas páginas onde o texto é estático, normalmente haverá um redator responsável em escrevê-lo. Além de conversar com ele antes de fazer o wireframe (se isso for possível), acompanhe-o durante e depois do texto ser escrito. É muito comum que o redator estenda o seu lorem ipsum em duas linhas, o revisor em mais duas e que o programador de interface quebre as linhas 15 pixels antes do que você estava imaginando. O resultado pode ser problemático – tanto visualmente quanto pelo excesso de conteúdo nas telas onde você sabe que o usuário não terá vontade de ler.

Faça ajustes

Não tenha receio de ajustar depois de pronto. Quando o arquiteto de informação está próximo do time de desenvolvimento, fica fácil identificar telas problemáticas e corrigi-las antes de entrar no ar – ou mesmo depois. É melhor correr para ajustar de última hora do que ficar com aquela aberração no ar. Fora que já vi (e já ouvi muita gente dizer que viu) sites publicados com lorem ipsum, seja por distração ou por desespero.

Um dos motivos para o lorem ipsum ser usado há décadas nas publicações impressas é porque lá é mais fácil saber quanto conteúdo cabe em uma página e também porque o hábito do consumidor é outro. Em geral, na internet lê-se menos, com menos atenção e com mais pressa. Sempre que possível eu deixo o lorem ipsum de lado e treino o meu lado redator. Você valoriza o trabalho, apresenta uma tela mais realista para o cliente e ainda evita os problemas de implementação. Uma pena que nem sempre é possível.

viaO lorem ipsum pode atrapalhar sua vida | Arquitetura de Informação.

Testes de usabilidade custam basicamente nada | Arquitetura de Informação

Testes de usabilidade custam basicamente nada

Posted on janeiro 11, 2010 by Fabricio Teixeira

Li esses dias uma entrevista de Jared Spool, CEO da User Interface Engineering e co-autor de alguns livros sobre User Experience e Testes de Usabilidade. Em uma de suas respostas, Spool explica que testes de usabilidade são mais baratos e simples de serem feitos do que se imagina.

Traduzi abaixo a pergunta de Russell Wilson e a resposta de Spool:

Alguns times de desenvolvedores parecem procurar por formas mais baratas e rápidas de validarem seu design. Usabilidade é frequentemente percebida como sendo muito cara. Você acha que os testes de usabilidade devem ser barateados? Perguntando melhor: teste de usabilidade, hot or not?

Um teste de usabilidade, em sua forma mais básica, custa basicamente nada. É um processo simples. Você senta do lado de alguém e o assiste experimentando seu design.

Qualquer custo adicional vem da tentativa de adicionar rigor ao processo. Rigor não precisa ser caro, mas pode ser caro.

Pense que é como pintar uma casa. Uma pessoa pode fazer tudo praticamente sozinha, economizando uma boa quantia, mas provavelmente isso vai tomar muito tempo e, sem as ferramentas adequadas, ela não vai produzir um resultado de alta qualidade. Mas vai ter pintado a casa.

A questão é quanto valem o tempo e a qualidade. Há uma relação entre quanto você investe e a qualidade e velocidade que você vai ter de volta. Compre uma escada, uns pincéis e rolos de melhor qualidade, tintas melhores e peça a ajuda de algum estudante colegial desempregado, e você terá uma pintura melhor em sua casa.

A mesma coisa acontece com testes de usabilidade. Investimentos inteligentes aumentam a qualidade.

Mas há uma coisa que difere de pintar uma casa: pode ser um erro contratar alguém para testar para você.

O principal benefício de qualquer projeto de teste de usabilidade não é o relatório de recomendações que é entregue no final. Nossa pesquisa mostra que o benefício é a exposição que o time tem ao observar usuários reais utilizando seu design. Quanto maior essa exposição, melhores são os produtos entregues.

Se você contrata alguém para fazer o seu teste, bem, é mais ou menos como contratar alguém para curtir suas férias – a tarefa é feita, mas você perde a melhor parte.

Então, o maior investimento em testes de usabilidade não é o dinheiro – que até pode ser não muito caro. É o tempo. Nossa pesquisa mostra que as equipes das organizações mais eficazes gastam pelo menos duas horas a cada seis semanas observando usuários interagirem com seus projetos. Cada membro da equipe.

E a experiência se paga muito rapidamente. O time agora sabe como é usar o design. Eles sabem quais mudanças tiveram o impacto que eles esperavam, e quais delas nem foram notadas. E eles vêem como alguns problemas pequenos e irritantes podem arruinar soluções consideradas inovadoras.

É muito barato começar a praticar testes – se a dúvida é fazer ou não o investimento.

Agora, se você estiver preocupado com os gastos, eu recomendo que você faça um produto realmente de baixa qualidade. Sempre haverá uma solução mais barata. (E é interessante observar que se você quiser realmente fazer um produto de baixa qualidade, você consegue fazer muito rapidamente, também.)

Muito bacana a metáfora que Jared fez sobre a pintura da casa. Aqui na agência temos investido bastante em testes caseiros e mais frequentes, seja com recrutamento de um perfil específico de público-alvo, seja com o colega do lado. Recentemente desenvolvemos um aplicativo de iPhone em que perdi a conta do número de testes de usabilidade que foram feitos com o próprio time da agência, além dos testes que o próprio desenvolvedor fazia para assegurar a estabilidade do aplicativo. No fim, a troca de experiências entre esses dois tipos de teste foi riquíssima, e não custou nada mais do que algumas horas e um pouco de bom senso.

É claro que para determinados tipos de projeto a contratação de especialistas dedicados é indispensável. Mas quando os custos inviabilizam o projeto de testes, o jeito é improvisar. Como bem concluiu a Silvia em nossa última apresentação no Ebai: “Qualquer pesquisa é melhor do que nenhuma pesquisa”.

A entrevista completa de Jared Spool está publicada no UI Trends.

viaTestes de usabilidade custam basicamente nada | Arquitetura de Informação.