Wd :: Dos conceitos tradicionais formulados nos primórdios da internet comercial por especialistas como Steve Krug, “nada importante deve estar a mais de dois cliques de distância”, e Jakob Nielsen, “o conteúdo é o rei”, o que ainda podemos considerar válido, o que foi transformado e o que caiu em desuso, em sua opinião?

Fred :: Jakob Nielsen e Steve Krug ficaram famosos na época em que a bolha econômica da internet estava estourando. Ninguém sabia bem porque os negócios não estavam dando certo.

Nielsen e Krug argumentaram que o problema era na interface com o usuário. Apresentaram uma série de critérios e regras de usabilidade que substituíam qualquer reflexão mais complexa acerca do design destas interfaces. Bastava seguir suas recomendações e tudo estava resolvido.

Muitos desenvolvedores foram seduzidos pelo messianismo da usabilidade e tomaram as recomendações como dogmas. Era mais fácil acreditar no discurso simplista da usabilidade do que encarar a complexidade do design. Hoje, podemos notar um retorno ao interesse pelo design, não como um mero aspecto visual, mas como o balanceamento dos múltiplos aspectos de um produto, incluindo a própria usabilidade.

Wd :: No artigo “Keys to E-Commerce Success”, ficamos sabendo que “não encontrar o que procura” (34%) e “problemas de navegação/usabilidade” (13%) ainda são alguns dos principais obstáculos que dificultam a realização de compras em sites de comércio eletrônico, segundo pesquisa realizada entre abril e junho de 2009, com usuários pelo mundo. Pensando nisso, quais são os desafios para incluir a usabilidade como diretriz de negócios e estratégias em projetos digitais?

Fred :: O problema principal das lojas de comércio eletrônico hoje é que elas são projetadas mais pelos princípios da informática do que pelos princípios de vendas. A experiência de compra das lojas virtuais parece-se mais com a de softwares de automação comercial do que com a de lojas físicas. Não se trata de imitar o espaço físico, mas de aproveitar as estratégias de interação que funcionam. O velho bordão do “cliente sempre tem razão” foi esquecido.

Nas lojas virtuais, se você digita o nome de um produto diferente do que foi cadastrado, a loja geralmente não mostra nada. Se você pedir numa loja física, o vendedor não só dá um jeito de descobrir o que você busca, como passa a usar o seu linguajar para se referir ao produto.

Isso não é difícil de fazer num sistema de loja virtual, porém, é preciso conhecer estes princípios. Sonho com o dia em que o comércio eletrônico não será mais considerado como uma opção de menor custo, mas sim como uma opção de maior comodidade e prazer.

Wd :: Ainda é muito comum alguns profissionais confundirem o significado, ou até mesmo usarem como sinônimo, usabilidade e funcionalidade. Pela sua experiência, como podemos definir estes conceitos e quais são as principais diferenças entre eles?

Fred :: Funcionalidade é o que pode acontecer. Usabilidade é o que de fato acontece. Um determinado produto pode ter milhares de funcionalidades que ninguém usa, ou porque são inúteis ou porque estão escondidas. Essa estratégia de colocar todas as funcionalidades possíveis num produto é tão comum em tecnologia da informação quanto sua própria ineficiência. O produto perde personalidade e se torna mais um genérico multifuncional. Falta design, que serve justamente para priorizar o que de fato é importante para o usuário.

Wd :: Segundo o professor Robson Santos, no artigo “Alguns conceitos para avaliar usabilidade”, “efetividade, eficiência e satisfação são as medidas de usabilidade mais freqüentemente consideradas em relação à websites”. Como estes conceitos devem ser aplicados no processo de produção do designer de interfaces?

Fred :: É importante que os critérios tradicionais de usabilidade (eficiência, eficácia e satisfação) não sejam os únicos. A usabilidade deve estar alinhada à proposta de experiência como um todo. Isso significa que, em alguns casos, os critérios tradicionais podem ser relativizados ou mesmo ignorados. Que relevância tem a eficiência de uma interface voltada ao entretenimento? Na outra ponta, como a satisfação do usuário pode ser mais importante do que sua segurança num Internet Banking?

Wd :: Na edição de abril de 2009, apresentamos uma entrevista com Yasodara Córdova, pesquisadora de IHC e web design ágil, que analisava os efeitos da aplicação das metodologias ágeis no design de interfaces. Segundo ela, “o designer precisa pensar cada vez mais em construir respostas para os problemas dos usuários (sejam usuários de geladeiras, carros, computadores, celulares etc.) da maneira mais ágil e barata, com a melhor qualidade”. Diante disso, quais transformações que estas metodologias podem trazer para a aplicação dos conceitos de usabilidade em projetos digitais e interativos?

Fred :: As metodologias ágeis ressaltam um aspecto importante para a usabilidade: a avaliação continuada. O problema é que nem sempre os critérios de usabilidade são levados em consideração nos testes. É preciso validar com usuários para garantir que o projeto vai atender às suas expectativas. Existem diversos métodos de pesquisas com usuários que são rápidos e baratos o suficiente para serem encaixados em metodologias ágeis.

Wd :: Em chat realizado no curso “Web para designers”, você levantou uma questão interessante durante o bate-papo: “se o cliente pede algo que você sabe que vai prejudicar a usabilidade, o que você faz?”. Nestes momentos, o que o profissional deve fazer e como ele deve se posicionar para não prejudicar a usabilidade do projeto?

Fred :: Esta é uma excelente oportunidade para o designer mostrar que seu trabalho é baseado em algo mais do que na inspiração pessoal. O cliente precisa perceber que a visão do designer vai além do senso-comum para respeitar seu trabalho.

Nesta situação, o profissional pode apresentar todas as pesquisas e dados que sustentaram suas decisões: livros, websites e artigos que serviram de fontes de referência. Porém, as provas mais contundentes aparecem em testes de usabilidade. Numa situação crítica, vale à pena rodar um teste de usabilidade experimental só para verificar a questão.

Wd :: Outro assunto pertinente discutido neste chat envolveu a questão cultural na aplicação dos conceitos de usabilidade. A dúvida é: ela deve ser trabalhada de outra forma em culturas diferentes ou existe um conceito universal?

Fred :: Assim como varia a forma como pessoas de diferentes países usam alimentos e roupas, varia também a forma como as pessoas usam softwares e websites. Porém, como estas ferramentas são frequentemente criadas com o intuito de padronizar determinadas atividades, existe certa universalidade de princípios básicos.

Por mais que um website seja independente de sistemas operacionais, as experiências que os usuários tiverem com seus sistemas operacionais (SOs) irá influenciar como interagem com o website. Por isso, os padrões das interfaces de SOs não devem ser ignorados. É preciso estar atento, entretanto, às mudanças nos SOs e em outras experiências interativas dos usuários.

Alguns websites já estão incorporando linguagens de interação advindas do iPhone, por exemplo. Quando se fala da usabilidade de um produto, é preciso avaliá-la frente ao contexto real de uso, porém, quando falamos de usabilidade de um modo geral, estamos nos referindo a padrões que atravessam diferentes dispositivos e contextos, ou seja, universais.

Wd :: Diante do caráter dinâmico e veloz que a internet apresenta, os projetos precisam ser revistos de tempos em tempos para se adaptarem as “novas” exigências de usuários e da atualização de tecnologias que possam aperfeiçoar o funcionamento dos sistemas. Recentemente, a Google lançou uma nova interface do Orkut, porém muitos criticaram a ação, classificando-a mais como uma ação de marketing do que uma contribuição efetiva na melhoria do período de experiência. Pensando nisso, quais são os cuidados na hora de se efetuar o redesenho de projetos web, de maneira que não prejudique a usabilidade do ambiente?

Fred :: É muito difícil ter certeza de que um produto inovador será um sucesso do ponto de vista da experiência do usuário. Em primeiro lugar, existem barreiras competitivas: a novidade não pode vazar antes do lançamento. Em segundo, se o produto é realmente inovador, não existem referências equivalentes para comparação.

Na maioria dos casos, as empresas optam por colocar o produto logo no mercado e ver o que acontece. Esse tipo de teste é muito oneroso, mas gera um aprendizado organizacional valioso.

Para superar essa prática corrente no mercado, sugiro que as empresas parem de olhar somente para seu umbigo e aprendam melhor com a experiência de outros. Para que tentar reinventar a roda se alguém já está fazendo isso? Pensemos em turbinas!

Comente este post

As pessoas em geral não estão alheias à questão da sustentabilidade, mas no dia-a-dia a usabilidade é mais importante. Precisamos fazer tantas coisas em tão pouco tempo que a sustentabilidade acaba sendo deixada em segundo plano.

Será que é possível unir as duas coisas? Será que o Design pode propor mudanças de hábitos unindo usabilidade e sustentabilidade para o dia-a-dia urbano? Essa era a pergunta-desafio que propus aos alunos do Centro Tecnológico Opet no Dia Mundial da Usabilidade, semana passada.

