UX e HTML5: vamos ajudar os usuários a preencher seu formulário móvel (parte 1)

Os formulários são uma das interações primárias mais básicas que os usuários terão com seus sites (e aplicativos para dispositivos móveis). Eles ligam as pessoas e permitem que elas se comuniquem. Eles permitem que eles comentem os artigos e expliquem ao autor como eles discordam fortemente do que escreveram. Eles permitem que as pessoas conversem diretamente em um aplicativo de namoro para conhecer “o cara”. Seja para fóruns, pedidos de produtos, comunidades online, criação de contas ou pagamentos online, os formulários são uma grande parte da vida online dos usuários.

Estamos em 2018 e temos mais usuários de dispositivos móveis do que de desktops em todo o mundo . No entanto, ainda tratamos esses usuários como cidadãos de segunda classe da web. Todo mundo escreve e fala sobre a experiência do usuário o tempo todo. Então, por que, por que, por que tantos sites e produtos ainda estão fazendo isso errado. Por que a experiência do usuário móvel está prejudicada em metade do mundo? Por que ainda é uma dor, por que ainda é super difícil reservar um voo e registrar uma conta em um formulário móvel hoje? Os usuários esperam melhor!

Leitura recomendada : World Wide Web, Not Wealthy Western Web

Esta é a primeira parte de uma série de dois artigos. Neste, resumirei algumas práticas recomendadas essenciais para melhorar seus formulários móveis, incluindo a capacidade de digitalização e legibilidade. Vou guiá-lo através do posicionamento, tamanho e otimização de rótulos e entradas. Veremos como escolher o elemento de formulário certo para reduzir os custos de interação. Por fim, você aprenderá como prevenir e lidar com erros em formulários móveis.

Na segunda parte, examinarei mais de perto os recursos móveis específicos e os elementos de formulário HTML5, e iremos além dos elementos de formulário clássicos para criar aplicativos e sites da Web exclusivos e agradáveis.

Observação : Embora a maior parte do aprimoramento de código neste artigo seja relacionado à Web (porque não conheço Swift ou Java), as práticas recomendadas de usabilidade são válidas para aplicativos móveis .

Form Design 101: Priorizando a digitalização e legibilidade

“Um formulário é o nome, valor, pares, em uma estrutura para armazenar dados em um computador vomitados como rótulos e campos de entrada para o ser humano.” Esta é uma citação direta de Luke Wroblewski em uma conferência. Assim como ele, acredito que a maioria dos problemas de usabilidade do formulário vem dessa tendência de servir a estrutura do banco de dados aos usuários.

Arquitetura de Informação Forte

Para construir formulários melhores, primeiro você precisa dar alguns passos longe da estrutura do seu banco de dados. Tente entender como os usuários desejam preencher os formulários. É aqui que fazer alguns testes de usabilidade e pesquisas de usuários em seus formulários se torna útil. Modelos mentais do usuário é um conceito de UX que pode ajudá-lo com isso. O Nielsen Norman Group o descreve como “o que o usuário acredita sobre o sistema em questão”. Peça ao seu testador para pensar em voz alta e dizer como eles preencheriam o formulário. Quais etapas eles esperam? O que vem primeiro? O que vem depois? Isso lhe dará uma ideia melhor de como estruturar seu formulário de maneira mais amigável.

Agrupar visualmente os campos que pertencem um ao outro também ajudará os usuários a preencher um formulário. No código, use a tag fieldset para agrupá-los programaticamente. Também ajudará os leitores de tela a entender a hierarquia.

Se o formulário for longo, não exponha tudo por padrão . Seja esperto sobre o que você exibe. Use a ramificação com sabedoria para exibir apenas os campos que as pessoas precisam. Em um formulário de checkout, por exemplo, não exiba todos os campos detalhados para todas as opções de envio. Isso vai sobrecarregar o usuário. Exiba informações suficientes para ajudá-los a escolher a opção de envio correta. Em seguida, exiba apenas os detalhes e campos relacionados a essa escolha.

A atenção do usuário diminui com o tempo: peça itens opcionais no final do formulário. Por exemplo, se o seu formulário for uma pesquisa de satisfação do cliente, peça informações demográficas no final. Melhor ainda, preencha-os automaticamente, se possível. Peça aos usuários apenas o que for necessário.

Por fim, planeje com antecedência a localização: o que acontecerá quando seu formulário for traduzido? O que acontecerá, digamos, para o alemão? Seu projeto ainda funcionará?

Posicionamento de rótulos e otimização de entrada

O layout de coluna única funciona melhor

Devido à falta de espaço, você não tem infinitas opções para colocar rótulos e campos em telas de dispositivos móveis:

• Apresente campos em um layout de coluna única . Não há espaço no celular para várias colunas. Formulários com várias colunas também não são uma boa ideia no desktop.
• No modo retrato, é melhor colocar o rótulo na parte superior do campo para que os usuários possam ver o que está no campo ao digitar.

