Quais são os erros a evitar quando se está a desenhar interfaces de aplicações? Tiago Simões, OutSystems Expert Developer partilha com os leitores do TeK as melhores práticas num artigo que, pela sua extensão, dividimos em três partes.

Publicamos agora a primeira parte, guardando a segunda e a terceira para os próximos dias.

Design e Usabilidade de aplicações
6 passos para criar melhores interfaces de utilizadores nas aplicações web

Por Tiago Simões (*)

Vamos ser realistas: como engenheiros de software, todos falhamos no que toca à criação de interfaces para utilizadores. Como estudámos e trabalhámos toda a nossa vida para compreender os sistemas complexos, acreditamos que as outras pessoas lidam da mesma forma que nós com a complexidade. Acontece que isto, simplesmente, não corresponde à verdade. As interfaces complexas que criámos foram a principal razão para que algumas das nossas aplicações não tenham sido bem sucedidas no passado.

E as velhas desculpas de não ter aprovação superior ou dos orçamentos limitados acabaram. Porque?


  1. Porque com a história recente da Apple, todos os executivos no mundo estão cientes do impacto da usabilidade para o sucesso de um produto – afinal estamos na era da usabilidade!
  2. 2. Porque os processos de usabilidade mais leves e mais baratos têm tido excelentes resultados – e neste artigo ficará a saber como aplicá-los.

Então, como pode melhorar o design e a usabilidade das interfaces? É fácil, necessita apenas de seguir estes 6 passos. Comecemos pelo primeiro:

1: Recolher e prioritizar as user stories

Antes de criar uma aplicação precisa de recolher as user stories. Estas não são apenas novas funcionalidades. São antes "histórias" de alto nível que ilustram os requisitos do utilizador. Aqui está um exemplo:

"Como chefe de equipa, o Johnny Boss precisa de ter um calendário com as férias de todos os membros da equipa, para que possa perceber se existem sobreposições relevantes antes de aprovar um requerimento".

Johnny Boss é uma persona. Uma persona é uma personagem fictícia criada para cada tipo de utilizador que irá utilizar a sua aplicação - estas personagens vão, mais tarde, ajudá-lo a colocar-se nos seus lugares. Por isso, dar um nome divertido ao seu personagem, fácil de lembrar, é uma boa estratégia.

Portanto, antes de iniciar o desenvolvimento da sua aplicação, deve criar 2 ou 3 personas que representam os utilizadores e cerca de 20 histórias como a que foi descrita anteriormente. É importante manter esta lista pequena. As histórias precisam de ser de alto nível, e podem incluir exemplos para torná-las mais fáceis de entender. Depois de escrever as histórias pode desenhá-las num diagrama de processo. Isso vai ajudar a visualizar a sequência. O documento com as personagens, as histórias do utilizador, e o diagrama não deve ter mais do que 3 páginas.

É muito importante fazer isto ANTES de começar sequer a pensar na base de dados. Ao fazer esta tarefa muitas vezes vai ser tentado a pensar como irá estruturar as tabelas da base de dados. Outro erro comum é aprofundar demasiado as discussões de detalhe. Evite ambas as situações - neste momento as suas preocupações devem centrar-se em manter o alto nível deste projecto.

Outro problema ao criar estas histórias é apenas recolher as "histórias de escrita", ou seja apenas para quando são alterados dados no sistema. No entanto é também importante recolher as user stories de quando os utilizadores necessitem apenas de interagir com o sistema para consultar informação.

E o que tem de fazer para inventar essas "histórias"? Rigorosamente nada! Os seus utilizadores, sim, terão de fazê-lo. Apenas necessitará de escrevê-las. Entreviste as pessoas que irão utilizar a aplicação, tente perceber como fazem as coisas presentemente. Quanto mais perguntas fizer, melhor e mais completa será a user story. De seguida mostre as user stories aos utilizadores e deixe-os ajudá-lo a melhorá-las.

A tarefa seguinte é ordenar as user stories por prioridade: quais dessas "histórias" são as mais comuns? Qual será usada todos os dias? Procure seleccionar apenas 3 ou 4 user stories e classificá-las como "Alta Prioridade". Estes são os 20% da sua aplicação que serão usados em 80% do tempo (a regra 80-20). Em seguida, dê prioridade às restantes "histórias". Pessoalmente, recorro a um esquema de categorização muito básico para simplificar: Alto, Médio e Baixo. Também sobre isto os utilizadores sabem mais do que qualquer outra pessoa. Tenha em mente que as diferentes partes interessadas terão perspectivas diferentes, e todas devem ser levados em conta, mas é necessário ordenar as user stories por prioridades para as pessoas que usam realmente o sistema na maior parte do tempo.

Prioritizar as user stories é a parte mais importante na criação de interfaces para os utilizadores.

Se a qualquer momento durante o projecto alguém lhe perguntar quais são as três principais user stories, necessita de ser capaz de responder de imediato. Consegue fazer isso para o projecto em que está a trabalhar presentemente?

2: Compreender os custos
Para completar uma dessas user stories, um utilizador terá de navegar pela interface da sua aplicação. Designamos isso por "caminho do utilizador". Estes "caminhos" têm custos e deve ser capaz de reconhecê-los para fazer os ajustes necessários à melhoria das interfaces dos utilizadores.

O objectivo é simples: as user stories mais comuns devem ter "as pegadas do utilizador" mais baratas.