Comecei apresentando os conceitos de indução de comportamento pelo Design do Dan Lockton. Em seguida, mostrei exemplos em que o comportamento sustentável era a opção mais divertida, como na proposta da Fun Theory da Volkswagen.

O desafio era criar uma pequena intervenção no dia-a-dia das pessoas que tornasse mais fácil ser sustentável. Algumas propostas foram muito boas, outras não chegaram a aproveitar a usabilidade como fator de indução e ficaram apenas no divertimento. De qualquer forma, foi uma experiência muito bacana saber que estávamos conectados com uma comunidade global pensando na mesma questão.

Conceitos desenvolvidos

Um espelho que modifica a imagem do usuário de acordo com seu consumo de água. O usuário pode ganhar nariz de porco, dente preto ou chifrinhos caso gaste água demais.

Bicicleta ergométrica que transforma a energia da pedalada em energia elétrica. Para ligar os acessórios, o usuário precisa pedalar. No primeiro nível de velocidade, o usuário consegue ligar o ventilador, no segundo o rádio e no terceiro uma televisão.

Uma pia com um bonequinho que se afoga quando gasta água demais.

E o grande vencedor do desafio: colocando pilhas nesse dispensador, você assiste um breve espetáculo musical feito por pequenos bonecos-robôs.

Até meu filho participou (6 anos)! A idéia dele era aproveitar a luz solar para aquecer água e usar para esquentar comida no fogão e tomar banho.

Comente este post

Como podemos definir USABILIDADE?

Usabilidade é o mesmo que facilidade de uso. Se um produto é fácil de usar, o usuário tem maior produtividade: aprende mais rápido a usar, memoriza as operações e comete menos erros.

Quais são os erros de usabilidade mais comuns?

O erro mais comum é acreditar que se sabe tudo sobre os usuários de um website. O criador do website projeta de uma forma que lhe faz sentido, mas para o usuário, não há sentido algum. Aí o usuário se bate, não consegue navegar e até mesmo desiste e vai embora. Quem é que já não passou por estas dificuldades?

• Excesso de informação irrelevante
• Palavras técnicas desconhecidas
• Botões que não reagem como esperado

Isso acontece ou porque o desenvolvedor achou que o usuário ia entender ou porque não sabia como fazer melhor. Usabilidade preenche justamente essa lacuna do desenvolvimento: definir o que fica melhor para o usuário.

Quais são as diretrizes de usabilidade que devem ser usadas na construção de um site?

Eu não acredito em diretrizes. Acredito em bom senso. O desenvolvedor que deseja melhorar a usabilidade de um website deve conhecer bem seus usuários, tomar decisões informadas e testar suas criações. Não existem diretrizes que substituam isso.

Como planejar a estrutura de um site?

Deve-se começar com uma pesquisa com usuários para verificar suas expectativas. Depois, analisar o conteúdo disponível. Esse conteúdo deve ser organizado de uma forma que faça sentido para o usuário, então é preciso convidá-los a participar da organização usando uma dinâmica chamada card-sorting. Por fim, deve-se elaborar diagramas que sintetizem a visão do usuário para os desenvolvedores do website.

Quais são as práticas de usabilidade mais eficientes atualmente?

Pesquisa com usuários. Elas são fundamentais para tomar decisões informadas. Existem vários métodos, tais como testes de usabilidade, card-sorting, avaliação heurística, mas o mais importante é ter bom senso.

As práticas de usabilidade variam de acordo com o tipo de site e seu público? Ou não, são diretrizes fixas?

As práticas de usabilidade devem ser executadas dentro de uma metodologia contextual, que leva em conta a situação específica do projeto, adaptando os métodos e técnicas para a necessidade. Embora existam, eu não confio em procedimentos padronizados para a usabilidade.

É possível avaliar se as práticas utilizadas em um site estão tendo o resultado esperado? Como avaliar?

A análise de estatísticas de navegação e os testes de usabilidade são muito eficientes para verificar o nível de usabilidade de um website. Na análise de estatísticas, é possível identificar situações indesejáveis como, por exemplo, a desistência do usuário no meio de uma tarefa. Porém, não dá pra saber o motivo da desistência. Isso pode ser verificado num teste de usabilidade, no qual o usuário executa tarefas na frente dos desenvolvedores, que observam sua fala, seu estado emocional e contexto de uso.

Você poderia dar exemplos de boas práticas de usabilidade e práticas ruins?

A Usabilidade está por todas as partes em nosso dia-a-dia. Da torneira de banheiro ao painel do microondas. Se funciona, a gente nem nota que está ali, mas se apresenta dificuldade, ficamos irritados. As boas práticas de usabilidade passam desapercebidas, mas contribuem para uma boa experiência no final do dia. Existem produtos que se tornaram famosos por sua usabilidade: é o caso do buscador Google, do iPhone, do Windows e do Nintendo Wii. Algumas pessoas acham que a usabilidade desses produtos é boa, outros acham que é ruim, mas o fato incontestável é que a usabilidade é a alma desses produtos.

O que é o design de Interação?

O Design de Interação vai além da Usabilidade. Usabilidade é um aspecto importante da experiência do usuário, mas não é o único. É preciso considerar aspectos estéticos, emocionais e sociais. Design de Interação integra tudo isso dentro das teorias e metodologias de Design, que fornecem uma excelente base para lidar com o balanceamento destes aspectos. Pode-se considerar o Design de Interação como uma especialidade dentro do Design, assim como Design Gráfico ou Design de Produto.

O que é o Instituto Faber Ludens?

O Instituto Faber-Ludens é uma entidade sem fins lucrativos que promove o desenvolvimento do Design e da Tecnologia no Brasil através da integração entre mercado e academia. Apoiamos projetos de pesquisa, ensino e consultoria nas mais diversas áreas.

Comente este post

É uma suíte que funciona da seguinte forma: você roda o Morae Recorder na máquina do usuário, gravando a tela, o áudio e a webcam em sincronia. Num outro computador, pode ficar um anotador e outras pessoas que desejem acompanhar o teste em tempo real. O Morae Recorder transmite ao Morae Observer os dados via rede. Testamos dentro de uma rede wifi com laptops de baixo poder de processamento e o time-lag foi de alguns segundos apenas.

Por fim, as gravações e anotações são abertas todas em sincronia no Morae Manager, que permite selecionar, cortar, marcar, gerar estatísticas, enfim, tudo necessário para gerar relatórios sobre o teste. O Morae suporta praticamente todo o fluxo de aplicação do método de teste de usabilidade.

Detalhes que encantam: já trabalhava com o Morae há alguns anos, mas só na oficina descobri uma nova funcionalidade: a possibilidade de marcar um ponto interessante do teste com o Wiimote. Mesmo tendo um anotador na sala ao lado, eu como facilitador e analista, sinto a necessidade de lembrar de determinados pontos depois. Dá pra cruzar estas notas com as do anotador, sem conflitos.

O Morae ajuda bastante a executar o teste, porém, não substitui o analista de usabilidade. De nada adianta ferramenta, se não sabe usar. É preciso planejar o propósito do teste, escolher os usuários, facilitar a interação do usuário e interpretar os resultados. Nada disso pode ser feito por uma máquina.

Na oficina, começamos pelo plano, a parte mais importante para o sucesso do teste: definição de objetos a serem testados, objetivos, métricas e perfil de usuários.

Após definir o perfil de usuários, é importante elaborar um roteiro de recrutamento. Se forem recrutados os usuários com os perfis errados, o resultado do teste pode ser irrelevante. Eis uma simulação utilizando o roteiro elaborado pelos alunos:

Uma vez que os usuários estão definidos, é preciso definir o que eles vão fazer. Para fazer um teste orientado a tarefas, é preciso conhecer muito bem a tarefa em questão. Os alunos fizeram análise da tarefa em dois websites concorrentes, de modo a comparar os caminhos e levantar hipóteses de possíveis problemas de usabilidade.

A partir daí, começamos os testes pilotos, que funcionam como simulações. Convidamos o porteiro da faculdade a participar e ele encontrou alguns problemas relevantes no Americana Viagens.

É claro que para ser conclusivo, a seleção de participantes do teste deve ser rigorosa, mas os participantes locais foram de grande valia para fins didáticos. 

Numa sala estava o notebook do usuário, equipado com o Morae Recorder que grava as ações e vídeo do usuário e, do outro, a máquina do anotador com o Morae Observer.

O anotador podia ver e ouvir em tempo real o usuário e deixar anotações que posteriormente seriam sincronizadas com o vídeo, facilitando e muito o trabalho de análise posterior ao teste.

Veja o trecho de um dos testes [AVI - 104 Mb] gravado com o Morae Recorder. 

O material de apoio ao curso está disponível publicamente. Quem quiser participar de novas edições da oficina, assine a newsletter do Instituto Faber-Ludens para ser avisado de novas turmas.

Comente este post

