Interfaces user-friendly

São poucas as empresas que apostam num processo UX a sério. Muitas confundem-no até com caprichos para “se pôr algo mais bonito”. Isto resulta em aplicações com usabilidade reduzida e, no fim, em utilizadores descontentes e com uma má experiência de utilização. Por exemplo, num website, isto pode acabar em frustração e não regresso.. Aqui apresento a compilação de 8 dicas primordiais na fase de desenho de interação de uma GUI.

Escrevi originalmente este artigo (originalmente eram 4) no site maistutoriais.com em março de 2011. Aqui, encontram-se os 4 artigos num só.

1 – Realizar prototipagem

Um protótipo de baixo nível (de baixa fidelidade / throw-away prototype) é um esboço (mockup) ou wireframe de uma interface utilizador (GUI) realizado em papel ou em software adequado.

A ideia é obter uma representação gráfica de como irá ficar a GUI, de forma rápida e barata.

Protótipo de baixo nível (prototipagem em papel – esboço)

Esta técnica deve preceder qualquer implementação de GUI, pois:

  • Permite ter uma previsão de como o produto irá ficar;
  • Dá a hipótese de testar várias alternativas de desenho;
  • Tem custos muito baixos associados (processo simples e rápido; só precisa de caneta e papel);
  • Serve como meio de comunicação entre os intervenientes;
  • Permite obter feedback dos utilizadores (e outros) e captar erros desde muito cedo; e
  • Envolve e inspira os vários intervenientes no projecto.

Exemplo de wireframe

Um exemplo real da utilização desta técnica, é a prototipagem realizada para o MEO Interactivo.

As fases em que é mais proveitoso recorrer a protótipos de baixo nível são:

  • Início do produto (prototipagem geral); e
  • Antes da criação/alteração significativa de um novo ecrã, janela, página ou semelhante.

Um protótipo de baixo nível serve geralmente como ponto de partida para um de nível médio (já no PC) e por fim para a implementação concreta. Num ambiente agile, ganha ainda mais relevância, pois pode servir como técnica de especificação de requisitos.

Para saber mais, recomendo a leitura deste artigo e apresentação do Ivo Gomes do Sapo.

2 – Recorrer a metáforas visuais

Uma metáfora visual ou metáfora de interface, em desenho de interfaces, é uma analogia que se estabelece entre um sistema já conhecido e a interface a desenvolver.

Da mesma forma que recorremos a exemplos práticos para explicar algo no dia-a-dia, as metáforas visuais ‘explicam’ conceitos numa GUI. Por exemplo, o uso de um “coração” para representar favoritos é uma metáfora da vida real. Um exemplo mais complexo é o Google Maps, que tenta herdar os conceitos de um mapa real.

A grande motivação da utilização de metáforas é acelerar significativamente a criação de um modelo mental no utilizador (ou por outras palavras, a apreensão do modelo conceptual da aplicação).
E porquê? Porque estamos a aproveitar conhecimento que o utilizador já tem, para que ele entenda os conceitos inerentes à nossa aplicação.

Vejamos algumas metáforas conhecidas e usadas em interfaces-utilizador:

Leitor de música de um sistema hi-fi

Leitor de música para PC

Cestos

List shuttle no Windows

Armário de arquivos (file cabinet)

Explorador

Interruptor

Botões alternantes (toggle buttons)

Outros exemplos conhecidos são o “correio tradicional” ► “email”, “formulário em papel” ► “formulários web” e o “dossier” ► “interfaces TDI” (e.g. Firefox), mas existem muitos mais.

Esta é uma das 10 heurísticas de Nielsen que dita: “Match between system and the real world”.

A escolha da metáfora certa deve preceder qualquer criação de interface ou a adição de nova funcionalidade. Contudo, tal escolha não é uma tarefa fácil (a prototipagem permite testar várias). Uma das regras de ouro é nao forçar o uso de uma metáfora: se esta precisar de muitas adaptações, estamos no caminho errado.

Una metáfora de interface é caracterizada por uma ou mais affordances. Uma affordance é a capacidade de um objecto transmitir a sua acção (e.g. uma maçaneta dizer-nos que abrirá a porta). Para saber mais sobre affordances, veja esta apresentação (Ivo Gomes).

