Formulários Sensíveis: Um Checklist das Usabilidades de Formulários

por Brian Crescimanno

Computadores deveriam tornar nossas vidas mais fáceis, não mais difíceis. Como designers conscientes sobre usabilidade, podemos fazer as vidas de nossos usuários mais fáceis pensando na maneira como as pessoas interagem com nossos websites, provendo direções claras, e colocando o peso de organizar os detalhes nas mãos do computador – e não dos usuários.

É desta última que iremos tratar aqui. Todos nós ouvimos e lemos sobre os grandes erros de usabilidade de tempos em tempos: "Não use navegação com imagens ou Flash", "Não use Javascript para links", e eu certamente espero que estejamos todos aplicando estas lições aos nossos trabalhos. Geralmente são os menores erros de usabilidade que trazem as maiores dores de cabeça para os usuários, principalmente quando se trata de formulários HTML. Siga estas regras, e você já terá um bom começo.

Use o campo correto para a tarefa

Com tantos elementos de formulários para escolher, cada um com suas vantagens e desvantagens, pode ficar difícil decidir qual elemento usar numa determinada situação. Use radio buttons, checkboxes e select boxes apropriadamente: Para radio buttons e checkboxes, use as tags <fieldset> e <legend> para agrupar logicamente os elementos dentro de um tópico óbvio. Este agrupamento mantém o formulário gerenciável para os usuários, já que ele pode ser quebrado em partes menores em suas cabeças.

Jakob Nielsen oferece estas recomendações para uso de checkboxes ou radio buttons:

• Radio buttons são usados quando existe uma lista de duas ou mais opções que são mutuamente exclusivas e o usuário deve escolher exatamente uma delas. Em outras palavras, clicando num radio button não-selecionado fará com que qualquer outro botão da lista seja desselecionado.
• Checkboxes são usados quando existem listas de opções e o usuário pode selecionar qualquer número de opções, incluindo nenhuma, uma, ou várias. Em outras palavras, cada checkbox é independente dos outros na lista, então selecionando um box não desseleciona os outros.
• Um checkbox sozinho é usado para uma opção única que o usuário pode selecionar ou não.

Fonte: " Checkboxes vs. Radio Buttons ."

Para campos em que uma única opção é necessária e existe um número grande de opções, pense em usar um drop-down para manter a aparência da tela. A barreira entre o que faz sentido como radio buttons e select boxes é algo como uma neblina e dependerá do contexto. Se você vai precisar de 5 ou mais radio buttons, talvez seja a hora de mudar para um select.

Se o campo permite opções múltiplas, se esforce ao máximo para evitar as tão comuns "multi-select boxes". Este elemento, na melhor das hipóteses, confunde o usuário, e na pior, torna o formulário inútil para aqueles que não entendem imediatamente sua funcionalidade. Se o número de opções for tão grande a ponto de se tornar um grande vulto representado como checkboxes, pense em consolidar algumas opções categorizando-as hierarquicamente para ficar mais fácil de entendê-las.

Dê espaço para eles digitarem

Tão importante quanto fazer a escolha certa de campo é especificar corretamente seus tamanhos. Só porque seu nome é Joe Tod não significa que outros usuários não precisarão de mais espaço para digitar seus nomes. Ofereça no mínimo 20 caracteres para os campos de nome e sobrenome. Além disso, não faça com que o tamanho do campo ocupe menos área do que o que deve ser digitado. Para text areas, faça questão de dar ao usuário espaço suficiente para digitar e ler seu texto. Colunas muito altas e estreitas são tão difíceis de ler como as baixas e largas. O valor exato vai variar dependendo do seu uso mas podemos estabelecer um mínimo de 50 caracteres de largura por 10 linhas de altura para garantir a leitura.

Encurte seus formulários e coloque campos "obrigatórios"

Para deixar seu formulário o mais conciso possível, recomendo uma verificação em dois passos para cada elemento do formulário. Para começar, pergunte a você mesmo as seguintes perguntas sobre cada elemento:

• Esta informação é valiosa para nós?
• Esta informação é tão valiosa que vale a pena negar o acesso do usuário se ele não quiser passá-la?