Para Nielsen, Design é a origem dos problemas de usabilidade que engenheiros como ele tem que identificar e corrigir. Os problemas que Nielsen costuma identificar são justamente as características de um projeto que os tornam únicos, expressivos e afetivos. Para uma crítica mais completa, veja o texto"Os usos de Nielsen" traduzido por Carlos André Gonçalves. Também é bacana a crítica dos flasheiros sobre. Abaixo segue o trecho em vídeo da palestra.

Minha recomendação é que Nielsen deve ser conhecido, mas a mesma crítica que ele faz ao trabalho dos outros deve ser feita ao trabalho dele. É importante conhecer outras visões para o Design de Interação, especialmente fora do discurso de Usabilidade e IHC tradicionais.

Comente este post

Nos softwares desktop, as plataformas de desenvolvimento facilitam a inclusão de atalhos pois há um padrão de interação bem estabelecido nesse sentido. Toda aplicação tem os mesmos atalhos de teclado básicos do sistema operacional (Ctrl+C, Ctrl+V, etc) e os menus e barra de ferramentas costumam indicar também os atalhos de teclado equivalentes. O usuário começa a interagir com o mouse e vai gradualmente aprendendo os atalhos de teclado. As vantagens do teclado em relação ao mouse são:

• maior precisão
• maior agilidade
• mnemônica (capacidade de memorização)
• acessibilidade estendida
• velocidade subjetiva mais rápida

Atenção para esta última vantagem, que pode não ser uma vantagem. Nem sempre o teclado é mais rápido do que o mouse, mas, em geral, as pessoas percebem que o teclado é mais rápido, acredito que porque o teclado é mais engajante do que o mouse e dá maior sensação de poder, de controle.

Um estudo realizado por Bruce Tognazzini provou essa teoria em 1992. Foram dadas as mesmas tarefas para as pessoas realizarem primeiro usando o mouse e, depois o teclado. A versão do teclado requeria que o usuário fizesse várias pequenas decisões. A do mouse, não exigia decisões e fazia o usuário pensar menos. Em média, os usuários concluiram a tarefa 50% mais rápido do que com o teclado, mas, pasme, acharam que com o teclado era mais rápido!

Os experimentos de Fitts também comprovam que o teclado é o mais lento dos dispositivos de input para as tarefas de selecionar. Na decisão de usar ou não o teclado, o designer deve prever e pesar a diferença o tempo objetivo ou o tempo subjetivo.

Um prédio comercial em Nova Iorque sofria da lentidão dos elevadores na década de 30. O síndico recebia muitas reclamações e chamou engenheiros para resolver o problema. Não havia como aumentar a velocidade dos elevadores nem adicionar outros. Despesperado, ele chamou um designer de interiores para, pelo menos, tornar a espera mais agradável. Eles tiveram a idéia de colocar espelhos cobrindo as paredes, um de cada lado, assim as pessoas podiam ficar se olhando umas as outras. Assim foi feito e o síndico não recebeu mais reclamações.

O tempo subjetivo também pode ser contrário ao uso do teclado. Basta lembrar da preguiça que dá de trocar mouse pelo teclado para preencher algum formulário. Pior ainda se não der para usar a tecla Tab para mover entre os campos e tiver que alternar entre mouse e teclado diversas vezes até chegar ao final.

Uma vez que o usuário passou ao input do teclado, o ideal é que ele possa concluir a tarefa que está executando sem alternar para o mouse. Digitadores que descobrem como usar o teclado para selecionar e navegar pelo texto e deixam de usar o mouse para isso, ganhando muita perfomance. Alternar demais entre dispositivos de input diminui muito a produtividade do usuário, mas por outro lado, podem evitar LERs.

É possível, entretanto, usar os dois inputs ao mesmo tempo. Se bem projetados, atalhos de teclado e operações com o mouse podem ser realizados conjuntamente. Isso agiliza muito o uso de aplicações com muitas opções, mas só são concebíveis para usuários frequentes. Quando o usuário está familiarizado com o que a aplicação pode fazer, ele começa a procurar formas de otimizar seu trabalho. É um princípio básico da computação.

Pode-se facilitar a memorização dos atalhos e diminuir a taxa de erro fazendo aparecer um pequeno menu que ensina as opções de atalhos enquanto a tecla control ou alt (ou aquela que você escolheu para dar início a sequência) está pressionada. O Office 2007 mostra como acessar os botões da ribbon enquanto se mantém pressionado a tecla alt.

É importante preservar os padrões dos atalhos, caso eles não sejam padrões burros. Ctrl+B só é atalho de salvar no Microsoft Office em português até a versão 2003 (esse B só pode ser de Bill Gates). Em 99% das aplicações, o comando é Ctrl+S. Imprimir é Ctrl+P, copiar e colar você já decorou há tempos e por aí vai. Quando você tiver um comando na sua aplicação que seja o mesmo ou similar a de aplicações de desktop, copie o atalho mesmo que traduzindo para o português não tenha sentido. O usuário fica muito satisfeito quando pode reaproveitar seu conhecimento prévio com outras aplicações.

Um dos atalhos que mais sinto falta na web é o Ctrl+Z. Me parece que os designers de aplicação Web não realizaram que errar é humano e perdoar é divino. Pior do que não ter como voltar, um atalho de teclado errado pode fechar o navegador sem qualquer confirmação ou gravação dos dados. É claro que as aplicações não percebem que isso aconteceu e não voltam ao último estado quando são reabertas. A falta de segurança e tolerância a erros nas aplicações Web ainda me faz preferir aplicações desktop quando disponíveis.

[ nota ] este é mais um artigo de gaveta escrito há 4 anos atrás. Dá pra perceber o contraste com os escritos em Design de Interação mais recentes?

Comente este post

As interfaces são construídas em torno de um dispositivo de entrada principal. Os demais são auxiliares. Um jogo orientado ao teclado até permite usar o mouse em menus, mas não dá pra fazer tudo com ele. Já nos aplicativos de desktop, existem uma miríade de atalhos no teclado para funções rotineiras que economizam movimentos e cliques do mouse. Porém, somente usuários que usem o programa frequentemente conseguirão memorizá-los. O mouse é mais fácil de usar porque as opções disponíveis estão explícitas no foco da interação. Mesmo que tenha a marcação do atalho de teclado ao lado da opção de menu (Shift+Espaço ao lado de "Espaço não separável ", por exemplo), quando o usuário for acionar este atalho sem o menu, a visualização não estará disponível.

O mouse do Macintosh é composto de apenas um botão. O do PC, em geral tem dois. Alguns podem ter três botões ou uma rodinha chamada mouse wheel. A partir de agora, quando usar o termo botão do mouse, estarei me referindo ao botão esquerdo do PC e ao botão único do Macintosh.

rollOver

Evento que ocorre quando o ponteiro do mouse está sobre o botão. Embora seja um efeito simplório, é muito eficaz para valorizar o input, a participação do usuário. Outra vantagem é que o usuário não precisa pensar se o cursor está ou não sobre o botão. Ele pode olhar apenas com o canto do olho o botão mudando de cor, liberando a visão para outros assuntos mais importantes.

O problema é quando esses efeitos são muito chamativos e há vários botões na tela. Pior ainda se o efeito rollOver for uma animação. O resultado é uma verdadeira dança de botões, poluição visual. Uma solução prática é ativar o rollOver só se o mouse repousar mais de meio segundo sobre o objeto. Assim quando ele passar em velocidade, o efeito não será ativado.

Designers dos primórdios da Web, se esmeravam em programar aquele javascriptzinho para mudar a imagem do link e alcançar o efeito rollOver. Quando descobriram que o Flash fazia isso muito mais facilmente, ficaram apaixonados. A instância button já vem equipada com os frames "Up" e "Over" que controlam a aparência do botão antes e depois do cursor estar sobre ela. Assim como os designers dos primórdios que descobriram o efeito rollOver em javascript, os designers que usam o Flash abusaram do efeito. É um erro comum esconder o rótulo de uma opção do menu para mostrá-las somente no estado rollOver, por exemplo.

Para ilustrar como essa prática é ruim, conto uma cena que vi. Certa vez, estava num terminal de ônibus e vi um cego andando sozinho com a ajuda daquela vara que eles batem no chão. A cada 10 passos em média, o cego esfregava ostensivamente a sola do sapato no chão. Fiquei encafifado. Seria um cacoete? Depois de algumas esfregadas, ele parou e ficou esperando o seu ônibus. Olhei para o chão. Ele estava fazendo isso para se orientar, saber onde era o ponto do ônibus que ele iria pegar. O chão do terminal é revestido de lajotas àsperas, mas de vez em quando, há algumas lajotas lisas, aleatórias. Decerto decorou o número de lajotas lisas e de passos necessários para chegar desde a entrada do terminal ao ponto certo.

Da mesma forma, o usuário que não pode ver todas as opções de um menu vai testar cada uma delas, assim como o cego que testa a textura das lajotas. Nem todas as pessoas gostam de jogar Campo Minado. O usuário vai perder tempo, porque mover o mouse é mais demorado do que mover o olho. Para o cego, não tem jeito: ver a amplitude de pontos a sua disposição antes de andar é impossível sem a ajuda de outra pessoa. Mas, para o usuário, basta o menu ser explícito e não depender do evento rollOver para se revelar.