3 – Inspirar-se em sistemas existentes

É determinante procurar inspiração em sistemas já estabelecidos (e.g. Windows, Gmail, Google Maps, iPhone). Para além de terem dado provas positivas, são conhecidos pela maioria ou pela comunidade-alvo. O objectivo com isto é reduzir as questões na cabeça do utilizador, tirando partido de conhecimento que ele já obteve noutros sistemas. Melhora-se assim significativamente a curva de aprendizagem da aplicação em causa.

Os dois factores mais importantes na inspiração noutros sistemas são as regras (guidelines) e os padrões de interacção (que vamos ver abaixo).

Um exemplo é associar o ‘F5’ a ‘actualização de conteúdo’ e nunca a outra operação. Vejamos outros exemplos concretos:

Colocar a caixa de pesquisa no canto superior direito:

Caixa de pesquisa do Windows

Caixa de pesquisa da Wikipedia

Usar reticências em items que dão origem a um ecrã/diálogo que precisa de input do utilizador:

Excel

Google Docs

Tal como afirma um dos ‘gurus’ da usabilidade, Jakob Nielsen, uma aplicação deve ter em linha de conta “Consistency and standards“. Vejamos alguns documentos de referência:

4 – Recorrer a padrões de interacção

Qualquer programador sabe que não deve reinventar a roda. O desenvolvimento de qualquer software deve contemplar bons padrões de desenho (e.g. encapsulamento, proxy, abstracção).

Por sua vez, no desenho de interfaces, é essencial ter em conta padrões de interacção (interaction design patterns). Padrões de interacção são soluções testadas e reutilizáveis para problemas comuns no desenho de GUIs. Não devem ser confundidos com metáforas visuais, apesar de o conceito ser semelhante. Vejamos dois exemplos:

Breadcrumb

Permite ao utilizador navegar fácil e rapidamente para níveis acima, assim como saber o lugar onde está.

Breadcrumb (na web)

Breadcrumb em Mac

Breadcrumb (no Windows 7)

Wizard

Um wizard orienta o utilizador numa tarefa que atravessa diversas áreas funcionais.

Wizard (website)

Wizard (Windows)

Um padrão de interacção pode ser categorizado consoante a sua aplicabilidade: navegação, visualização de dados, selecção, interacção, formulários, pesquisa, compra, etc.

Nunca se deve usar um padrão de desenho sem primeiro perceber e formular bem o problema em causa. Só de seguida podemos procurar um padrão para o efeito, e caso necessário adaptá-lo à empresa/aplicação. Para nos ajudar a perceber se o padrão é adequado ao problema, este está geralmente descrito da seguinte forma:

Nome – título do padrão
Nomes alternativos – outras designações pelas quais o padrão é conhecido
Problema – breve descrição do problema a resolver
Solução – sumário do padrão
Quando – em que casos o padrão deve ser usado; pode também ser referida a(s) plataforma(s) aplicáveis (web / desktop / mobile)
Como – regras a ter em conta na sua utilização
Porquê – vantagens para o utilizador
Exemplos – imagens de casos práticos de boa utilização (e opcionalmente contra-exemplos)

Estes padrões estão geralmente organizados em bibliotecas de padrões (ou seja, repositórios). As empresas que mais apostam em usabilidade têm até a sua própria biblioteca de padrões. Bons exemplos são:

5 – Respeitar o fluxo de tarefas

As pessoas executam procedimentos de forma sequencial. As tarefas que executam no dia-a-dia seguem uma ordem lógica. Numa aplicação ou website, isto deve ser respeitado. Por exemplo, num site de e-commerce, não faz sentido pedir a morada antes da especificação dos produtos. Numa janela de uma aplicação, também não faz sentido colocar o “OK” e o “Cancelar” no topo da janela ou pedir admitir que o utilizador já leu algo que está “mais abaixo”.

Exemplo errado (formulário do SecondLife.com): neste caso, o utilizador tem “trabalho extra” a descobrir o fluxo de interacção

Nas culturas ocidentais, a ordem natural de leitura é de cima para baixo, da esquerda para a direita. Isto tem diversas implicações. Uma delas é que o que estiver do lado direito pode ser facilmente ignorado pelo utilizador.