• No modo paisagem, a altura da tela é reduzida. Você pode querer colocar rótulos à esquerda e entradas à direita . Mas teste para ter certeza que funciona.

Para saber mais sobre a colocação de rótulos, consulte “Usabilidade de formulário móvel: Coloque rótulos acima do campo” do Baymard Institute.

Os rótulos devem ser claros e visíveis e funcionar sem contexto

Lembre-se que assim que um campo fica em foco, o teclado se abre e ocupará pelo menos um terço da área da tela. Em pequenas telas móveis, os usuários também terão que rolar para preencher o formulário. Isso significa que eles perderão parte do contexto ao preencher o formulário. Planeje de acordo:

• Seus rótulos devem ser texto claro e visível que possa ser lido e entendido sem contexto. O usuário deve ser capaz de completar cada etiqueta e par de campos como uma tarefa separada, mesmo que perca o contexto.

• Evite jargões, abreviações e linguagem específica do setor sempre que puder.
• Ser consistente. Se você usar “cliente” em um rótulo uma vez, fique com essa palavra. Evite usar “clientes” posteriormente, pois pode confundir os usuários.
• O tamanho da fonte deve ser grande o suficiente. Teste seu formulário em dispositivos reais o mais rápido possível e ajuste o tamanho de acordo.
• O texto em maiúsculas pode ser difícil de ler para alguns usuários. Convém evitar o uso de texto em maiúsculas nos rótulos.
• A cópia da etiqueta deve ser curta e digitalizável. Se um campo precisar de esclarecimento, não o coloque no rótulo. Em vez disso, use uma descrição de campo.

Prática recomendada de tamanho de entrada

Se possível, o tamanho do elemento de entrada deve corresponder ao tamanho do conteúdo esperado . Isso ajudará os usuários a preencher o formulário rapidamente e entender o que é esperado.

Usando máscaras para evitar a divisão de entradas no celular

Não divida as entradas apenas para formatar . É especialmente irritante no celular, onde os usuários não podem usar o teclado para navegar entre os campos. Requer toques extras apenas para ir para o próximo campo para preencher o formulário. Você pode estar pensando: “Mas eu colocarei automaticamente o foco no próximo campo quando eu obtiver o número necessário de caracteres nesse campo”. Isso poderia funcionar. Mas você terá assumido o controle da interface do usuário, que se torna imprevisível para o usuário. Além disso, seria uma dor se você os enviasse automaticamente para o próximo campo e eles precisassem corrigir algo no último campo. Finalmente, é mais complicado adivinhar o que é obrigatório com entradas divididas. Então, vamos parar de jogar o jogo “Mas e se” e simplesmente não dividir as entradas.

Entendo: você ainda quer poder formatar os dados do seu usuário em pequenos pedaços para ajudá-los a preencher seus campos. E você está perfeitamente certo sobre isso. Para isso, você pode usar máscaras . Em vez de dividir uma entrada, basta colocar uma máscara em cima dela, para ajudar visualmente o usuário a preenchê-la. Aqui está um exemplo de vídeo de como seria uma máscara para ajudar os usuários a preencher um campo de cartão de crédito:

As máscaras ajudam a evitar erros, orientando os usuários para o formato correto. Evite revelá-los gradualmente — mostre o formato diretamente. Além disso, evite colocar valores falsos na máscara . Os usuários podem pensar que já está preenchido. É por isso que substituí os números por um pequeno “X” na minha demonstração. Encontre o que funciona melhor para o seu tipo de entrada.

Por fim, lembre-se de que alguns dados podem variar entre os países e, às vezes, o formato também muda (números de telefone, por exemplo). Planeje de acordo.

Descrições de Campos Eficientes

A exibição de descrições de campo eficientes pode fazer a diferença entre uma experiência de formulário perfeita e dolorosa.

Para que as descrições podem ser usadas?

As descrições podem ajudar os usuários de muitas maneiras. Aqui estão alguns exemplos.

• O que exatamente você está pedindo?
  

  Por qualquer motivo relacionado ao banco de dados, algumas empresas de remessa solicitam os campos "Endereço 1" e "Endereço 2". Isso é altamente confuso para os usuários, mas talvez você não tenha escolha aqui. Adicione campos de descrição para ajudar os usuários a entender o que eles precisam colocar em cada campo.

  

  O mesmo vale para siglas e abreviaturas. Eu sei que eu disse que você deveria evitá-los, mas às vezes você não pode. Se você trabalha em formulários complexos para um setor específico, por exemplo, eles podem ter seu próprio conjunto de abreviações. Qualquer novo usuário que precise preencher o formulário pode não estar familiarizado (ainda) com essas abreviações. Ter uma descrição disponível em algum lugar irá ajudá-los.

• Por quê você precisa dessa informação?
  Os usuários podem relutar em fornecer informações pessoais se não entenderem por que você precisa delas e o que fará com elas . Mas às vezes você ainda precisa solicitar essas informações por motivos legais (como data de nascimento de um site que vende álcool). O uso de descrições de campo aqui ajudará os usuários a entender por que esse tipo de informação é necessário.
  
  

  Em sites de comércio eletrônico, você pode solicitar o número de telefone do usuário caso o entregador precise entrar em contato com ele. Esta é uma razão legítima. Então, novamente, use as descrições para explicar aos usuários de comércio eletrônico por que você precisa do número de telefone deles.

  

“Onde encontro as informações?”
Se seus usuários precisarem encontrar determinadas informações em outro lugar para preencher um formulário, diga a eles onde encontrá-las. Eu trabalhei em um aplicativo móvel que permite ao usuário rastrear sua casa. Os usuários precisavam emparelhar o aplicativo com o dispositivo de monitoramento usando um número de série. Não é muito fácil encontrar esse número de série no dispositivo; requer alguma instrução. Adicionamos um pouco ? botão ao lado do campo do número de série. O botão abre um modal que mostra uma imagem e alguma indicação para ajudar o usuário a entender onde encontrar o número de série no dispositivo de monitoramento. Os sites de comércio eletrônico fazem o mesmo com os códigos promocionais: eles fornecem indicadores que informam aos usuários onde encontrar os códigos.



• “Como devo formatar as informações?”
  Alguns campos precisam de um formato específico . Nesse caso, use descrições para que os usuários conheçam as regras de formatação antecipadamente. Aqui estão alguns exemplos:
  • Número de telefone: preciso colocar o código de discagem internacional (+xx) na frente do campo?
  • Existe um comprimento máximo? O Twitter no celular faz um bom trabalho com isso.
  • Ao lidar com valores monetários, o formato é com vírgula (como 10.000) ou um espaço (como 10.000)?
  • Que formato você espera para as datas? Vou deixar você verificar na Wikipedia que pesadelo isso é. A diferença entre DD MM YY e MM DD YY pode causar *muito* problemas aos usuários ao fazerem reservas online.
  Observe que muitos desses problemas de formatação podem ser resolvidos por máscaras de entrada. Chegaremos a isso mais tarde no artigo (ou você pode pular direto se estiver impaciente).

  

Como exibir descrições

Nos exemplos acima, vimos algumas maneiras de exibir descrições de campo. Aqui está um resumo do que fazer:

• As descrições embutidas devem ser diretamente visíveis e exibidas ao lado do campo.
• Se precisar de descrições mais detalhadas com conteúdo pesado, você pode usar dicas de ferramentas ou modais . As dicas de ferramentas geralmente são acionadas ao passar o mouse na área de trabalho e ao tocar no celular. O mesmo vale para os modais: abra-o quando o usuário tocar no ícone de ajuda ou no link “ver mais”, por exemplo.

Tenha cuidado com espaços reservados

Entendo: é tentador remover campos no celular para ganhar espaço e usar espaços reservados. Todos nós já fomos por esse caminho. Mas por favor, não. A especificação HML5 é clara sobre isso: “O atributo placeholder representa uma dica curta (uma palavra ou frase curta) destinada a auxiliar o usuário na entrada de dados”. E aqui está o porquê:

• O espaço reservado desaparece quando o usuário começa a digitar. O usuário deve então confiar na memória de curto prazo para lembrar o que deve colocar no campo . Caso não consigam, terão que esvaziar o campo para ver a indicação.
• É difícil para os usuários verificarem os campos antes de enviar porque os campos não têm mais nenhuma indicação de rótulo.
• É difícil se recuperar de erros depois que um campo é enviado porque, novamente, não há rótulo para ajudar o usuário.

Mesmo se você usar marcadores de posição com rótulos, ainda poderá ter alguns problemas. É difícil dizer a diferença entre um campo preenchido e um campo com um espaço reservado . Sou um designer de UX que escreve sobre design de formulários para dispositivos móveis e até fui enganado na semana passada por um desses. Se isso acontecer comigo, acontecerá com seus usuários – confie em mim. Por fim, a maioria dos espaços reservados tem texto em cinza claro, portanto, você também pode ter alguns problemas de contraste.

Se você quiser se aprofundar neste tópico, há um ótimo artigo chamado “Placeholder Attribute Is Not A Label, e também Joshua Winn e FeedbackGuru detalham por que isso é uma má ideia. O Nielsen Norman Group também escreveu um artigo sobre o assunto, intitulado “Placeholders in Form Fields Are Harmful”.

Espaços reservados não são obrigatórios em HTML5 . Do ponto de vista da usabilidade, você certamente não precisa de um espaço reservado em todos os campos do seu formulário. Mas com a adoção massiva do Bootstrap e outros frameworks, parece que muitas pessoas apenas copiam e colam componentes. Esses componentes têm espaços reservados, então acho que as pessoas se sentem meio que obrigadas a adicionar algo ao espaço reservado no código? Se os espaços reservados do seu formulário se parecerem com “Por favor, preencha seu — rótulo — aqui”, você está fazendo isso errado.