Segundo pesquisadores, escolhemos onde vamos clicar e só depois nos dirigimos a opção desejada. Lembre-se daquele seu amigo impaciente usando o computador: ele fica girando o mouse em círculos na àrea central da tela enquanto decide pra onde vai. Por essse mesmo motivo, opções de menu que se desdobram ao passar o mouse por cima (fly-out) não são recomendáveis. O usuário nunca vai conseguir ver todas as opções disponíveis dos submenus ao mesmo tempo para poder decidir.

Se o cego tivesse como saber exatamente onde fica o ponto onde quer ir e não tivesse nenhuma possibilidade de alguém cruzar o seu caminho, ele chegaria mais depressa ao seu destino. Para encontrar o ponto da forma como vi, o cego precisa de muita força de vontade, é uma tarefa relativamente complicada. Para o usuário, significa apenas um movimento mínimo a mais do seu braço, mas é completamente desnecessário. Os desconfortos do uso do computador deixam o usuário sem paciência para essas coisas.

Press

Evento que ocorre quando o usuário pressiona o botão do mouse. O objeto acionado pode simplesmente mudar de cor quando esse evento acontece ou já ativar sua ação. Feedback quando o botão está pressionado torna a interface como um todo mais responsiva. Quando o usuário pressiona o botão e não solta ele pode saber onde está clicando e desistir, arrastando o ponteiro para fora do botão.

Quando a possibilidade do usuário ficar em dúvida ao clicar num objeto é nula, a ação desse objeto pode ser ativada direto no evento Press, ao invés do tradicional Release. Assim, o usuário ganha alguns milisegundos de tempo e tem uma leve impressão de que a interface é mais rápida.

Release

Evento que ocorre quando o usuário solta o botão do mouse dentro do objeto. É o padrão para ativar os botões da interface. Não há muito o que dizer de algo tão óbvio. Só acrescento que ao soltar o botão, o usuário esperará no máximo um segundo para ter algum retorno da interface. Pode ser a mudança de estado do botão, um efeito sonoro, ou uma mensagem de carregando ou etc. Se nada acontecer nesse curto período de tempo, ele ficará em dúvida e, dependendo da pressa, pode clicar novamente até que algo aconteça.

Esse evento possui uma variação chamada ReleaseOutside que acontece quando o usuário pressiona o botão dentro do objeto e solta fora da área de ação. O evento DragOut acontece antes do usuário soltar, ou seja, assim que ele arrasta o ponteiro para fora do botão. Se ele trouxe o cursor para dentro do botão novamente, ativa o evento DragOver.

Drag´n-drop

É o movimento do mouse que consiste em clicar num objeto e manter pressionado o botão enquanto move o mouse, e finalmente soltá-lo. Arrastar-e-soltar, em português.

Se em algum momento, você se sentir tentado a usar esse movimento para tornar mais próximo do real a interação entre os objetos, pense duas vezes. Primeiro poque é preciso explicitar que deve ser assim a interação, já que o normal é clicar nas coisas para elas acontecerem. Segundo porque é um movimento que exige perícia e paciência do usuário. Ele pode, sem querer, diminuir a pressão sobre o botão do mouse e errar. O mouse pode colidir com algum outro objeto na mesa ou o mousepad pode acabar bem na hora e o usuário erra de novo. Para ser cuidadoso, o usuário move o mouse mais devagar do que o normal.

Fora esses aspectos objetivos, o arrastar-e-soltar em geral é visto de forma negativa. Um estudo realizado com crianças revelou que elas preferem o apontar-e-clicar ao invés do arrastar-e-soltar. Metade das crianças jogaram a versão do clássico jogo The Incredible Machine baseada no apontar-e-clicar e a outra metade, no arrastar-e-soltar. As crianças do primeiro grupo resolveram mais quebra-cabeças e foram mais rápidas do que as do segundo grupo.

A vantagem do apontar-e-clicar é que ele decompõem o movimento em duas partes. Para crianças, o esforço físico do arrastar-e-soltar, em geral, não compensa pelo ganho conceitual. Mas, para a audiência que possui boa experiência de uso do computador, o movimento pode ser útil em aplicações complexas. A melhor solução para todos os casos é tornar o arraste opcional. Arrastar um item de uma loja virtual até o carrinho de compras pode ser interessante para algumas pessoas dispostas ao esforço adicional. Para outras, isso pode ser dispensável. Então, em algum lugar proeminente da tela há uma instrução: "arraste os itens até o carrinho ou clique no botão comprar". A interface deve dar sempre a oportunidade do usuário escolher o método para realizar a tarefa que mais lhe agrada.

Se só existe um destino possível para o arraste, ele não apresenta grandes vantagens sobre o apontar-e-clicar. Mas, seguindo a idéia da loja virtual, se houvesse dois destinos (o carrinho de compras e a lista dos itens desejados, por exemplo), o apontar-e-clicar exigiria dois botões desenhados próximo a cada um dos itens, o que aumentaria o ruído visual. Melhor somente duas caixas de destino no canto da tela e os itens para serem arrastados. Quanto mais destinos possíveis, mais o arrastar e soltar é útil.

Quando o assunto é lazer, o arraste pode enriquecer muito a metáfora. Imagine uma loja virtual de roupas. Como não é possível prová-las, o consumidor fica numa situação complicada quando quer comprar peças de roupa avulsas. Um provador virtual serviria para o consumidor testar se as peças escolhidas previamente combinam entre si. Um manequim no centro e as roupas dispostas nos cantos. O usuário pode trocar, ajeitar ou simplesmente bagunçar tudo através do arraste. Não é como ir pessoalmente à loja, mas é mais parecido do que ver só uma foto de cada peça separadamente.

Se você for incluir o arraste em seu projeto, siga as seguintes dicas:

• avise numa mensagem proeminente que o arraste é possível ou necessário. Para determinados tipos de audiência, pode ser útil uma breve animação explicando como é o processo
• mude o estado do objeto arrastado a cada etapa do movimento: apontar (rollOver), clicar (Press) e soltar (Release)
• diminua ao máximo a distância entre o item e o destino
• aumente as proporções do destino ao máximo possível. Seu tamanho mínimo é igual ao tamanho do maior objeto arrastado
• aceite uma margem de erro. Se o objeto for solto próximo ao destino, trate como se tivesse sido na mosca
• caso haja algo mais entre o destino e os objetos arrastados, não permita que eles fiquem estagnados no lugar onde forem soltos, à exceção do destino. Isso pode causar uma bagunça tremenda, melhor voltá-los à posição antes do arraste

Double-click

Movimento que consistem em dois cliques seguidos sobre o objeto. Foi criado na época em que o mouse tinha apenas um botão com o intuito de dar duas opções de operação sobre ícones.

No Windows Explorer, o clique seleciona arquivos e o clique-duplo, os abre. Na verdade, uma vez selecionado o arquivo, não há muito o que fazer com ele, a não ser ver as informações de tamanho que aparecem na barra de status ou dar algum comando de teclas, como deletar, recortar e etc. A necessidade do clique-duplo para abrir o arquivo serve mais para confirmar a intenção do usuário de abrir a aplicação. Experimente alterar esse estilo de interação do seu Windows para abrir com um único clique e verá como a incidência de erros fica maior. Depois de algum tempo, você se acostuma, assim como se acostumou a navegar na Web. Vai me dizer que você nunca deu um clique-duplo num texto sublinhado?

Pois é, na Web o estilo de interação é com um clique só e quem fere esse padrão corre sérios riscos. Se não for dito ao usuário, ele clicará no botão uma vez e, se nada acontecer, vai julgar que há algo de errado com o website e vai embora. Além do mais, é preciso uma boa justificativa para usar o duplo-clique porque afinal, assim se gasta mais energia. Usuário odeia perder tempo na Web.

Até hoje, não encontrei uma aplicação decente para o duplo-clique em websites e aplicações Web, a não ser aquelas que simulam ambientes típicos dos sistemas operacionais, como janelas, pastas e etc.

Nota: Encontrei esse artigo abandonado em minha gaveta desde 2004. Resolvi publicá-lo antes que o mouse seja substituído pelos monitores sensíveis a toque.

Comente este post

Cidades em que acontece o evento:

• São Paulo
• Rio de Janeiro
• Belo Horizonte 
• Manaus
• Recife
• Porto Alegre
• Curitiba

Eu estou particularmente envolvido com a organização em Curitiba. Tenho certeza que será um excelente evento.

Nesse ano tentaremos uma novidade. Transmitir ao vivo nosso evento em Curitiba e nos conectar com os demais eventos, em outras cidades. A idéia é que seja possível acompanhar o evento mesmo não estão na cidade através do nosso canal no Ustream.tv. Fique de olho, pois no dia 13 de novembro, quinta-feira, haverá transmissão o dia inteiro.

Comente este post