Para além da ordem, a escolha do ‘layout’ também desempenha um papel vital. Por exemplo, em formulários onde há conteúdo importante do lado direito, vários utilizadores podem simplesmente nem vê-lo.

Ordem pela qual utilizador analisa layouts

No exemplo seguinte, verificamos que o botão “Apagar” está colocado acima da tabela. Contudo, a tarefa consiste em “1. Escolher linhas a apagar > 2. Pedir para apagar”, pelo que o botão deveria estar colocado debaixo da tabela.

Tabela com botão “Apagar” mal colocado

Na escolha do layout para um website, devem-se garantir linhas invisíveis orientadoras, para que o utilizador sinta harmonia e ordem visual no design, mas para que também apreenda rapidamente a organização visual do site.

A um nível mais macro (arquitectura da informação), é fundamental usar storyboards para definir os fluxos de acção das tarefas que uma aplicação suporta.

O objectivo é tentar ilustrar, ao estilo de uma banda desenhada, a sequência de ecrãs necessários para se executar uma tarefa. Esta é uma técnica que já sai fora deste âmbito, mas que poderemos vir a falar no futuro.

Em suma, tente pôr-se na pele do utilizador, tentando respeitar a ordem natural pela qual ele faz as coisas. E obviamente, teste as várias propostas usando protótipos de baixo nível com utilizadores finais.

6 – Garantir contextualidade

A contextualidade é a capacidade de uma interface-utilizador oferecer aquilo que o utilizador precisa, quando precisa. Ele não deve ter que procurar por botões, menus, opções, ajuda, etc; uma GUI deve ser simples e construída de tal forma, que o utilizador demore apenas um instante à procura do que precisa.

Por outro lado, também não devemos oferecer opções que o utilizador não precisa. Por exemplo, um menu contextual deve apenas conter itens contextuais. Isto parece óbvio, mas é um erro comum colocar itens fora de contexto (e.g. opções que não afectam o ficheiro seleccionado).

Menus de contexto (Windows / Facebook): contêm acções directamente relacionadas com o item em causa

Em geral, quando o utilizador precisa de ajuda, deve ser redireccionado para a página mais contextual possível do sistema de ajuda.

Em aplicações web, os menus devem servir apenas para navegação (ao contrário das aplicações desktop). As acções (e.g. apagar, editar, copiar, etc.) devem estar colocadas em toolbars no interior do painel onde fazem sentido:

Botões colocados no seu contexto

Ainda em aplicações web, as barras de deslocação (scroll bars), devem ser colocadas no componente que afectam (e.g. uma árvore), de modo a não activar o scroll da janela do browser.

Existem muitos mais exemplos que poderiam ser dados, mas em suma: dê ao utilizador apenas aquilo que ele precisa, onde precisa; nem mais nem menos.

Por fim (e não menos importante), há que realçar que o contexto deve ser mantido a todo o custo: operações que obrigam a mudanças de ecrã (muitas vezes demoradas) fazem com que o utlizador facilmente se “perca”. Na web (aplicações / sites), devem-se privilegiar técnicas tais como actualização focada a sub-áreas, diálogos, wizards, lazy loading, tabs, entre outras (para tal, o AJAX desempenha um papel determinante). Em aplicações web, devem-se considerar interfaces SPI (e.g. baseadas em portlets, dashboards).

7 – Ser consistente

Consistência é um conceito algo abstracto. O seu objectivo no desenho de GUIs é dar ao utilizador aquilo que ele está à espera, através da reutilização de conceitos de interface sempre que possível.

Aqui não estamos a falar de consistência com outros sistemas. Este nível de consistência é interno à web app/site.

A regra de ouro é não reinventar a roda. Devemos usar sempre as mesmas representações para os mesmos conceitos. A relação entre conceito e representação deve ser de um para um.

Alguns dos principais factores a ter em conta são:

  • Imagens: ícones, logótipos e outros artefactos visuais devem ser reutilizados
  • Texto: mensagens (e.g. de feedback) devem ser consistentes na gramática, terminologia, etc.
  • Posição: se o utilizador espera uma informação num local, este deve ser mantido (e.g. barra de estado, i.e. status bar)
  • Tamanho e forma: o utilizador associa tamanho e forma a conceitos, pelo que devemos aproveitar isso e ser consistentes
  • Estilos: por exemplo: se usamos um determinado design de janela, devemos mantê-lo para todas as janelas
  • Cores: a cor associada a um conceito deve ser mantida
  • Sons
  • entre muitos outros

