Joel on Software

Joel on Software Joel sobre Software

 

Projeto de Interface com Usuário para Programadores
Capítulo 1
Capítulo 2
Capítulo 3
Capítulo 4
Capítulo 5
Capítulo 6
Capítulo 7
Capítulo 8
Capítulo 9

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

 

Projeto de Interface com Usuário para Programadores
Capítulo 6: Projetando para Pessoas que Tu Coisas Melhores para Fazer com Suas Vidas


Por Joel Spolsky
Traduzido por Rosana de Oliveira
26 de Abril de 2000

Quando você projeta interfaces para usuário, é uma boa idéia manter dois princípios em mente:

  1. Usuários não tem o manual, e se tivesse, eles não o leriam.
  2. De fato, usuários não podem ler nada, e se eles pudessem, eles não iriam querer.

Estes não são, a rigor, fatos, mas você deveria agir como se eles fossem fatos, e isto deixará o seu programa mais fácil e mais amigável. Projetar com estas idéias em mente é conhecido por respeitar o usuário, que significa, não ter muito respeito pelo usuário. Confuso? Deixe-me explicar.

O que significa fazer alguma coisa fácil de usar? Um modo de medir isto é ver qual a porcentagem de usuários do mundo real são capazes de completar as tarefas em uma dada quantidade de tempo. Por exemplo, suponha que o objetivo do seu programa é permitir que as pessoas convertam fotos de câmara digital em um albúm de fotos da web. Se você pegar um grupo de usuários médios com seu programa e pedir a eles que completem esta tarefa, desde modo quanto mais amigável o seu programa for, maior a porcentagem de usuários que serão capazes de criar um albúm de fotos para web com sucesso. Para ser científico sobre isto, imagine 100 usuários do mundo real. Eles não estão necessariamente familiarizados com computadores. Eles têm muitos talentos diversificados, mas alguns deles distintamente não têm talentos na área de computador. Alguns deles estão desesperados enquanto eles tentam usar o seu programa. O telefone está tocando. O QUE? O bebê está chorando. O QUE? E o gato continua pulando em cima da mesa e caçando o rato. EU NÃO POSSO OUVIR VOCÊ!

Agora, mesmo sem ir a fundo com estes experimentos, eu posso afirmar com alguma confiança que alguns dos usuários irão simplesmente falhar para completar esta tarefa, ou levarão uma quantia extraordinária de tempo para fazer isto. Eu não quero dizer que estes usuários são estúpidos. Muito pelo contrário, eles são provavelmente muito inteligentes, ou talvez eles são atletas talentosos, mas em relação ao seu programa, eles simplesmente não estão aplicando toda sua capacidade motora e células cerebrais para o uso do seu programa. Você está obtendo somente cerca de 30% de suas atenções, então você tem que fazer como se o usuário, de dentro do computador, não pareça estar jogando com cartões de processamento de dados.

Usuários não lêem o Manual.

Antes de tudo, eles realmente não têm o manual. Pode não existir um manual. Se existir um, o usuário pode não ter, por todos os tipos de razões lógicas: eles estão no avião; eles estão usando uma versão que foi baixada do seu web site; eles estão em casa e o manual está no trabalho; o Departamento de Informática nunca entregou o manual. Mesmo se eles tem o manual, francamente, eles simplesmente não vão ler a menos que eles absolutamente não tenham outra opção. Com muito poucas exceções, usuários não irão pegar o seu manual e ler inteiro antes que eles comecem a usar o seu software. De modo geral, seus usuários estão tentando obter alguma coisa pronta, e eles vêem a leitura do manual como uma perda de tempo, ou na melhor das hipóteses, como uma distração que os mantêm distante de terminar suas tarefas.

O simples fato de você estar lendo este livro o coloca em um grupo de elite de pessoas altamente culta. Sim, eu sei, pessoas que usam computadores são e muito capazes de ler, mas eu garanto a você que uma boa porcentagem deles achará que a leitura é um martírio. A linguagem no qual o manual está escrito pode não ser sua língua materna, e eles podem não ser totalmente fluentes. Eles podem ser crianças! Eles podem decifrar o manual se eles realmente precisarem, mas eles acharam que não vão ler se eles não forem obrigados. Usuários fazem a leitura superficial do manual, em uma situação estritamente necessária.

O resultado de tudo isto é que você provavelmente não tem escolha a não ser projetar o seu software de modo que ele não necessite de um manual em primeiro lugar. A única exceção que eu posso pensar é se seus usuários não têm nenhum domínio do assunto -- eles realmente não entendem o que o programa pretende fazer, mas eles sabem que é melhor que eles aprendam. Um bom exemplo disto é o imensamente popular programa de contabilidade para pequenas empresas o Intuit do QuickBooks. Muitas das pessoas que usam este programa são proprietários de pequenas empresas que simplesmente não têm idéia do que está envolvido em contabilidade. O manual do QuickBooks assume isto e assume que terá que ensinar para as pessoas princípios básicos de contabilidade. Não há outra maneira de fazer isto. Ainda, se você conhece contabilidade, QuickBooks é fácil de usar sem o manual.

Na verdade, usuários não lêem nada

Isto pode soar um pouco severo, mas você verá, quando você faz teste de usabilidade, que existe uma quantia pequena de usuários que simplesmente não lêem as palavras que você coloca na tela. Se você exibir uma mensagem de erro de qualquer espécie, eles simplesmente não lerão. Isto pode ser desconcertante para você como um programador, porque você se imagina como se estivesse conduzindo um diálogo com o usuário. Ei, usuário! Você não pode abrir aquele arquivo, nós não suportamos aquele formato de arquivo! Apesar disso, a experiência mostra que quanto mais palavras você coloca naquela mensagem, menor o número de pessoas que realmente lerão.