Da Psicologia Cognitiva veio a Teoria do Processamento de Informação e da Psicologia Sócio-Histórica, veio a Teoria da Atividade. Embora Design de Interação seja uma área prática - diferente de IHC que é científica - essas teorias são muito importantes porque delineiam as metodologias, métodos, técnicas e princípios empregados na prática.

Slides [PDF] 6 mb

A Teoria do Processamento de Informação é a mais conhecida (e muitas vezes a única). Ela se baseia na premissa que a mente humana é um processador extremamente complexo de informações. No entanto, se subdividimos seus componentes e descobrirmos como eles se relacionam, é possível compreender o funcionamento da mente. Os cientistas observam o comportamento, formulam modelos abstratos de funcionamento e rodam experimentos para tentar comprová-los. Essa teoria possibilitou o desenvolvimento das seguintes coisas, por exemplo:

• O computador
• Interfaces gráficas
• Design Centrado no Usuário
• Teste de Usabilidade
• Card-sorting

Já a Teoria da Atividade é menos conhecida, mas também influente. A idéia principal é que o sujeito é construído socialmente através da interação com seus pares, sempre mediada por instrumentos ou signos. A consciência se manifesta na atividade (social) e, consequentemente, a constituição mental de um indivíduo é delineada pelas atividades em que ele participa. Para investigar a mente, é preciso investigar o locus social dos indivíduos e, principalmente, suas atividades. Essa teoria possibilitou o desenvolvimento das seguintes coisas, por exemplo:

• Websites de redes sociais
• Softwares colaborativos multi-usuário
• Design Centrado na Atividade
• Design Participativo
  
• Etnografia

Conhecer estas duas teorias é fundamental para o designer de interação ser crítico em relação à sua prática e, principalmente, com as conceitualizações ingênuas de sua prática. O designer praticante não é um teórico, portanto, não precisa ficar preso a nenhuma dessas correntes e sim, aproveitar suas contribuições.

[ Download vídeo ]

Áudio [MP3] 51 mb

Comente este post

É comum encontrar botões grandes nas interfaces? Não. A navegação secundária está sempre o mais perto possível da navegação principal? Não. Os cantos do monitor são usados como alvo? Não. 

Talvez a facilidade motora não seja importante para a maioria dos projetos de interface, mas acredito que se essa Lei fosse mais conhecida, seria melhor aproveitada. Numa sociedade que valoriza mais a dimensão semântica (significado) do que a pragmática (uso) das interfaces, isso é compreensível.

Botões grandes

Botões grandes são mais fáceis de acertar, mas são difíceis de encaixar nos layouts porque dificultam a hierarquia visual. Se o botão não é usado na tarefa, ele chama a atenção desnecessariamente. Se o botão é grande, também é maior a ênfase persuasiva na opção.

Uma dica simples é que a área de ação do botão tenha, pelo menos, 12px de largura e 24px de altura, que é o tamanho do cursor padrão do mouse. Assim não resta dúvida se o cursor está dentro ou fora do botão. Além disso, pode-se estender a área de ação para fora do desenho do botão, o que dá uma margem de erro para a pontaria do cursor. Na Web, o cursor muda automaticamente quando está sobre a área de ação do botão.

Cantos da tela

Melhor do que botão grande, só posicionando o botão no canto da tela. Por mais que o usuário arremesse seu mouse para o lado, não há como passar além do limite da tela. É como se o botão tivesse altura e largura infinitas. Para um destro, o canto inferior direito é o mais rápido de acessar, seguidos do canto superior esquerdo, superior direito e inferior esquerdo. Mexa o mouse e deixe que seus músculos lhe provem isso. Os pontos das bordas entre os cantos também são poderosos, mas possuem apenas uma das dimensões infinitas: ou largura ou altura.

O Mac OSX faz bom uso da Lei de Fitts. Os menus dos softwares estão posicionados sempre no topo absoluto da tela, o que os torna muito mais rápidos de acessar do que os menus no Windows, posicionados ligeiramente abaixo do topo da tela, quando a janela está maximizada. Quando trabalhava na Apple, Bruce Tognazzini verificou que a performance
dessa disposição era muito melhor do que outro computador com dois monitores, um em cima do outro, com o menu no topo do monitor de baixo, o que eliminava a altura infinita do menu.

O Dock, a metáfora de barra de programas do OSX, além de estar grudada num dos cantos da tela, amplia os ícones na medida em que o mouse se aproxima.

O OSX peca, entretanto, na barra de rolagem. Quando se maximiza uma janela, ela não encosta no canto direito da tela. 

Proximidade do mouse

Entretanto, a Lei de Fitts não deve ser prioridade absoluta em todas as ocasiões no Design de Interação. Bruce Tognazzini sugeriu certa vez que os menus contextuais (acionados com o botão direito do mouse) deveriam se alinhar centralizadamente ao ponteiro do mouse, deixando as opções mais próximas do ponteiro. Isso de fato facilitaria o acesso a algumas opções do menu, mas complicaria a compreensão do contexto. 

No buscador de músicas Songza, criado pelo filho de Jeff Raskin, quando se clica num item da lista, o menu aparece em círculo ao redor do cursor. 

Comparando com o menu contextual do iTunes, é possível perceber a intenção de priorizar as opções mais comuns, bem como uma ordem lógica.

Comente este post

Parece um paradoxo, algo impossível de acontecer, simplicidade e sofisticação estarem num mesmo lugar, no mesmo objeto. Mas é real: empresas como a Apple e Google  estão chamando a atenção do mundo pelo fino equilíbrio entre essas qualidades. A Google saiu do fundo de uma garagem para se tornar uma das maiores empresas do mundo em menos de 10 anos graças à simplicidade de sua página e à sofisticação de seu mecanismo de busca. Só é preciso digitar uma palavra e apertar um botão para ter acesso a milhares de informações espalhadas na Web. A complexidade fica por conta do sistema, que realiza operações mirabolantes para indicar à pessoa as páginas mais relevantes.

Mas a simplicidade tem um preço: a simplicidade esconde mais do que revela. Olhamos para um objeto ou uma pessoa simples e pensamos: “puxa vida, gostaria de ser como aquela pessoa” ou “ter o que ela tem”. O que não sabemos é que ser simples não é simples. Um sábio indiano certa vez escreveu que o segredo da felicidade é “vida simples, pensamento elevado”. Tento aplicar isso em minha vida, mas é tão difícil... O problema é que, em nossa sociedade atual, a vida é muito complicada. Temos que desempenhar diversos papéis sociais, vivenciar dramas, equilibrar conhecimento, economia e prazer numa agenda sempre lotada!

A simplicidade está na moda porque a complexidade impera. A cada momento, multiplicam-se em progressão geométrica as coisas que precisamos conhecer, relacionar e interagir para sobreviver. Definitivamente, não damos conta de tudo. Quando aparece um deserto nesse mar de oásis, ficamos embasbacados, pensando como é possível que ninguém sacou antes que poderia ser simples assim? Esse efeito estarrecedor da simplicidade é pura ilusão. Na miragem, o iPod parece uma caixa com um botão, uma rodinha e um display que é a solução para as demandas de consumo de música do indivíduo. Desmistificada a elegância da simplicidade, percebemos que ao invés de solucionar qualquer coisa, o iPod complexifica ainda mais a vida das pessoas. Agora temos que escolher não uma dentre 10 músicas do Discman, mas uma dentre 5.000!

A última versão do iPod, agora com monitor sensível ao toque, comporta menos músicas, mas faz um monte de outras coisas: funciona como agenda, calculadora e navegador de Internet. Na verdade, a Apple aproveitou o sucesso do iPhone e fez uma versão sem telefone: o iPod Touch. Para quem já tinha um iPod anterior e acompanhou o lançamento do iPhone, ele parece tão simples quanto o primeiro iPod. Agora, para quem está de fora dessa cultura, ele é uma quimera tão assustadora quanto o programador de gravação do videocassete. Como diz John Maeda em seu livro As Leis da Simplicidade, “o conhecimento faz tudo mais simples”, logo a simplicidade não é universal: para alguns é simples, para outros, não.

É por tudo isso que não concordo quando alguém evoca o velho bordão do design cunhado pelo arquiteto Mies van der Rohe na escola Bauhaus: “menos é mais!” Eu pergunto: menos é mais para quem? Van der Rohe usava ela para aludir à racionalização extrema de recursos: usar o mínimo de material para obter o máximo de eficiência de uso. O modernismo almejava a padronização do cotidiano segundo leis de bem-estar pretensamente universais. Hoje em dia, ninguém acredita que isso seja possível, no entanto continua-se a repetir que “menos é mais”. É porque a frase adquiriu um novo sentido. Diante de tamanha abundância de produtos e tecnologia, oferecer menos é um diferencial de mercado, ou seja, destaca o produto. Hoje, menos é diferente, não é mais. Se fosse mais, as pessoas pediriam menos produtos, menos funcionalidades, menos consumo, mas não é o que se observa na prática: as pessoas querem sempre mais e mais! Menos é menos e mais e mais; não dá pra correlacionar quantidade com qualidade.

Assim como o protagonista do romance A Insustentável Leveza do Ser sente o peso do comprometimento com a liberdade quando se envolve com uma mulher, nós sentimos o peso da simplicidade quando sua complexidade inerente se desvela. Negar a complexidade é tapar o sol com a peneira: o caos se alastra inevitavelmente. Entretanto, precisamos crer em simples ideais para sobreviver ao caos que nos consome em nossa sociedade atual.

Nota: a idéia desse artigo é problematizar a visão simplista que se tem da relação entre simplicidade e complexidade, manifesta, por exemplo, na excelente (porém simplista) palestra do meu amigo Horácio Soares. O primeiro artigo que encontrei que me fez repensar a empolgação com a simplicidade foi o questionamento sobre a pretensa simplicidade do Google de Donald Norman. Depois, o contato com os projetos explorando os prazeres complicados dos seres-humanos no Royal College of Art me convenceram de vez a ser mais crítico a respeito dessa questão.

Comente este post

Agora, a opinião pública quer culpar alguém para aliviar sua raiva. Os jornais citam a possibilidade de uma falha técnica no avião, mas não se levanta que possíveis falhas técnicas poderiam ter ocorrido. Os jornalistas só querem saber de suspeitos:

• O Presidente Lula, por não ter botado ordem na casa depois do acidente com o avião da Gol ano passado
• Aos controladores de vôo, por terem autorizado o pouso em condições sub-ótimas
• Aos medidores do nível de água na pista por terem informado que a pista estava levemente molhada
• Os diretores da Tam, que pressionam os pilotos para descer mesmo em condições desfavoráveis para evitar a insatisfação dos clientes
• Os pilotos, que não estariam capacitados para a operação ou teriam cometido erros na avaliação da situação

A investigação pode demorar 10 meses, isso se não acabar em pizza. Enquanto o resultado oficial não chega, as opiniões se dividem em duas hipóteses: erro humano ou falha mecânica. Eu não entendo nada de aviação, mas quando li a notícia tive o pressentimento de que poderiam ser as duas coisas em conjunto: comportamento das pessoas e adaptação das máquinas inadequados para a situação.

O comportamento das pessoas, a mídia já está cuidando de avaliar, ou melhor, julgar. Então, aqui pretendo levantar as inadequações das adaptações das máquinas, em especial, no nível da interface entre os pilotos e o sistema. Esse ponto é relevante para análise do acidente porque a ação humana é restringida pelas possibilidades que o sistema oferece. Se os pilotos tomaram uma decisão que levou ao acidente, pode ser que não houvessem outras alternativas disponíveis no sistema para aquela situação ou, mesmo que elas existissem, elas não estavam visíveis.

Antes, um esclarecimento: não sou especialista no assunto. O que escrevo abaixo me baseio exclusivamente na minha experiência como designer de interação para a Web, na leitura de alguns artigos de Donald Norman sobre a Psicologia Cognitiva em cockpits e numa breve pesquisa que fiz sobre a documentação do modelo do avião e simuladores. Se alguém entender mais do que eu, por favor, corrija-me.

Para começar, vamos ver o que a Tam diz sobre a análise de acidentes em seu guia para a segurança em vôos:

E.3.2.1 Em poucos anos, sistemas complexos têm evoluído para sistemas automatizados sofisticados com muitas interações e interfaces. Esses sistemas podem ser formados por vastos subsistemas de hardware, firmware (isto é, software com dongle), software de eletrônica, aviônica, hidráulica, pneumática, biomecânica, ergonomia e fatores humanos. Há complicações adicionais envolvendo outras considerações, como o potencial de supervisão pela gerência e percepção do risco. Um paradigma mais completo do risco de um sistema deve levar em consideração todas estas complexidades.

Até aí tudo bem. Eles propõem, então, o modelo SHEL (Software, Hardware, Environment - Ambiente e Liveware - Pessoas):

A partir daí, as pessoas são tratadas como "Equipamento humano" e os demais equipamentos devem combinar com às suas características peculiares. O problema é que as pessoas tem o "péssimo hábito" de...

adaptar-se a más combinações, mascarando, dessa forma, qualquer má combinação sem removê-la e, como tal, constitui um perigo potencial. Exemplos disso são altímetros de três ponteiros, mau layout dos assentos nas cabines, que pode atrasar a evacuação, etc.

Eu não diria que isso é um péssimo hábito. Diria que, se uma pessoa é obrigada a usar um determinado sistema, o melhor a fazer é adaptar-se a ele. E o inverso também é verdadeiro: os sistema deve se adaptar à pessoa. Numa relação de adaptação mútua, os conflitos se assentam, mas, quando emergem variáveis externas incomuns, a adaptação acaba: o homem vai prum lado e a máquina vai pro outro. O homem abandona os procedimentos padrões e age com base na emoção para encontrar uma solução inesperada para um problema inesperado, enquanto a máquina solicita ou executa procedimentos pré-definidos para a solução do problema - isso se ela tiver percebido a adversidade.

Segundo relatos dos controladores de vôo da torre do aeroporto, os pilotos foram avisados de que a pista estava molhada e escorregadia antes do pouso. Tocaram o solo normalmente, mas não se sabe por que, os pilotos resolveram tentar subir de novo. A torre só se deu conta de que alguma coisa estava errada quando ouviram um dos pilotos gritar "vira, vira, vira!", mas em seguida o avião bateu e explodiu. Os colegas dos pilotos acreditam que o avião entrou em aquaplanagem (um estado em que o atrito com o solo é reduzido) e, quando não havia mais espaço, tentaram decolar novamente ou dar um cavalo-de-pau.

O avião pode ter entrado rápido demais na pista para a condição climática da situação, o que indicaria uma decisão errada dos pilotos. Mas vejamos se essa decisão foi tomada só pelos pilotos ou se a máquina também participou da decisão.

Segundo o FCOM, o manual do A320, quando a aeronave se encontra a baixa altitude, o modo de controle muda para pouso automaticamente. A partir daí, a máquina faz o ajuste automático da velocidade do avião e do ângulo de inclinação dentro de certos limites, que podem ser definidos pelo piloto. A imagem capturada de um simulador do A320 demonstra a sinalização visual de que o auto-land está ativado:

Em seguida, o piloto pode ativar o auto-brake, que possui três opções:

• Lo - condições normais de pista
• Med - pistas curtas ou molhadas
• Max - não recomendável para pousos

Pode ser que os pilotos, acostumados com o procedimento padrão, ativaram o auto-brake Lo, quando deveria ser Med ou Max. Também pode ser que eles tenham superestimado a velocidade máxima que o avião poderia atingir naquela situação e usaram o padrão. Em ambos os casos, a máquina não toma a decisão sozinha, mas contribui para o piloto tomar.

Quando se automatizam procedimentos nas máquinas, o processo não fica explícito para os homens e eles tendem a confiar demais na automatização. É por isso que a cabine do avião tem tantos displays e controles. Poderia ser tudo automatizado e controlado através de poucos controles, mas devido às experiências fracassadas de outrora, a aviação tenta reduzir ao mínimo a automatização.

Entretanto, talvez a aviação não esteja atenta para os perigos da automatização da ação humana. Quando as pessoas repetem os mesmos procedimentos diversas e diversas vezes, a tendência é que ignorem pequenas variações necessárias, como uma redução da velocidade em função da chuva.

Quando os pilotos perceberam que não ia dar pra parar na pista, era tarde demais. O procedimento padrão é identificar a inadequação para pouso antes de tocar o solo porque, para levantar novamente do solo, é preciso uma velocidade muito mais alta do que quando se pousa. Se, mesmo assim o avião pousa e ultrapassa uma marca na pista, ele é aconselhado a arremeter. Nesse caso, o avião aterrissou antes da marca, mas não conseguiu reduzir o suficiente. Na verdade, o avião acelerou, não se sabe se por intenção do piloto ou mal-funcionamento do reverso.

Se a investigação apontar "erro humano" na operação, devemos considerar se não seriam problemas de usabilidade imprevistos que surgiram na situação de risco e não permitiram a rápida recuperação do problema ou se a automatização induziu ao "erro humano".

Quem quizer saber mais sobre usabilidade em situações críticas, dê uma olhada no blog Confiabilidade humana, mantido pelos pesquisadores da USP.

Comente este post

Se você já quebrou a perna e teve que subir uma escada de muletas, sabe a falta que faz uma rampa para uma pessoa que tem de usar muletas a vida inteira.

Quando você era criança, você queria ligar no orelhão pra passar trote e não conseguia porque era muito alto. "Telefone é coisa de gente grande", diziam os adultos, mas e quanto aos adultos que usam cadeira de rodas e precisa fazer uma ligação urgente?