A grande vantagem é o utilizador aprender mais rápido os conceitos inerentes à aplicação ou website, dado que mais facilmente sabe o que esperar e tem menos conceitos para aprender.
Contudo, a regra da ‘consistência’ não deve ser invocada acima de tudo. Por vezes, há que tomar opções que a põem em causa. No desenho de interfaces, o bom senso é essencial.

8 – Manter a simplicidade

A simplicidade não é simples de se atingir. À medida que se adicionam funcionalidades, é fácil ficar com interface confusa e cada vez menos usável. Esta é das heurísticas de Nielsen mais importantes mas menos valorizadas: ‘Aesthetic and minimalist design’. Deve ser encarada como a perfeição: devemos caminhar para ela, mesmo sabendo-a inatingível.

‘Simplicidade’ é uma “meta” presente em diversos campos do conhecimento, entre os quais o design. As seguintes citações explicam-no bem:

  • «Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.» (Antoine de Saint-Exupery)
  • «Simplicity – the art of maximizing the amount of work not done – is essential.» (Agile Manifesto)
  • «Never increase, beyond what is necessary, the number of entities required to explain anything.» (William of Ockham)

Quando adicionamos um elemento gráfico a uma GUI (ícone, botão, tabela, etc.), devemos pensar se o seu valor acrescentado o justifica. A interface-utilizador ideal de um ‘ecrã’ é aquela que condensa mais funcionalidade com o mínimo de carga visual (da mesma forma que a frase ideal é a menor, mas que passa mais informação).

Uma funcionalidade, se for muito utilizada ou muito comum, deverá estar muito mais acessível: à distância de menos cliques / passos / ecrãs / etc. Quanto mais for usada, mais importância visual deve ter. As funcionalidades menos comuns deverão estar mais “escondidas”:

Frequência de utilização vs. número de cliques vs. número de passos

Como exemplo, temos o botão dropdown “More actions” no Gmail:

“Mais acções” no Gmail

De cada vez que adicionamos funcionalidade a um ecrã, devemos analisar a sua carga visual e, se necessário, redesenhá-lo.

Funcionalidade vs. simplicidade

Um bom exercício é remover o que está a mais e testar a sua falta:

  • Remover tudo o que distrai o utilizador e não traz valor acrescentado (e.g. animações desnecessárias)
  • Remover instruções (uma GUI que precisa de instruções é um sintoma de que algo está mal)
  • Relegar para primeiro plano aquilo que o utilizador mais usa e para segundo plano o que menos usa (progressive disclosure).
  • Considerar padrões de interacção modernos que simplificam o desenho (e.g. Filtros, Notificações, botões dropdown, etc.)
  • Usar uma hierarquia visual: a importância de algo deve ser proporcional à sua carga visual (e.g. tamanho de texto).

Uma das principais condicionantes a ter uma interface simples é o lidar com aplicações legacy: os argumentos são que se deve manter o que se tem por motivos históricos. Nestas situações, há que saber gerir a mudança: por exemplo, fazendo o protótipo ideal, mas lançando-o faseadamente.

Só mesmo a experiência pode ajudar a atingir a meta da simplicidade. A boa notícia é que os protótipos de baixo nível têm custos muito reduzidos.

Conclusão

Com certeza que existiriam muito mais dicas a dar, mas tentei resumir os tópicos que considero fundamentais e que não podem ser esquecidos na criação de uma nova interface-utilizador, fruto da minha experiência na área; tentei apenas referir as menos óbvias e exploradas. Ficaram de fora muitas dicas, tais como: testar iterativamente com utilizadores, oferecer uma interface flexível (mais que uma forma de atingir o mesmo objectivo), providenciar ajuda bem escrita e contextual, etc.

Aproveito para reforçar a necessidade imperativa de prototipar sempre antes em papel. É enorme a diferença que isso pode fazer no ciclo de vida de um produto, principalmente porque este depende muito da sua interface para ter sucesso.

Deixar uma resposta