O fato que usuários não lêem o manual faz com que muitos designers de software assumam que eles vão ter que educar os usuários descrevendo as coisas a medida que elas aparecem. Você vê isto em todo lugar nos programas. No princípio, tudo bem, mas na realidade, a aversão das pessoas na leitura significa que isto quase sempre deixa você com problemas. Designers de IU experientes literalmente tentam minimizar o número de palavras nas caixas de diálogo para aumentar as chances delas serem lidas. Quando eu trabalhei no Juno, o pessoal da IU entendia este princípio e tentava escrever o mínimo possível, claro, com texto simples. Infelizmente, o CEO da companhia tinha uma graduação em Inglês na faculdade Ivy League; ele não tinha treino em design de IU ou engenharia de software, mas ele certamente pensou que ele era um bom editor de prosa. Então ele vetou os textos feitos pelos profissionais de designers de IU e adicional vários textos de sua própria autoria. Uma caixa de diálogo típica da Juno se parece com isto:

Compare esta com o equivalente do Windows:

Intuitivamente, você pode pensar que a versão do Juno, com 80 palavras de instruções, seria "superior" (i.e., mais fácil de usar) que a versão do Windows, com 5 palavras de instruções. Na realidade, quando você roda um teste de usabilidade neste tipo de coisa, você descobrirá que

  • usuários avançados passam direto pelas instruções. Eles assumem que sabem como usar as coisas e não têm tempo para ler instruções complicadas
  • usuários mais novatos passam direto pelas instruções. Eles não gostam de ler muito e esperam que os defaults estarão OK
  • o restante dos usuários novatos que o fazem, cuidadosamente, que tentam ler as instruções (alguns deles somente estão lendo porque é um teste de usabilidade e eles se sentem obrigados) são frequentemente confundidos pelo absoluto número de palavras e conceitos. Até mesmo se eles estão totalmente confiantes que eles seriam capazes de usar a caixa de diálogo quando ela aparecesse, as instruções realmente confundiriam ainda mais.

Agora, Juno foi obviamente micro-gerenciada além de todas as razões. Voltando ao ponto, se você é um mestre em Inglês pela Columbia, então você está em uma liga completamente diferente da literatura do que a média Joe, e você deveria ser muito cuidadoso sobre textos em caixas de diálogo que parecem ajudá-lo. Diminua-a, cale-se, simplifique, se livre de parágrafos complicados entre parênteses, e faça teste de usabilidade. Mas não escreva coisas que parecem com memorandos da faculdade Ivy League. Até mesmo adicionar a palavra "por favor" em uma caixa de diálogo, que pode parecer útil e educado, vai desanimar as pessoas: o aumento de volume de texto vai reduzir, por alguma porcentagem mensurável, o número de pessoas que lêem o texto.

Outro ponto importante é que muitas pessoas ficam intimidadas pelos computadores. Você provavelmente sabe disto, certo? Mas você não pode perceber as implicações disto. Eu estava vendo uma amiga tentar sair do Juno. Por alguma razão ela estava tendo um pequeno problema. Eu notei que quando você tenta sair do Juno, a seguinte mensagem aparece:

Ela estava selecionando No, e então ela ficou surpresa que o Juno não tinha saído. O simples fato de que o Juno estivesse questionando sua escolha fez com que ela imediatamente assumisse que ela estava fazendo alguma coisa errada. Geralmente, quando programas pedem a você para confirmar um comando, é porque você está para fazer alguma coisa no qual você pode se arrepender. Ela assumiu que se o computador estava questionando o seu julgamento, então o computador devia estar certo, porque, afinal de contas, computadores são computadores onde ela era meramente uma humana, então ela selecionou "No."

É demais pedir que as pessoas leiam 11 palavras desagradáveis? Bem, aparentemente sim. Antes de tudo, já que sair do Juno não tem nenhum efeito nocivo, Juno deveria ter saído sem solicitar a confirmação, como todo programa de GUI existente. Mas se você está convencido que é crucial que as pessoas confirmem antes de sair, você poderia fazer isto em duas palavras ao invés de 11:

Sem o completamente desnecessário "obrigado" e o sentimento de remorso "você tem certeza?", esta mensagem é menos provável de causar problemas. Os usuários certamente lerão as duas palavras, e dirão "hum?" para o programa, e selecionarão a tecla Yes.

Certamente, a mensagem de Confirmação para sair do Juno confunde umas poucas pessoas, você diz, mas isto é tão importante? Todo mundo irá eventualmente conseguir sair do programa. Mas neste lugar consiste a diferença entre um programa que é possível usar versus um programa que é fácil de usar. Até mesmo usuários espertos, experientes, avançados apreciarão coisas que você faz para torná-lo fácil para o usuário distraído, inexperiente, iniciante. As banheiras de Hotel têm grandes barras. Elas estão lá para ajudar pessoas com dificuldades, mas todo mundo usa as barras para sair da banheira. Elas tornam a vida mais fácil até mesmo para o exercício físico.

No próximo capítulo, eu falarei um pouco sobre o mouse. Exatamente como os usuários não lêem/não lerão/não podem ler, alguns não são bons para usar o mouse, então você tem que adaptá-los.



> Capítulo 7

Esse artigo apareceu originalmente em Inglês com o título User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky