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:
- Steve Krug. "Não Me Faça Pensar"
- Google. "Ten principles that contribute to a Googley user experience"
- Wikipedia. "Usabilidade"
- Chris Parsons. "UX is everything"
17 comentários:
Muito legal. Parabéns.
bommmm
Muito bom!
Acredito que quando se trata de software para humanos normais, menos é mais. Isso é especialmente verdade na interface. Quanto mais opções e configurações, pior para ele. Ninguém que compra um carro novo espera ter que fazer várias configurações técnicas(sensibilidade do freio, aceleração do motor, etc) antes de dar o passeio inaugural. Isto fica para os aficionados por carros. Mas infelizmente no software muitas vezes acontece isso. Em parte pq o desenvolvedor é um aficionado por software.
Lembro que quando eu liguei para o gerente deste mesmo banco com esta dúvida, ele me ensinou esse procedimento como sendo um 'macete' rsrs
Chega de escrever senão vai acabar como um post...
Ótimo artigo!
Recentemente fui fazer um resgate de prêmios do cartão de crédito e era necessário fazer um cadastramento de novo usuário. Um dos ítens a ser marcado era se era ou não correntista do banco. Entende-se que para prosseguir não é necessário ser correntista. No entanto ao completar o último campo que é criação de senha de acesso eu não consegui prosseguir porque eu NÃO sou correntista. Por quê eu tive que gastar o meu tempo preeenchendo todo o resto? Essas coisas me tiram do sério. Convivendo com você e ouvindo suas idéias de usabilidade eu me tornei tbém uma super crítica de coisas mal feitas. Há certos programadores que deveriam ser banidos do universo.
Concordo plenamente com post, todavia em alguns casos, na minha opinião, o usuário não é um ameba. Acho que cada um sabe sobre alguma coisa na vida. Por exemplo, ao dizer para um usuário configurar uma impressora, para quem é da área ou até mesmo para quem tem conhecimentos básicos em informática, é uma tarefa extremamente fácil. Mas para um usuário, que ainda não teve esse treinamento, pode ser algo um tanto complicado. Costumo dizer que não existem pessoas ignorantes(do ponto de vista de falta de conhecimento), existem pessoas que por algum motivo não tiveram oportunidade de aprender determinada coisa...Citando o caso anterior, o usuário não é uma ameba, por não saber instalar/configurar uma impressora. Agora já casos de profissionais da área de TI, não saber de coisas que deveriam estar "carecas" de saber...isso sim é ser um ameba...
abs
Álvaro
Gostei muito do Artigo, bem como dos outros.
Realmente algums programas poderiam ser mais fáceis e intuitivos.
Lembro que comprei uma TV nova, Full HD de 42 polegadas. Ao chegar em casa e a liguei, a unica coisa que vi foi uma tela preta, sem nenhuma informação, em todos os canais. Imaginei que estivesse quebrada e fiquei decepcionado. Como era noite, não teria como levá-la a loja para devolver, então comecei a ler o manual. Qual não foi minha surpresa, ao chegar a quinta página, que eu precisaria apertar uma sequencia de teclas no controle remoto para que ela se programasse.
teria sido bem mais simples se essa informação fosse mostrada na tela inicial. Como podemos ver, as vezes pequenas mudanças geram grandes facilidades.
Uau, quantos comentários caprichados! É muito bom ver gente nova comentando. Gostei de vê-los compartilhar suas experiências com interfaces que fazem o usuário pensar.
Valmir, Lidi, Álvaro, Israel e anônimos, obrigado pelos comentários!
Gostei especialmente do que o Álvaro disse: "em alguns casos... o usuário não é um ameba" :D
PS: Se houver algum leitor tímido escondido, fique à vontade e deixe seu comentário também :)
Trabalho com suporte técnico em um sistema ERP. Na maioria dos casos, o que falta aos usuários é conhecimento do próprio trabalho. Acredito que 80% das ligações telefônicas e e-mails que recebo solicitando suporte, são por exemplo: "O que é uma nota fiscal?" quando a pergunta deveria ser "como eu faço a emissão de uma nota fiscal no sistema?". Mas analisando a fundo, a culpa não é desses usuários, é de quem os coloca na função sem a mínima preparação, conhecimento, etc. É isso. Abraço a todos.
Muito pertinente seu comentário, amigo. E concordo contigo. Quem recruta esses funcionários e/ou não os treina adequadamente tem uma grande parcela de culpa. Nesses casos, mesmo que o desenvolvedor dê a devida atenção a usabilidade do software, ainda haverá demanda de suporte por falta de conhecimento dos usuários sobre o negócio.
Se o software não é desenvolvido pela mesma empresa que o utiliza, isso não é necessariamente ruim, pois abre a possibilidade de se vender treinamento sobre o negócio. Se isso não for feito, deve-se levar em consideração o nível de conhecimento dos usuários na hora de planejar o valor do contrato de suporte.
Obrigado pelo seu comentário! Um abraço.
Excelente!!!
Trabalhei fazendo manutenção num sistema que tinha um formulário medonho! Tinha diversas opções, que internamente no método, dependendo das combinações uma função era desempenhada. Enfim, era uma planilha aberta disfarçada de formulário pois era só escolher e fazer cagadas sobrenaturais daquelas que quando o rapaz da informática (era eu) vai apurar passa mal!
O programador (dono) acha esse formulário o masterpiece!
Como quero ter filhos ainda larguei essa merda. ¬¬'
Hahaha... essa de largar o trabalho porque quer ter filhos foi boa! Obrigado pelo comentário. Um abraço, Leandro!
Muito bom o blog..
Parabens!
Valeu, Renan!
Muito bom, parabéns
Obrigado, Carina!
Bem,estava lendo o artigo e idealizando tudo que também ja pensei com relação ao "Não fazer o usuário pensar".O exemplo do banco foi ótimo,pois eu ja quis fazer exatamente isso,e não permitia....
Muito bom...Mais uma vez está de parabéns!
Muito obrigado Suelen, fiquei feliz ao ver seu comentário por aqui. =)
Um abraço!
Postar um comentário