Os rótulos dentro dos campos podem, no entanto, funcionar bem para formulários curtos nos quais os campos são previsíveis . Os formulários de login são um bom candidato para isso. Mas, por favor, não use o espaço reservado HTML5 para codificar isso. Use um rótulo real no código e mova-o com CSS e JavaScript.

Desde o sucesso do material design do Android, um padrão começou a surgir: o rótulo flutuante. Esse rótulo fica dentro do campo quando o campo não está preenchido, portanto, ocupa um pouco menos de espaço vertical no celular. Quando os usuários começam a interagir com o campo, o rótulo se move acima do campo.

Esta parece ser uma maneira interessante de ganhar algum espaço, sem se deparar com os problemas de “espaços reservados no lugar de rótulos” citados acima. No entanto, isso não resolve o problema de usuários possivelmente confundirem um espaço reservado com conteúdo preenchido.

Redução de custos de interação para formulários bem-sucedidos

Reduzir o custo de interação (ou seja, o número de toques, furtos, etc.) dos usuários que realizam suas tarefas ajudará você a criar uma experiência de formulário perfeita. Existem diferentes técnicas para conseguir isso. Vejamos alguns deles em detalhes.

Um estudo mágico na Internet me disse para reduzir o número de campos

Mais campos significam menos conversões, certo? Você pode ter encontrado o estudo “reduzimos nosso formulário de inscrição de 11 para 4 campos e ele aumentou as conversões em 160%”. É um clássico. E se você olhar para o formulário de contato deles, faz sentido. Por que os usuários gostariam de preencher 11 campos apenas para entrar em contato com a empresa? Você não pode pedir um compromisso tão grande de pessoas que mal te conhecem, certo?

Comece pedindo apenas informações úteis. Por que você precisa do gênero de uma pessoa para criar uma conta para ela? Por que você tem duas linhas para o endereço se seu formulário de inscrição é para um serviço online?

Peça apenas as informações necessárias. E, em seguida, peça as informações no contexto. Se você tiver um site de comércio eletrônico, os usuários podem estar mais inclinados a fornecer seu endereço na seção de envio do processo de checkout do que quando se registram. Isso tornará seu formulário de registro de comércio eletrônico muito mais fácil de preencher no celular!

Além disso, não confie cegamente em todas as estatísticas e estudos que você encontrar na Internet. Lembre-se do estudo de 11 campos para 4? Bem, outro estudo mais recente mostrou que, reduzindo os campos de 9 para 6, as conversões caíram 14%. Chocante, não é? Por quê? Bem, eles removeram os campos mais envolventes. Para encurtar a história, eles voltaram para 9 campos, colocaram o mais importante no topo e pronto, as conversões aumentaram 19,21%.

A conclusão é que, embora esses estudos sejam interessantes, esses sites não são o seu site. Não confie cegamente no primeiro estudo que encontrar na Internet.

Então o que você pode fazer? Teste. Teste. E teste!

• Faça alguns testes de usuário para ver o tempo de preenchimento do seu formulário móvel.
• Medir desistências.
• Medir problemas com determinados campos.
• Meça a frustração associada a determinados campos. Até que ponto os usuários estão dispostos a fornecer essa informação? Quão pessoal é essa informação?

Otimizando as interações de toque

Tornando os controles amigáveis ​​ao toque

Se seus campos forem muito pequenos ou difíceis de alcançar, os usuários cometerão erros e precisarão de interações extras para atingir suas metas. Lembra da lei de Fitt? Você também pode aplicá-lo ao design para dispositivos móveis: torne seus rótulos, campos e controles de formulário fáceis de tocar aumentando o tamanho do alvo de toque . Para etiquetas na web, um pouco mais de preenchimento pode aumentar a área de toque. Às vezes, você também precisará adicionar algumas margens entre os elementos para evitar toques perdidos.

Além disso, não se esqueça de vincular os rótulos aos seus componentes emparelhando os valores for e ID. Dessa forma, se o usuário perder um toque no rótulo, o campo correspondente ainda ficará em foco.

Steven Hoober realizou algumas pesquisas com usuários sobre áreas de toque. Você encontrará um resumo em “Designing for Touch”. Com base no que descobriu, ele construiu uma pequena ferramenta de régua de plástico: o modelo de toque móvel. A ferramenta pode ajudá-lo a garantir que suas áreas de toque sejam grandes o suficiente para formulários móveis e, de maneira mais geral, para design móvel.

Para saber mais sobre o design para toque, você pode ler o seguinte:

• “Design amigável aos dedos: tamanhos ideais de alvos para telas sensíveis ao toque para dispositivos móveis”
• “The Thumb Zone: Design para usuários móveis”

Fornecendo feedback

Os usuários de dispositivos móveis não têm mouse (sem brincadeira), então eles não recebem o feedback de “clique” que os usuários de desktop recebem ao apertar um botão. Os usuários de formulários móveis precisam de feedback claro ao interagir com elementos:

• Forneça um estado de foco para o campo de formulário com o qual o usuário está interagindo.
• Fornecer feedback visual quando o usuário interage com um botão .

Eu não sou um grande fã do efeito cascata do material design nos botões. Mas devo admitir que as animações no Android fornecem feedback claro quando o usuário interage com um botão.

Honre a ordem do botão seguinte e anterior

Por fim, honre os botões próximo e anterior nos teclados móveis. Os usuários podem usá-los para navegar rapidamente pelos campos. A ordem tabindex deve corresponder à ordem visual dos campos e componentes.

Evite dropdowns no celular, se possível

As listas suspensas (o elemento de seleção HTML) na Web exigem muitas guias e interações. Portanto, como disse Luke Wroblewski, eles devem ser a interface do usuário de último recurso. Muitos outros componentes de interface do usuário funcionam melhor do que os menus suspensos em muitas situações.

Controles de segmento e botões de opção são boas alternativas para listas suspensas se você tiver entre duas e quatro opções. Por que ocultar as opções em uma lista suspensa quando você pode mostrá-las todas diretamente em uma tela? Observe que, como os botões de opção, os controles de segmento são mutuamente exclusivos.

Uma lista de países é um bom candidato para um componente. Uma lista suspensa de mais de cem países é um pesadelo de interação no celular. Tudo bem se você estiver procurando por Afeganistão (no início da lista) ou Zimbábue (no final da lista). Se você estiver procurando por Luxemburgo, acabará em um jogo de rolagem para chegar ao meio da lista, indo muito longe para a letra M, tentando voltar para L, e assim por diante.

Longas listas suspensas podem ser substituídas por campos de entrada de texto previstos . Quando o usuário começa a digitar L, a interface propõe nove países. Se eles adicionarem um U — voila! — Luxemburgo é. Quatro interações em vez de duas, contra até seis ou sete interações de rolagem com o menu suspenso.

Se você precisar que os usuários escolham uma data, esqueça de dividi-la em uma lista suspensa de dia, mês e ano, como as pessoas estão acostumadas a fazer em formulários de papel. Substitua várias listas suspensas de datas por um seletor de datas . O type=date funciona na maioria dos casos. Mas você pode ter algumas necessidades especiais e acabar criando seu próprio seletor de datas em JavaScript, especialmente se estiver no ramo de reservas (hotéis, carros, voos).

Em seu artigo “Mobile DropDowns Revisited”, Klaus Schaefers explica como o uso de um seletor de datas para datas de chegada e partida tornou as interações 60% mais rápidas.

Vamos ficar com o negócio de reservas. Suponha que o usuário precise adicionar vários viajantes ao itinerário. Você pode **substituir a lista suspensa * por um *passo** para selecionar o número de passageiros. Um stepper é um controle que permite ao usuário aumentar e diminuir valores simplesmente tocando nos botões + e - . Isso tende a ser mais rápido quando menos de seis pessoas precisam ser adicionadas. Também é mais intuitivo. Abaixo está um exemplo de um stepper usado no aplicativo Airbnb nativo do Android para selecionar hóspedes e no site otimizado para celular do Kayak para adicionar passageiros.

Uma alternativa final às listas suspensas é a exibição de lista. As opções seriam listadas em uma subvisualização específica, como botões de opção , por exemplo. É principalmente assim que as configurações do Android funcionam.

Ficando esperto com o preenchimento automático

Se você deseja diminuir o custo de interação do seu formulário, seja esperto. Não peça informações que você possa detectar automaticamente ou adivinhar com base em outras informações que os usuários deram a você. Autocomplete e pré-preencher o máximo que puder.

Lugares e endereços

Se o usuário pesquisar um lugar ou precisar inserir um endereço, você pode oferecer o preenchimento automático para ajudá-lo. Conforme eles digitam, uma API preencheria o restante do endereço para eles. Isso também reduz os erros.

Você poderia usar:

• API do Google Places
• Algolia Places, que é baseado no OpenStreetMap

Na França e em muitos outros países, você pode adivinhar a cidade com base no código de área. Portanto, se um usuário francês inserir um código de área, você poderá preencher automaticamente ou pelo menos propor a cidade. Meu país, Luxemburgo, é pequeno (não zombe de mim). Meu código de área está vinculado à minha rua. Então, se eu digitar meu código de área, o formulário deve até sugerir minha rua.

Cartões de crédito

Outra área em que a detecção automática é fácil são os cartões de crédito. Você não precisa perguntar ao usuário que tipo de cartão de crédito ele possui. Você pode detectar isso automaticamente com base nos números iniciais inseridos. Existe até uma biblioteca que pode fazer o trabalho para você.

Como usar o preenchimento automático de HTML5 (preenchimento automático)

O atributo de preenchimento automático HTML pode preencher previamente os campos com base nas entradas anteriores do usuário. Este atributo tem um estado ligado e desligado. Algumas pessoas inteligentes começaram a trabalhar em uma especificação para tornar isso mais poderoso e estender o atributo autocomplete para campos de formulário. O WHATWG também tem uma lista interessante.

O Chrome e outros navegadores móveis já suportam alguns dos valores estendidos para cartões de crédito e nomes. Isso significa que os usuários podem preencher formulários com seu nome e dados de cartão de crédito que usam em outros sites.

Em resumo, quando você precisar escolher entre sistemas diferentes, conte o número de interações que cada um exigirá.

Erros acontecem: como lidar com erros em formulários móveis

O último passo em nossa jornada em direção a formulários móveis melhores é lidar com erros e enganos. Podemos tentar reduzir os erros para aliviar a carga cognitiva do usuário. Também podemos ajudá-los a se recuperar de erros, porque não importa o quão bom seja o design do seu formulário, erros acontecem.

Evitando erros ao preencher os formulários

“Prevenir é melhor do que remediar”, minha mãe costumava dizer. Isso também vale para o design de formulários: evitar erros melhorará a experiência do seu formulário móvel.

Limitação de formato explícito

“Seja conservador no que você faz. Seja liberal no que você aceita dos outros.” Este princípio de robustez também pode ser aplicado a campos de formulário. Se possível, deixe o usuário inserir dados em qualquer formato.

Se você acha que precisa limitar o que um usuário pode inserir no campo, comece se perguntando “por quê”. No campo da experiência do usuário, temos uma técnica chamada “os três porquês”. Se a resposta for “porque blá blá banco de dados”, talvez seja hora de mudar as coisas. Por exemplo, por que você recusa caracteres especiais como e, a e o no campo de nome de usuário? Eu escrevi um artigo explicando como os formulários são rudes para mim quando tento digitar “Stephanie” como um nome de usuário. Ainda estou tentando descobrir uma boa razão para isso (além de razões de banco de dados).

Se você tiver um bom motivo para exigir um formato específico dos usuários, informe isso antecipadamente . Você pode usar placeholders HTML5 para dar aos usuários uma dica sobre como os dados devem ser, mas, novamente, tenha cuidado com eles. Você também pode usar todas as técnicas de descrição de campo explicadas no início deste artigo. Finalmente, as máscaras de entrada podem orientar os usuários para o formato correto.

Marcação de campos obrigatórios (e opcionais)

Não espere que os usuários enviem um formulário incompleto para informá-los sobre os campos obrigatórios. Se um campo for obrigatório, os usuários devem saber sobre ele . Marcar campos obrigatórios com um asterisco ( * ) e uma legenda tornou-se um padrão para formulários. A parte boa é que não ocupa muito espaço. O problema é que ele não tem valor semântico, então pode causar problemas de acessibilidade se mal codificado e se você confiar nos hábitos das pessoas com a interação do formulário.

Em vez disso, você pode marcar explicitamente os campos obrigatórios e opcionais com as palavras “obrigatório” (ou “obrigatório”) e “opcional”. Tanto o Instituto Baymard quanto Luke Wroblewski concordam com isso. Isso evita ambiguidade com formulários longos no celular, como ao usar um scroller, prosseguir com outra coisa, depois voltar e não lembrar se os campos obrigatórios foram marcados com um asterisco ou outra coisa.

Eventualmente, a decisão sobre como marcar esses campos dependerá do design e comprimento do campo e do contexto. A melhor maneira de saber se você tomou a decisão certa é, novamente, testar o formulário.

Padrões sensatos

Tenha cuidado com as opções padrão selecionadas nos formulários . Quando me candidatei ao meu emprego anterior, havia um formulário de informação. O estado civil era opcional. Eles fizeram o primeiro elemento no menu suspenso, “divorciado”, o campo padrão. Então, eu poderia não responder (porque era um campo opcional) e deixar o sistema acreditar que eu era divorciado, ou corrigir isso e divulgar meu estado civil real, mesmo que eu não quisesse.

Além disso, tenha cuidado com o gênero. Novamente, tenha uma opção para pessoas que não querem divulgar; deixe claro por que você está pedindo o gênero; melhor ainda, peça pronomes, ou não pergunte se você realmente não precisa. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• Ao fazer login
  Em um formulário de login, uma opção de mascarar/desmascarar senha melhoraria tremendamente a experiência do usuário.
  A Amazon tem um histórico interessante de iteração de senhas em seu formulário de login. Ele costumava ter uma versão em que você não podia ver a senha. A próxima iteração permitiu que os usuários o revelassem. Então, a senha foi revelada por padrão e você pode ocultá-la. Esta é a aparência em 2015:

  

  A Amazon testou a última versão e 60% das pessoas suspeitaram. Então, eles substituíram a caixa de seleção desmarcada "ocultar senha" pela caixa de seleção "exibir senha". Isso mostraria a senha em caracteres menores, sob o campo, enquanto o usuário digitava. Isto é o que parece no momento em que escrevo este artigo:

  

  Como você pode ver, sempre há espaço para melhorias.

