Por Scott Berkun, Nov 1999
“Uma consistência tola é o duende das mentes pequenas” – Emerson
As pessoas não gostam de aprender coisas. Se dedicarem tempo a aprender algo, esperam ser capazes de aplicar esse conhecimento em muitos lugares. Segue-se que os bons designers conservam o número de coisas que os utilizadores precisam de aprender para conseguir fazer as coisas. As ruas das cidades americanas são bons exemplos de conservação do conhecimento. Em qualquer parte da América, os sinais de ceder e parar parecem exactamente os mesmos. Os sinais de trânsito usam vermelho, amarelo e verde para significar exactamente as mesmas coisas, independentemente da rua ou cidade. As caixas de correio nas esquinas das ruas utilizam as mesmas cores e ícones, pelo que são claramente identificáveis em qualquer lugar. Torna-se difícil para as pessoas quando o seu conhecimento das coisas se desfaz. Um motorista de um país com sinais de rua diferentes que visite a América cometerá erros até aprenderem os novos sinais. Mesmo variações subtis como a diferença de velocidade de dois semáforos amarelos diferentes podem levar os condutores americanos a cometer erros.
As regras das ruas aplicam-se ao design da web e a todas as formas de design de interface. Se uma aplicação nomear uma peça de funcionalidade “imprimir”, os utilizadores esperam que o significado de “imprimir” seja o mesmo em toda a aplicação. Num sítio Web, se o utilizador vir o ícone do carrinho de compras no canto superior direito, esperará vê-lo no mesmo local, com a mesma aparência, em todas as páginas desse sítio Web, se não em todos os sítios Web que visitar. A consistência não só beneficia o utilizador, como também os designers e programadores. Uma vez que o comando “imprimir” tenha sido nomeado pelo designer, o programador não tem de passar mais tempo a pensar em como nomeá-lo. Se houver código para o seu comando de impressão, este pode ser reutilizado em qualquer lugar dentro da aplicação. A consistência é maravilhosa quando utilizada adequadamente, porque melhora a experiência tanto dos programadores como dos seus utilizadores.
Quando a consistência é má?
Em casos raros, a consistência pode tornar-se um monstro auto-perpetuador: Tem de ser utilizada para um fim. Uma consistência tola é aquela que não serve nenhum benefício para o utilizador final. Fazer com que as coisas pareçam e funcionem da mesma maneira é inútil se o utilizador já não conseguir cumprir as suas tarefas. Classificação que torna as coisas úteis acima de torná-las consistentes. Um exemplo são as interfaces para jogos de vídeo. Imagine que a sua empresa estava a desenvolver dois jogos de vídeo, um jogo de condução e um jogo Pac-Man. A melhor interface para o jogo de condução seria um volante, mas o jogo Pac-Man funcionaria melhor com um joystick e alguns botões. Tentar conceber uma IU para utilizar em ambos estes jogos seria um desastre. Na melhor das hipóteses, chegar-se-ia a um meio-termo que não era bom em nada. A coerência aplicada a certas tarefas do utilizador pode tornar a experiência do utilizador pior, não melhor. A coerência não garante a usabilidade. Geralmente ajuda uma interface do utilizador, mas não há garantias na concepção da interface. Neste exemplo de videojogo teria de escolher entre o custo do utilizador de aprender duas IU especializadas diferentes contra aprender uma IU que pudesse voltar a aplicar mas que não fosse bem adequada a nenhuma das tarefas que desejasse fazer.
No exemplo do semáforo, o tempo da luz amarela num cruzamento de quatro vias poderia ser alterado pelos engenheiros para compensar os padrões de tráfego específicos de um cruzamento. Uma luz amarela mais longa num sentido pode dar à estrada mais movimentada mais tempo para fazer passar os carros do que a outra estrada com menos tráfego. É uma contrapartida de uma optimização local em vez de uma simplificação global. A resolução de um problema local grave pode valer a pena criar um problema global menor. Ter bons dados sobre a forma como as coisas são utilizadas, como os dados de tráfego para o cruzamento, é a chave para tomar estas decisões. É preciso ser claro quanto aos prós e contras de cada extremo do compromisso, e tomar as melhores decisões para a característica em relação a todo o produto. Por vezes, a coerência global é a escolha certa. Por vezes, o melhor é optimizar localmente.
Quando a consistência é boa na Web?
Consistência é óptima porque as pessoas gostam de coisas previsíveis. Elas sentir-se-ão confortáveis quando puderem confiar em diferentes partes do seu produto para fazer exactamente o que pensam que ele fará. Um erro comum no design de um website é pegar num elemento de interface existente no HTML e optimizá-lo para um website. Um exemplo é a caixa de listagem fornecida pelo HTML para escolher a partir de uma lista de escolhas. O comportamento padrão é que o utilizador tem de escolher um item da lista, e depois clicar num botão OK para confirmar a escolha. Alguns sítios Web utilizam Javascript para fazer o menu pendente confirmar automaticamente a escolha, poupando ao utilizador o clique extra de clicar em OK . Independentemente de todas as outras coisas, este desenho pode funcionar bem. Mas como este controlo modificado parece semelhante ao controlo por defeito utilizado na web, os utilizadores de Windows e Macintosh nunca sabem o que esperar e são susceptíveis de cometer erros. A lição aqui é que se uma modificação a um controlo normalmente consistente causar custos de reaprendizagem e erros, provavelmente não vale a pena, especialmente se estiver apenas a poupar ao utilizador um único clique. A Web é um mau lugar para optimizações como esta, porque sabemos que os utilizadores visitam muitos sítios Web durante uma sessão, e a maioria deles não terá o seu novo design.
Tive discussões com designers de sítios Web que sentem que a consistência é coisa do passado, e que o design de sítios Web é uma nova fronteira onde a consistência importa menos. É uma lógica ténue. A forma como os seres humanos interagem com o mundo não muda quando a tecnologia o faz, será sempre baseada em ver, tocar e ouvir coisas, e usar o nosso cérebro para interpretar o significado dessas coisas. Os seres humanos tenderão naturalmente a reaplicar o conhecimento aprendido, e os bons designers usarão isto para fazer melhores designs. A criatividade é óptima se o resultado for algo mais valioso ou útil para os utilizadores, mas se o único resultado for que os designers/desenvolvedores são mais felizes com as suas carteiras, então estão a desenhar para si próprios, não para os seus utilizadores.
A questão chave é se uma aplicação específica de consistência é útil e não tola. Quando penso em interfaces na Web, recordo os primeiros tempos das interfaces GUI. Uma das melhores características dos sistemas operativos Windows e Macintosh era a utilização de uma barra de menu padrão para todas as aplicações. Pode ter reduzido alguma da criatividade das aplicações na forma como apresentavam os comandos, mas facilitou muito a vida dos programadores e utilizadores porque podiam reutilizar coisas que já tinham aprendido. Neste caso, a vitória global de uma forma consistente de apresentar comandos aos utilizadores compensou qualquer valor possível de uma aplicação fazer algo maravilhoso, mas não foi partilhada por outras aplicações. É sempre uma troca, e isto significa que os designers têm sempre de considerar os efeitos da procura de consistência.
The Bottom Line: Regras de Polegar para a Consistência
Aqui estão algumas directrizes para pensar na consistência das interfaces de utilizador:
- Begin reutilizando os controlos ou conceitos existentes nos seus esboços e protótipos, a menos que os seus objectivos incluam a alteração de uma tarefa ou comportamento específico do utilizador, comece com o máximo de consistência que puder. Reutilizar conceitos de trabalho é bom. Os guias de estilo são de grande valor aqui para o ajudar a reutilizar o máximo possível de conhecimentos existentes e um bom trabalho de concepção.
- Se não conseguir alargar o que tem para resolver o problema, vá conceber um novo widget ou conceito para resolver o seu problema.
- Se tiver de utilizar casos especiais (optimização local de um widget que não é utilizado em todo o lado), certifique-se de que é a melhor solução de compromisso que tem.
- Asegure-se sempre de que o sucesso do utilizador nas tarefas tem precedência sobre a consistência do design abstracto.
li>Se os seus esboços e protótipos não estiverem a funcionar em estudos de utilizadores ou outras avaliações devido ao fracasso dos conceitos existentes, tente fazer crescer um conceito existente para cobrir a nova situação que tem. Se alterar o comportamento de um controlo, aplique essa alteração em todo o lado em que o controlo for utilizado. Se alterar um conceito, aplique consistentemente essa alteração.
Estas directrizes devem ajudá-lo a ser o mais consistente possível, sem ser tolo. Deverão também ajudar a manter as suas interfaces simples. No centro de qualquer pensamento de design está uma série de trade-offs: velocidade versus fiabilidade, facilidade de aprendizagem versus proficiência especializada, consistência global versus optimização local. Como Ron Fein disse uma vez, “Design é escolher como falhar”, o que significa optimizar para uma coisa significa sempre falhar para outra. A chave para um bom design é saber quais são as características do seu website ou produto mais importantes, e quais as que está disposto a ceder. Se for claro quanto aos objectivos, o sucesso virá sempre do planeamento de tempo suficiente na sua agenda para reflectir sobre as contrapartidas de um vasto conjunto de alternativas. A coerência é um meio potencial para o sucesso, mas não o próprio sucesso.