Neste momento, enquanto você lê esse texto, você pode achar que a fonte está grande ou pequena demais para a sua vista. Se você tem um mouse com rodinha de rolagem, você pode segurar a tecla Ctrl (windows) ou Command (mac) e girar a rodinha; o texto vai aumentar ou diminuir de acordo com a sua vontade. Legal isso né?

Mas e se você não tivesse como usar o mouse? Sim, pode ser que você não tenha nascido com dificuldades motoras, mas pode adquirí-la futuramente se quebrar um braço, se for alcoólatra, se vier a sofrer de Parkinson e etc. Nesse caso, basta usar as teclas Ctrl ou Command combinadas com as teclas + ou - para ter o mesmo efeito.

Essas opções de acessibilidade estão embutidas no seu software navegador, mas se eu tivesse bloqueado a mudança do tamanho do texto usando uma medida fixa para a fonte, pode ser que você não conseguisse usá-las.

Porque eu faria isso? Ora, pra que meu layout fique sempre igual do jeito que eu quero e quem não conseguir ler, que diminua a resolução do monitor. Ou talvez eu faça isso porque é mais fácil. Se usar um tamanho de fonte relativo, terei que garantir que todo o layout se ajuste, o que daria um trabalhão e os clientes não iriam me pagar o extra. Não vale à pena.

Economizando desse jeito, logo consigo juntar uma grana pra comprar um PDA com acesso à Internet . Abro este site no navegador do PDA pra mostrar pros meus amigos e o danado do site fica todo desconjuntado porque eu mesmo defini que ele é "melhor visualizado com Internet Explorer 6.0, 1024x768 pixels de resolução e Flash Player versão 9 instalada". A vergonha dá pra disfarçar com uma desculpa esfarrapada, mas e se fosse uma situação crucial na qual eu precisasse muito das informações do site?

O fato é que, mais cedo ou mais tarde, seremos vítimas das barreiras que nós mesmos criamos. Se é assim, por que não se esforçar para evitar as barreiras? Nós saímos ganhando com isso; nossos amigos saem ganhando com isso; pessoas que nem conhecemos saem ganhando com isso; enfim, a sociedade como um todo sai ganhando com isso.

Oxo: exemplo de sucesso

Sam Farber tinha uma fábrica de utensílios domésticos chamada Copco nos Estados Unidos. Ele sempre se preocupou em criar produtos acessíveis para pessoas idosas e com deficiências físicas, mas isso não era o foco da empresa. Quando se aposentou, ele e sua esposa passaram algumas semanas na França e os utensílios à disposição eram terríveis para quem tinha artrite como a esposa de Sam. Sam decidiu voltar à ativa e fundou a Oxo International com a proposta de design universal como missão da empresa. Os novos produtos ganharam visibilidade na mídia e cairam no gosto popular. Mesmo quem não tinha nenhuma deficiência, preferia comprar Oxo pela facilidade de uso. A empresa ganhou vários prêmios e Sam pode se aposentar de novo, agora com a satisfação de ter contribuído e muito para um mundo melhor.

Acessibilidade em três passos

Primeiro passo: não exclua ninguém, a não ser o preconceito. Mesmo que determinadas pessoas não se encaixem no público-alvo do projeto, elas devem ter livre acesso. Você não gostaria de ser barrado numa portaria de um prédio só porque não faz parte do "público-alvo" do prédio, não é mesmo? Discriminação é crime, mas, através do design, a discriminação pode se reproduzir da forma mais cruel e imperceptível possível, mesmo aos olhos do próprio designer. Designers precisam conscientizar-se de que o diferente não é ameaçador; pelo contrário: é com ele que aprendemos coisas novas.

Segundo passo: flexibilize o acesso. Todas as pessoas são iguais perante à Lei e, portanto, tem os mesmos direitos. No entanto, a maneira como cada pessoa goza de seus direitos é diferente, já que cada pessoa tem um corpo diferente, pensa diferentemente e age diferentemente. Os objetos e ambientes projetados são os mesmos para muitas pessoas, mas eles podem ser flexíveis a ponto de suportar algumas diferenças básicas. Algumas pessoas são altas e outras baixas e, para não impedir o acesso de ambos, devemos ter degraus baixos e portas altas. Nivelamos pelo percentil 5 e 95 . Quando a diferença é na percepção sensorial, devemos oferecer conteúdo alternativo para outros sentidos: textos que podem ser lidos por surdos oralizados ou sintetizadores de voz para cegos, por exemplo. Por fim, devemos permitir que as pessoas acessem com diferentes apetrechos (carro ou bicicleta; laptop ou smartphone) e encontrem caminhos alternativos para chegar onde elas querem (sinalização de orientação ou balcão de informações; navegação por menus ou busca por palavra-chave).

Terceiro passo: se coloque no lugar do outro. Teste o que você projetar. Baixe o leitor de telas Jaws e tente navegar no seu website de olhos fechados, usando apenas o teclado. Se você não for cego, isso só vai te dar uma sensação próxima da que passará um cego de verdade, pois ele não poderá abrir os olhos quando chegar numa parte confusa. Por outro lado, eles estão muito mais acostumados do que você a se virar em situações como essa. Celebre a diferença observando como as outras pessoas acessam seus projetos e aprenda com isso. Tome como guia os princípios de Empatia e de Crítica.

Chamando à responsabilidade

A Acessibilidade é uma área que justifica especialistas como os meus colegas da Acesso Digital, mas isso não significa que todo o trabalho deve ser empurrado a alguém que entenda do assunto. Entender do assunto é responsabilidade social de todo designer. O design acessível pode permitir que as pessoas façam coisas maravilhosas que, sem ele, seriam impossíveis. A Leda e o MAQ sempre foram vozes muito ativas nas atividades da Acesso Digital e nesse vídeo não foi diferente. Quem viu, viu; quem não viu, ouviu; quem não ouviu, leu e quem não viu, não ouviu e não leu, não sabe o que está perdendo.

Download completo em vários formatos.

[nota] Aproveitei para criar uma nova seção neste blog para agregar tudo o que já escrevi sobre Acessibilidade. Como disse o Horácio, depois que conheci o pessoal da Acesso Digital, estou me tornando também um acessibilidoido.

Comente este post

Vale ressaltar que as heurísticas são síntese de um conhecimento maior. Para aproveitá-las é preciso entender como se chegou a elas.

1) Feedback

• O sistema deve informar continuamente ao usuário sobre o que ele está fazendo.
• 10 segundos é o limite para manter a atenção do usuário focalizada no diálogo.

2) Falar a linguagem do usuário

• A terminologia deve ser baseada na linguagem do usuário e não orientada ao sistema. As informações devem ser organizadas conforme o modelo mental do usuário.

3) Saídas claramente demarcadas

• O usuário controla o sistema, ele pode, a qualquer momento, abortar uma tarefa, ou desfazer uma operação e retornar ao estado anterior.

4) Consistência

• Um mesmo comando ou ação deve ter sempre o mesmo efeito.
• A mesma operação deve ser apresentada na mesma localização e deve ser formatada/apresentada da mesma maneira para facilitar o reconhecimento.

5) Prevenir erros

• Evitar situações de erro.
• Conhecer as situações que mais provocam erros e modificar a interface para que estes erros não ocorram.

6) Minimizar a sobrecarga de memória do usuário

• O sistema deve mostrar os elementos de diálogo e permitir que o usuário faça suas escolhas, sem a necessidade de lembrar um comando específico.

7) Atalhos

• Para usuários experientes executarem as operações mais rapidamente.
• Abreviações, teclas de função, duplo clique no mouse, função de volta em sistemas hipertexto.
• Atalhos também servem para recuperar informações que estão numa profundidade na árvore navegacional a partir da interface principal.

8) Diálogos simples e naturais

• Deve-se apresentar exatamente a informação que o usuário precisa no momento, nem mais nem menos.
• A seqüência da interação e o acesso aos objetos e operações devem ser compatíveis com o modo pelo qual o usuário realiza suas tarefas.

9) Boas mensagens de erro

• Linguagem clara e sem códigos.
• Devem ajudar o usuário a entender e resolver o problema.
• Não devem culpar ou intimidar o usuário.

10) Ajuda e documentação

• O ideal é que um software seja tão fácil de usar (intuitivo) que não necessite de ajuda ou documentação.
• Se for necessária a ajuda deve estar facilmente acessível on-line.

Comente este post

A técnica de criação de personas aliado à técnica de cenários são as melhores respostas para essas perguntas. É barato, é fácil e divertido para a equipe de desenvolvimento e não tem contra-indicação.

Em resumo, os dados coletados sobre as pessoas na etapa de pesquisa são utilizados para construir modelos de usuários que servirão como critérios para a adequação do projeto. Ao invés de tentar projetar para uma grande quantidade de pessoas e nivelar por baixo para ter segurança, com personas, projeta-se para um número bem pequeno de usuários fictícios, porém representativos.

As vantagens dessa técnica são:

• engaja e conscientiza a equipe de projeto
• chega-se a um consenso dos interesses do usuário
• mantém o foco no usuário durante todo o projeto
• agiliza a tomada de decisões porque não é preciso consultar usuários reais a cada etapa do projeto

