14 de agosto de 2010

Não faça o usuário pensar

Aos dezessete anos de idade consegui meu primeiro emprego como programador. Foi numa pequena empresa que desenvolvia software para outras pequenas empresas. Os usuários desses softwares eram, na sua esmagadora maioria, quase totalmente leigos em informática. Esse cenário fez com que o seguinte conselho do meu então chefe fosse pertinente:

“Nunca duvide da capacidade de um usuário ser uma “ameba”.”

Em outras palavras, meu chefe não queria que eu deixasse brechas nos softwares para que os usuários cometessem um erro. Se houvesse uma única chance de um usuário fazer uma besteira, isso seria suficiente para algo dar errado. Era a Lei de Murphy.

Um motivo mais nobre

Anos mais tarde, depois de desenvolver diversos projetos de software para os mais variados perfis de usuários, e depois de me tornar um forte crítico de todos os softwares que uso e desenvolvo, me dei conta de que há um motivo, digamos, mais nobre, para não exigir muito raciocínio dos usuários dos softwares que faço:

“Meu software é apenas o meio pelo qual os usuários resolvem seus problemas.”

Ou seja, os usuários querem pensar apenas sobre os seus próprios problemas, sejam eles as suas compras, vendas, cobranças, pagamentos, reposições de estoque etc. Eles não querem ter que pensar sobre o meu software. Se meu software exigir que eles pensem em coisas que não são os seus problemas, isso significa que não fui eficiente em projetar um software que facilite sua vida.

Facilitando a vida dos usuários

Um software que facilite a vida dos usuários vai além de resolver os seus problemas (ou “atender aos requisitos funcionais”). Ele os conduz pelo caminho necessário de forma que se sintam confiantes de que estão fazendo a coisa certa. Suas escolhas são praticamente impensadas de tão óbvias. Isso traz à tona a importância de algo que não é levado em consideração por muitos desenvolvedores de software: a Usabilidade.

Como diz meu amigo Valmir Santana, uma boa imagem vale mais que 1024 palavras. Então vamos analisar algumas imagens em dois exemplos de usabilidade.

O exemplo ruim

O exemplo ruim tirei do internet banking do banco onde concentro minhas transações financeiras. Eventualmente me sobra algum dinheiro na conta corrente e eu o transfiro para a poupança, que tem o mesmo número da conta corrente. A interface onde realizo essa operação não é intuitiva como poderia ser. Vejamos:

Suponha que eu queira transferir R$1000 da conta corrente para a conta poupança. Consigo fazer isso através dessa interface? Bem, a primeira informação apresentada (dentre muitas) diz que se eu precisar de um limite maior para transferências, preciso utilizar a opção “Transferência entre Contas Cadastradas”. Mas qual é o limite??? Preciso ler o restante do texto para descobrir que o limite diário é de R$500 (note que a ordem das informações está invertida: primeiro se informa o que fazer quando o valor de transferência é superior ao limite e só depois se informa qual é o limite).

De qualquer forma, esse limite NÃO se aplica ao tipo de transferência que quero fazer - entre uma conta corrente e uma poupança com mesmo número. E o cadastramento de contas para transferências com limite superior a R$500 também NÃO se aplica ao meu caso. Mas como descobrir isso? A interface não me ajuda (eu descobri por tentativa e erro).

Percebeu o quanto foi preciso pensar desnecessariamente no software para “resolver o meu problema”?

Agora veja uma outra parte dessa mesma interface:

Por que eu precisaria informar o número da agência e conta destino se ele é exatamente o mesmo da conta origem?

O bom exemplo

Quando resolvi passar a ler os meus e-mails do Yahoo! a partir da minha caixa de entrada no GMail, fiquei bastante impressionado ao ver como foi mais fácil fazer isso no GMail do que em clientes de e-mail como o Outlook e Thunderbird.

Veja qual a primeira coisa que o GMail me solicitou no seu amigável e sucinto wizard.

Essa é a única informação necessária para começar. Note que, com base no e-mail fornecido, algumas informações foram automaticamente deduzidas.

Um usuário inexperiente poderia facilmente ficar confuso se tivesse que fornecer o endereço e a porta do servidor POP, mas o Gmail sabe deduzir essas informações para o usuário. Por outro lado, se as informações deduzidas não estiverem corretas, é possível para o usuário alterá-las. Continuando...

Essa última captura é a que mais me impressionou. O GMail me ofereceu a possibilidade de enviar e-mails do Yahoo! usando um servidor SMTP do próprio GMail. Neste caso, nem preciso saber qual é o endereço SMTP do GMail – o software por trás dessa interface me poupa da necessidade de conhecer esse dado. Por outro lado, se eu quiser informar o endereço SMTP do Yahoo! poderei fazer isso sem problemas, mas note que a interface foi projeta para o cenário mais fácil e mais provável.

Conclusão

Projetar interfaces como no bom exemplo acima, não é subestimar a inteligência do usuário. É fazê-lo não pensar no software desnecessariamente. O usuário avançado perceberá a facilidade e sentirá que foi levado em consideração quando essa interface foi projetada. O usuário leigo talvez não perceba o quanto foi mais fácil resolver seu problema - ele só sabe que não teve dificuldade para conseguir o que queria, o que é o suficiente. Um software assim passa confiança para o usuário.

A qualidade interna do software sem dúvida é importante, mas ela não significará nada para o usuário se a interação dele com o software for sofrível. Se o usuário frequentemente se pergunta “Será que dá pra fazer X?” ou “Onde será que fica Y?” ou “Como faço Z?” a qualidade do software percebida por ele será baixa.

Portanto, ao projetar interfaces de usuário, seja em sistema web, mobile ou desktop, lembre-se:

  • Usuários precisam ter a confiança contínua de que estão no caminho correto.
  • Tornar as escolhas mais claras é uma das principais coisas que tornam um software mais fácil de ser usado.

Gostou do que leu? Deixe seu comentário.

Crédito da foto: Jessy Ratfink

Referências:

Postar um comentário