Um dos exemplos mais óbvios de um elemento que não passa no primeiro teste é a saudação. Geralmente não temos nenhum benefício real ao coletar esta informação, então por que estamos pedindo que o usuário nos dê? Não desperdice o tempo dos usuários pedindo informações inúteis.

O segundo teste ("devemos tornar este campo obrigatório?") é um pouco mais subjetivo. Um exemplo é o número do telefone. Existem muitas circunstâncias em que seria interessante ter o número do telefone. No entanto, ele geralmente não é obrigatório para continuar a transação. Devolva a escolha para as mãos do usuário.

Marque os campos obrigatórios claramente

Alguns campos devem ser preenchidos para completar a transação: se você está vendendo um bem físico, você obviamente vai precisar de um endereço de entrega. Como mensagens de erro, dê dicas visuais aos usuários para quais campos são obrigatórios. Muitas vezes, autores de formulários usam negrito ou itálico para demonstrar quais campos são obrigatórios e esperam que o usuário faça essa associação. Existem muitas outras opções explícitas que você pode usar para chamar a atenção para campos obrigatórios. Você pode usar um asterísco, "obrigatório" em parênteses depois do campo, ou podemos dividir o formulário em duas seções: informações obrigatórias e opcionais. Em qualquer caso, se você está usando qualquer tipo de símbolo ou destaque para se referir a campos obrigatórios, você deve oferecer uma legenda de fácil acesso que notifica o usuário sobre o significado dos símbolos.

Eu desaconselho o uso do vermelho para campos obrigatórios, porque esta cor geralmente indica um erro ou um aviso. Como discutirei em breve, você deveria oferecer fortes dicas visuais para indicar erros, então escolha uma cor que não será confundida com mensagens de erro.

Ofereça rótulos descritivos para todos os seus campos

Qual a vantagem de um campo de formulário que você não sabe o que digitar? Utilize a tag <label> para garantir acessibilidade a todos os usuários. Além disso, tenha certeza que seus rótulos (labels) são suficientemente descritivos para que os usuários não se questionem o que inserir naquele campo. Os nomes dos campos devem ser concisos e claros. Se informações adicionais ajudarem, o XHTML 1.1 possui a tag <caption> para inserir uma legenda descritiva e oferecer uma acessibilidade adequada. Para os menos aventurados, você pode sempre criar pequenas legendas de texto usando XHTML 1.0 e CSS.

Deixe o computador, e não o usuário, tratar o formato da informação

Poucas coisas confundem tanto os usuários como pedir que eles insiram a informação num formato específico. Pedidos de formato para informação como números de telefone são particularmente comuns. Existem muitas maneiras que estes números podem ser representados:

• (800) 555-1212
• 800-555-1212
• 800.555.1212
• 800 555 1212

No final, o formato que gostaríamos é aquele que contém somente números:

• 8005551212

Existem três maneiras de tratar isso. O primeiro método diz para o usuário que um formato específico de inserção é necessário e o devolve para o formulário com uma mensagem de erro se ele não consegue seguir esta instrução.

O segundo método é dividir o campo do telefone em três. Este método apresenta ao usuário duas impactantes barreiras de usabilidade para atravessar. Primeiro, o usuário pode tentar digitar todos os números de uma vez e se irritar porque eles acabaram de digitar o telefone completo num campo que só aceita três dígitos. A solução "ingênua" para este problema seria usar Javascript para passar automaticamente para o próximo campo quando o limite de dígitos for alcançado. Alguém aqui já usou esse tipo de formulário e passou pelo ridículo processo de tentar voltar o foco para o que o Javascript vê como um campo preenchido? Levante a mão; não tenha vergonha! Sim, eu vejo todos vocês.

Seja razoável; nós temos tanto medo de expressões regulares (regular expressions) que não conseguimos tirar caracteres excedentes de um único campo? Deixe os usuários digitarem seus telefones como eles quiserem. Podemos usar um pouquinho de programação para filtrar o que não precisamos.

Use mensagens de erro informativas