Então, qual é o custo de uma "pegada do utilizador"? É a soma de vários tipos de custos:


  • Custos de localização

    Cada vez que um utilizador necessita de encontrar algo num ecrã há um custo. Estudos de rastreamento ocular têm demonstrado que o olho viaja em saltos entre pontos de uma página, e que ao saltar de ponto para ponto o olho é essencialmente cego.

    • Topo e Esquerda do ecrã mais baratos do que a direita e parte inferior do ecrã
      O padrão mais comum que vemos (em países ocidentais) é o olho navegar de cima para baixo e depois da esquerda para a direita ao longo de alguns eixos, no que parece ser um padrão F. A partir daqui pode ver que elementos da interface que estão no topo ou à esquerda têm custos de localização mais baixos, ou seja, serão mais fáceis de encontrar.

      [caption]imagem[/caption]

      Estudos de eye tracking mostram os olhos dos utilizadores a viajar de cima para baixo e da esquerda para a direita (Imagens de estudos da Nielsen Norman Group)

      Por essa razão, sempre que coloca uma lista na interface do utilizador deve pensar sobre qual a melhor ordem de classificação. Mesmo quando isso possa ser alterado pelo utilizador, é necessário seleccionar cuidadosamente a ordem de classificação por defeito. A ordem alfabética é geralmente uma má escolha. Algumas das melhores escolhas são a última alteração ou a última data de acesso. Mas é claro que isso depende das user stories.

      Este princípio aplica-se a todos os outros elementos da interface. Por exemplo, se necessita de colocar alguns botões numa só linha, os mais utilizados devem ficar do lado esquerdo.


    • Criar melhores focos de atenção
      Os estudos de rastreamento ocular também constataram que o olho se detém num texto maior (ou com um estilo diferente). Estes acabam por ser, geralmente, os labels, links, cabeçalhos e títulos. Chamemos-lhes Focos de Atenção. Portanto, se o olho salta entre esses focos, o que deve fazer o programador? Aproveitá-los. Utilize a linguagem do utilizador para estes elementos de design, ou, de preferência, use os dados do utilizador sempre que possível. Por exemplo, o melhor título para uma página que mostra as informações de contacto é o nome do contacto. Outro exemplo: numa página de resultados do Google, os títulos dos resultados da pesquisa são os títulos das páginas em causa.

    • Informação Agrupada
      Quando existem muitas informações para mostrar numa página, a forma mais fácil para localizá-la é agrupá-las. Na maior parte das vezes, estes grupos terão um título como "foco de atenção". No fundo é como este artigo que está a ler: se quisesse encontrar alguma coisa neste texto, seria relativamente simples, porque o texto está agrupado em secções.

    • Quanto Menos Melhor
      Mas a melhor forma de facilitar a localização de algo no ecrã é retirando tudo o resto. Quanto menos coisas estiverem na página, mais facilmente se encontra o necessário.


  • Custos de espera
    Estes custos são bastante simples de compreender. Existem quando o utilizador precisa de esperar pelo sistema, geralmente devido a latência. Seguir o link vai fazer com que o utilizador espere pela resposta do servidor. É por isso que o AJAX se tornou tão popular na web: estas chamadas são mais rápidas e por isso têm um custo mais baixo para a interface. Mas não se iluda: até com o AJAX o utilizador precisa de esperar, ou seja, existe um custo a ser considerado.

    Então, para evitar os custos de espera, bastaria colocar tudo na homepage da sua aplicação, tornando desse modo todos os caminhos da interface mais baratos, certo? Errado! Os custos de localização acima mencionados disparariam, pois seria muito mais difícil encontrar algo nessa página.

    Como resolver então este dilema? Lembre-se mais uma vez da prioritização das user stories; coloque as três ou quatro principais na página inicial.

    Mais uma vez: as user stories mais comuns necessitam de caminhos mais baratos para a interface.

  • Custos de interacção
    Gosta de preencher formulários na web? Ninguém gosta, devido aos custos de interacção associados.

    Sempre que os seus utilizadores precisam de digitar uma tecla no teclado há um custo. Se precisam de clicar com o rato há outro custo. Navegar para cima e para baixo numa página ou numa drop-down tem um custo. Quando os utilizadores precisam de trocar entre o teclado e o rato há ainda outro custo. Para evitar este último deve certificar-se de que é possível usar a tecla tab para navegar entre os campos. Outro acelerador útil é colocar o foco automaticamente no primeiro campo de entrada.

    Para reduzir os outros custos apenas precisa de minimizar a quantidade de digitações e cliques necessários. Quanto menos entradas obrigatórias, melhor. Efectivamente, quanto menos entradas houver melhor, pois os custos de localização também se aplicam aos formulários. Por isso, lembre-se de agrupar os campos de preenchimento obrigatório no topo, uma vez que são os mais importantes. Os opcionais devem vir a seguir, ordenados por frequência de preenchimento.

    Valores por defeito inteligentes são outra forma de reduzir custos: se a maioria dos utilizadores irá seleccionar um valor específico de uma lista o valor deve estar sempre pré-seleccionado para poupar cliques.

    Porque serão melhores os campos de auto-preenchimento do que as listas quando temos um domínio grande? Porque nos campos de auto-preenchimento só precisamos de digitar dois ou três caracteres, enquanto numa lista teríamos de clicar muitas vezes para localizarmos o que queremos, fazendo disparar os custos.

(*)
OutSystems Expert Developer

Nota da Redacção: Nesta primeira parte do artigo publicamos apenas os 2 primeiros passos definidos por Tiago Simões. Nos próximos dias serão publicadas as duas partes que faltam deste artigo.