Validação em linha

Se você estiver familiarizado com os princípios de usabilidade, talvez conheça a lei da proximidade da Gestalt. No celular, evite o resumo de erros no topo da página, sem informações contextuais, depois que o usuário tocar no botão enviar.

Em vez disso, as mensagens de erro devem ser localizadas próximas aos próprios erros .

Validação em tempo real

Você também não precisa esperar até que os usuários apertem o botão de envio. Você pode validar campos e exibir comentários enquanto o usuário os preenche .

Algumas dicas:

• Conforme mencionado anteriormente, os campos de senha se beneficiariam da validação e feedback em tempo real em cada pressionamento de tecla.
• Você também pode validar nomes de usuário em tempo real quando as contas estão sendo criadas, para garantir que estejam disponíveis. O Twitter faz um bom trabalho nisso.
• Não valide cada pressionamento de tecla. Aguarde até que o usuário termine de digitar. (Use JavaScript blur para formulários da web ou apenas espere alguns segundos para detectar inatividade.)

Nota : *Mihael Konjevic escreveu um bom artigo sobre “Validação Inline em Formulários: Projetando a Experiência”. Ele explica o conceito de “ recompensar cedo, punir tarde .”*

“Se o usuário estiver inserindo os dados no campo que estava em estado válido , realize a validação após a entrada dos dados.”

“Se o usuário estiver inserindo os dados no campo que estava em estado inválido , faça a validação durante a entrada dos dados.”

A cor importa

Não estou dizendo que a cor importa apenas por causa do meu atual cabelo ruivo, rosa e roxo. A cor realmente importa no design de formulários.

Existem algumas convenções na web que você não quer quebrar. Usuários não daltônicos sabem que vermelho é para erros, amarelo é para avisos e verde é quase sempre para confirmação ou sucesso. É melhor ficar com essas três cores. O vermelho pode deixar as pessoas ansiosas, no entanto. O usuário pode pensar que cometeu um erro muito sério. Usar laranja ou amarelo para mensagens de erro pode causar menos pânico. O problema com o amarelo e o laranja é que é difícil encontrar tons amigáveis ​​para daltônicos.

Falando em daltonismo: a cor não deve ser a única maneira de transmitir uma mensagem de erro . Este é um critério de acessibilidade.

No exemplo abaixo à esquerda, o campo com erro está na cor laranja e o campo que foi corrigido ficou verde. Eu usei uma ferramenta de teste daltônico para tirar a captura de tela no meio: você não pode mais distinguir entre a borda cinza padrão e a verde. Adicionar alguns ícones na última captura de tela garante que as mensagens de erro sejam transmitidas para pessoas daltônicas.

Recuperando de erros: escrevendo mensagens de erro amigáveis

Neste ponto, fizemos todo o possível para ajudar os usuários a preencher nossos formulários e evitar erros. Mas às vezes, apesar de nosso melhor esforço, erros acontecem. É hora de descobrir como ajudar os usuários a se recuperar desses erros.

Primeiro, lembre-se: não sequestre o controle do sistema. Se um problema não for crítico, o usuário deve poder continuar interagindo com o restante da interface. Evite essas mensagens de erro de alerta JavaScript e modais que bloqueiam os usuários sempre que possível. Além disso, se seu formulário precisar de alguma permissão, solicite-o no fluxo de uso. Se a permissão não for concedida, não considere isso um erro porque não é. Tenha cuidado com a cópia que você usa aqui.

Você não é um robô, nem seus usuários

Robôs são legais, eu sei. Mas você não é um robô, nem seus usuários. No entanto, muitas mensagens de erro ainda são tão mal escritas. Aqui estão algumas dicas quando se trata de mensagens de erro amigáveis:

• Nunca mostre uma mensagem de erro bruta, como “Ocorreu um erro do tipo 2393. O servidor não pôde concluir a operação.” Em vez disso, explique o que aconteceu em linguagem humana e por que aconteceu .
• Nunca mostre uma mensagem de erro sem saída, como “Ocorreu um erro”. Em vez disso , sugira maneiras de se recuperar do erro . Escreva uma cópia acionável.
• Nunca mostre uma mensagem de erro vaga, como “Não foi possível encontrar um servidor com o nome de host especificado”, com um botão “Tentar novamente”. Em vez disso, torne as mensagens de erro informativas e consistentes . Por favor, não soe como um robô.
• Não presuma que as pessoas conhecem o contexto de uma mensagem. Seus usuários não são geeks com experiência em tecnologia. Em vez disso, explique a eles em linguagem simples, sem jargão técnico, como se recuperar desse erro .