Quando comecei a trabalhar neste artigo, falei com a minha mãe, uma típica dona de casa, sobre o assunto. A questão dos erros de formulários foi a primeira coisa que ela falou, ou melhor, reclamou. Quando ela tentou fazer um pedido de um presente de Natal por um website recentemente, ela preencheu o formulário e clicou no botão "Comprar". Depois disso ela foi enviada de volta ao formulário com as palavras "Erro no Cartão de Crédito" em negrito e vermelho no topo da tela. Confusa, ela procurou pelo formulário para encontrar qualquer indicação de onde o erro tinha acontecido. Não encontrando nada, ela procurou de novo para achar o campo do cartão de crédito. Ela conferiu o número e a data de validade. Ela conferiu até seu nome, mas a cada vez que ela enviava o formulário, o mesmo erro era exibido.

No final, o problema era que o sistema de processamento de cartão de crédito do site estava fora. Nada que ela pudesse fazer com o formulário faria alguma diferença. Retornar um usuário para esta situação só os faz se sentirem ignorantes, e acredito que podemos concordar que insultar um usuário não está entre nossos melhores interesses.

Existem muitos passos que podemos tomar para tratar melhor os erros em formulários HTML. Primeiro , e mais importante, podemos oferecer mensagens mais informativas. Substituir mensagens encriptadas como "Erro no Cartão de Crédito", por mensagens de acordo com o contexto:

• "Ocorreu um erro no nosso sistema de processamento de Cartões de Crédito. Seu cartão não foi cobrado. Por favor, tente mais tarde ou entre em contato diretamente pelo telefone..."
• "Ocorreu um erro ao processar seu cartão de crédito; não foi possível verificar o número do cartão. Por favor, confira seu nome, número do cartão e data de validade do cartão. Lembre-se que eles devem estar idênticos ao que está no cartão"

Estas mensagens de erro estão completas e dizem ao usuário o que aconteceu. Estas mensagens também direcionam os usuários para possíveis soluções ao invés de simplesmente informá-los o que está errado e esperar que eles inventem suas próprias soluções.

O próximo passo que podemos tomar para evitar erros confusos é oferecer algumas dicas visuais de onde está o problema; não deixe seus usuários caçarem sozinhos as áreas com problemas. Com um pouco de CSS, você pode modificar o formulário original de diversas maneiras para que o usuário possa facilmente identificar os elementos que precisam ser corrigidos. Você também pode usar CSS para esconder campos que já foram preenchidos corretamente e só exibir aqueles que precisam ser corrigidos. Podemos fazer isso para grupos de campos (como a informação exigida para a validação do cartão de crédito) usando a tag <fieldset>.

Não retorne usuários para formulários alterados

Quantas vezes você digitou suas informações num formulário e clicou em enviar só para descobrir que deixou um campo obrigatório vazio? Se você se parece o mínimo comigo, acredito que isso aconteça com uma certa frequência. Enquanto pode ser só o preço que pago por enganar o formulário e tentar passar por ele o mais rápido possível, eu não deveria voltar para um formulário alterado se eu cometesse um erro.

Quando enviei meus dados, eu cliquei na opção em que disse que concordo com os termos de serviço. Eu também preenchi minha senha. E, se me lembro bem, eu definitivamente não cliquei naqueles boxes que dizem "Insira meu e-mail no maior número de listas possível". Então por que tantas vezes eu recebo um formulário preenchido pela metade?

Este exemplo é realmente uma combinação da preguiça do desenvolvedor com técnicas super- conservadoras de marketing. (Apesar de que o campo da senha voltar vazio seja uma precaução legítima de segurança). Para os departamentos de marketing por aí: lembre-se que marketing é satisfazer as necessidades do consumidor. Se a necessidade de um usuário é não receber suas solicitações, você deveria respeitar isso ao invés de tentar jogar as pessoas numa coisa que eles já disseram que não querem. E para os desenvolvedores, tenha certeza de que está populando cada elemento do formulário que o usuário já enviou. Não há razão para que eles tenham que re-aceitar seus termos de serviços ou entrar com a informação uma segunda vez por causa de um pequeno engano.

Lembre-se, quanto mais controle os usuários têm sobre sua experiência, mais felizes eles ficarão ao usar seu website.

-----

Este artigo foi publicado originalmente na edição 209 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.