A persona é como uma ficha de personagem de RPG do usuário-modelo criado a partir de dados reais. Contém seu nome, seus gostos, seus hábitos, suas habilidades e etc. Essas informações podem ser obtidas através de entrevistas com usuários potenciais ou através de conversas com quem lida frequentemente com esse público. Um vendedor de telefones celulares sabe bem como é o comportamento dos consumidores desse produto, então é uma fonte muito rica para coletar dados para a persona. Basta perguntar a ele quais são as dificuldades que os consumidores mais tem, do que eles gostam, como tratam o vendedor e etc.

Nas entrevistas com usuários, entretanto, as perguntas não devem ser tão diretas. Além das perguntas objetivas sobre dados socio-econômicos, o entrevistador precisa descobrir quais são as expectativas do usuário em relação ao artefato que está sendo projetado.

• Será que ele vai ter tempo para aprender como usá-la melhor?
• Será que ele se importa com a aparência?
• Que cores odeia?
• O que tem medo que aconteça enquanto usa um artefato como esse?

Essas perguntas devem ser respondidas pelos usuários, mas não necessariamente devem ser feitas nessas palavras, diretamente. É melhor começar por uma pergunta aberta, do tipo: "qual é a primeira coisa que você faz quando se conecta à Internet?" Lembre-se de que a entrevista não é um inquérito; é uma conversa e quanto mais histórias forem contadas, melhor. Afinal, uma persona é exatamente isso: uma história particular. Por esse motivo é mais importante que as entrevistas sejam qualitativas do que quantitativas. É melhor ouvir bem meia dúzia de pessoas, do que ser superficial com duas dúzias.

Depois das perguntas mais abertas, é possível ir entrando nos detalhes, tão valiosos. "Quer dizer que você abre primeiro o email? E quantas vezes por dia você faz isso? Você recebe muito spam?" e por aí vai. Quando o usuário contar um causo peculiar que aconteceu com ele usando um artefato similar, ou relacionado à atividade em questão, anote bem anotado. Histórias permanecem muito mais tempo na memória do que dados estatísticos .

Baseado no livro de Alan Cooper que primeiro apresentou esta técnica, seguem as dicas mais quentes para criar personas úteis:

• identifique o fluxo de trabalho (workflow) e os padrões de comportamento em detalhes
• especifique a habilidade com informática
• inclua detalhes sobre a vida da pessoa para torná-la mais fácil de memorizar. Escolha alguns detalhes bem pessoais, só para torná-la mais interessante
• não use uma pessoa conhecida como uma persona. Além de expor a pessoa, acorrenta as características da persona à pessoa real. Crie um arquétipo baseado em pesquisas e dados, mas seja realista
• mantenha o número de personas pequeno, entre 3 e 7, dependendo da variedade do público. Quanto mais personas, mais risco de interesses conflitantes, confusão, etc
• não recicle as personas para novos projetos. Cada persona é feita especificamente para o seu projeto
• não viaje na maionese ou então a persona perde credibilidade

Comunicação interna

Personas são um meio muito eficaz de comunicação interna da equipe. Na Microsoft por exemplo, esse método é muito utilizado nos projetos de software. Eles criam cartazes atraentes comparando as características das personas, imprimem camisetas, bonés e até mesmo canecas com os seus rostos, tudo para lembrar constantemente a equipe do foco do projeto.

Outro ponto forte das personas é sua capacidade de concisão para apresentar resultados de pesquisa. No ritmo agitado da produção tecnológica, poucos são os que tem tempo (e interesse) em ler relatórios de dezenas de páginas sobre os estudos de usabilidade, as etnografia e as pesquisas de mercado do marketing.

As personas se aproveitam do poder das narrativas para aumentar a atenção, a memorização e a organização dos dados coletados sobre os usuários. E quando uma descoberta importante é feita sobre, é muito mais fácil comunicar a equipe toda, por exemplo: "o Adalberto não está conseguindo usar a ferramenta de busca na nossa página" é muito melhor do que "uma quantidade representativa dos participantes de testes de usabilidade tiveram problemas com a ferramenta de busca".

É possível que o criador das personas se sinta tentado a usar caricaturas para torná-las ainda mais atrativas. Em geral, as pessoas acham mais fácil encontrar o meio termo quando lhe são apresentadas os extremos porque podem julgar pelo senso-comum. Entretanto, essa abordagem corre o risco de levar as decisões para longe da realidade, desviar do sentido original das personas que é orientar o design centrado em usuários reais. Outro problema é que isso pode levar a discriminaçõs de ordem social, como por exemplo tirar sarro de deficientes físicos e outros perfis diferentes. Não é porque a persona é fictícia que deixamos de tratá-la como um ser humano de verdade, com todos os seus direitos.

As personas podem, por outro lado, ter efeito funesto ao projeto se forem manipuladas a esmo ou não levadas a sério. A tentação de criar e alterar a persona de acordo com o que for mais cômodo para a equipe ou para um profissional em particular pode ser desastrosa. Por isso, vale ressaltar que cada detalhe da persona deve estar muito bem embasado em dados reais, não em meras presunções.

Cenários

Os cenários, ao contrário, são descrições de legítimas situações hipotéticas em que são colocadas pessoas que interessam ao projeto. Essa técnica é usada de maneiras muito diferentes. Alguns utilizam para auxiliar numa decisão crucial de projeto, para avaliar as características do projeto, para demonstrar as características do artefato projetado em uso e etc.

O cenário pode se escrito formalmente, servindo como documentação de projeto, ou ser criado enquanto se discute questões de projeto. Utilizo muito essa técnica durante reuniões em que são discutidas as funcionalidade do artefato e quando preciso defender ou justificar um fluxo de interação.

Provavelmente você já até utilizou essa técnica e nem sabia que tinha um nome. O que se segue a essa frase é um cenário: "suponha que o usuário faça isso, então..."

Melhor do que utilizar um usuário genérico num cenário é utilizar um usuário definido, pois assim se pode avaliar melhor a pertinênica do cenário. Cenários muito desconexos da realidade são interessantes no início de projeto, quando o conceito do artefato ainda está em questão, mas nas demais etapas de desenvolvimento, é preciso estar cada vez mais conectado com a realidade empírica de uso.

Usando, por exexmplo, uma persona chamada Mariana que é contadora, podemos criar o seguinte cenário:

Mariana quer abrir uma pasta num sistema operacional e acessar um memorando de orçamentos. Entretanto, a pasta está cheia de planilhas que ela quer conferir enquanto lê o memorando. As planilhas são tão grandes que quase ocupam toda a tela. Ela pára, franze a testa, e pensa por alguns segundos. Redimensiona a planilha, move-a parcialmente para fora da tela, abre a pasta, abre o memorando, redimensiona e reposiciona o memorando para continuar a trabalhar, aliviada.

O cenário poderia também criar uma situação ambiental adversa, como por exemplo:

Mariana precisa fazer uma planilha com cálculos corriqueiros numa sala com várias outras pessoas falando alto. Ela não consegue se concentrar direito e precisa terminar o trabalho logo. Resolve procurar alguma forma automatizada de inserir os dados. Por sorte, o software possui assistentes para inserir dados passo-a-passo e fazer os cálculos mais comuns. A ajuda dá conta do recado, embora o processo todo tenha demorado mais do que se ela tivesse feito como sempre faz, manualmente.

Num projeto simples, os cenários não precisam ser necessariamente oficializados, escritos. Eles podem surgir no meio de conversas da equipe, ou apenas na mente do designer. O mais importante é estar colocando à prova o jogo de cintura da aplicação. Isso se torna especialmente importante nos momentos tensos da aplicação: formulários complexos, negociações financeiras, tratamento de erros e etc.

Cenários com personas

Cenários não se baseiam em dados reais, são apenas imaginados, previstos. No entanto, se criados para dar vida às personas, eles não levarão a concepções errôneas. Se a persona estiver bem baseada na realidade, o cenário também estará e, consequentemente, a situação prevista terá alta probabilidade de se realizar.

Durante os testes de usabilidade com usuários reais, os cenários podem ser reaproveitados para criar tarefas específicas e verificar se os usuários conseguem mesmo resolver os problemas. É por isso que aconselho a usar os cenários o mais cedo possível no projeto. Antes mesmo de qualquer protótipo, o designer já deve ter na cabeça os pontos do artefato em que o usuário pode se bater para encaminhar para a avaliação.

Apresentando esses cenários para os colegas da equipe, ele já pode iniciar discussões produtivas sobre o design. Não fica aquela conversa mole de "eu acho que ficaria melhor um vermelhinho naquela caixa". É muito mais interessante dizer que "o vermelho na caixa pode ter conotação de alarme para o usuário Marcos e fazê-lo parar seu fluxo de trabalho".

Para ver um exemplo prático de aplicação destas técnicas, veja as personas e os cenários criados para o redesign do Usabilidoido versão Seurat.

Livros que eu ainda quero ler

Comente este post