Cuidado com a linguagem que você usa nas mensagens

O que quer que você escreva, evite fazer as pessoas se sentirem estúpidas por causa de um erro. Se possível, omita palavras negativas ; tendem a assustar as pessoas e deixá-las ainda mais ansiosas. Em vez disso, use um tom cortês, positivo e afirmativo.

Não culpe os usuários por erros ; culpar o sistema em vez disso. O sistema não vai guardar rancor, eu prometo. Desloque a atenção do usuário para como o sistema não conseguiu processar a ação e explique a ele como encontrar uma solução .

Um pequeno truque é ler sua própria mensagem em voz alta. Ele irá ajudá-lo a ouvir se funciona ou é muito duro ou muito casual, etc.

Você também pode ser criativo com mensagens de erro e incorporar imagens e humor para torná-las menos ameaçadoras. No entanto, isso realmente dependerá da identidade e do tom da sua marca.

Para ajudá-lo a escrever uma mensagem de erro melhor, sugiro que você leia o seguinte:

• “Uma lista de verificação de microcópia de 6 pontos para equipes de produtos sem escritores de UX”
• “A arte da mensagem de erro: escrever uma cópia clara e útil para quando as coisas dão errado”

Hora de enviar o formulário

O usuário preencheu o formulário, não há mais erros e tudo parece bem. Finalmente, é hora de enviar o formulário!

A primeira regra é não mascarar o botão de envio . A sério! Eu me pergunto que mente distorcida surgiu com essa ideia, mas eu já vi isso em algumas formas. O botão enviar seria exibido apenas quando todos os campos obrigatórios fossem preenchidos sem erros. É perturbador para o usuário se perguntar se algo está errado ou se o botão do formulário não foi carregado ou se o site está quebrado e assim por diante.

Se você não quiser que os usuários possam clicar no botão de envio se faltarem campos obrigatórios ou se houver erros de validação, use o atributo HTML disabled na entrada de submit . Você precisará reativar o botão usando JavaScript assim que o formulário estiver válido e pronto para envio.

Se você tiver um apelo à ação primário e secundário, use cor, tamanho e estilo para mostrar a hierarquia .

Se você está se perguntando se o botão de confirmação deve vir antes ou depois do botão de cancelamento, eu também (e muitas outras pessoas). Se você estiver criando um aplicativo nativo, siga as diretrizes do sistema operacional. Tornou-se particularmente divertido desde que o Android mudou as posições dos botões em sua quarta versão. Na web, é mais complicado porque não há diretrizes reais. Independentemente do sistema operacional, aqui estão algumas diretrizes gerais para botões de envio otimizados para dispositivos móveis:

• Dê ao apelo à ação verbos descritivos e acionáveis.
• Forneça feedback visual quando o usuário tocar nele.
• Se você tiver dois botões, destaque a ação principal .
• A menos que você esteja trabalhando em um formulário corporativo de back-office muito específico (nesse caso, você terá muitos desafios de otimização para dispositivos móveis), evite um botão de redefinição . Os usuários podem confundi-lo com o botão de envio e perder todos os seus dados por acidente.

Conclusão

Nesta primeira parte, discuti várias pequenas técnicas para levar seu formulário ao próximo nível e ajudar os usuários a preenchê-lo. Algumas dessas diretrizes gerais e práticas recomendadas para dispositivos móveis podem não funcionar 100% do tempo - esse é o problema com as melhores práticas. Portanto, sempre teste seus formulários em usuários reais e dispositivos reais e adapte as diretrizes às necessidades e experiências específicas de seus usuários.

Além disso, faça alguns testes funcionais automatizados e de regressão — novamente, em dispositivos reais. O emulador móvel do Chrome não será suficiente para testar formulários otimizados para toque. Digo isso porque lancei um site de comércio eletrônico com um formulário de pesquisa que não funcionava no celular. Só fizemos testes automatizados usando um emulador. Aqui está o que aconteceu. O formulário de pesquisa estava oculto sob um ícone de pesquisa. Você pode tocar no botão, que abriu uma caixa com o campo de pesquisa. Funcionou emulando um mouse hover como um evento de toque. Testamos tocar no botão e ele abriu a caixa. Ninguém tentou iniciar uma busca. Assim, ninguém (nem mesmo o cliente) viu que o campo de busca desaparecia assim que os usuários tentavam interagir com ele. O que aconteceu? Quando o elemento de entrada ficou em foco, o botão perdeu o estado de foco, então fechou a caixa com o campo. O teste automatizado não conseguiu detectar isso porque a entrada não estava perdendo o foco. Então, lançamos um site de comércio eletrônico sem funcionalidade de pesquisa no celular. Não é uma super experiência.

Na segunda parte desta série, veremos técnicas específicas para dispositivos móveis mais avançadas. Veremos como usar recursos HTML5 interessantes para formatar campos e como usar recursos móveis para levar a experiência do usuário móvel ao próximo nível.