Padrões de design frustrantes que precisam ser corrigidos: seletor de aniversário

Você já os viu antes. Padrões de design confusos e frustrantes que parecem persegui-lo em todos os lugares, de um site para outro. Talvez seja um botão de envio desativado que nunca comunica o que está realmente errado, ou dicas de ferramentas que - uma vez abertas - cobrem o campo de entrada apenas quando você precisa corrigir um erro. Eles estão por toda parte, e são irritantes , muitas vezes nos jogando de um beco sem saída para outro, em algo que parece uma ratoeira bem orquestrada e mal projetada.

Esses padrões não são maliciosos nem malignos. Eles não têm muito em comum com avisos de cookies enganosos ou CAPTCHAs misteriosos disfarçados de hidrantes e faixas de pedestres. Eles também não são projetados com más intenções ou danos em mente: ninguém acorda de manhã esperando aumentar as taxas de rejeição ou diminuir a conversão.

É só que ao longo dos anos, algumas decisões de design mais ou menos aleatórias tornaram-se amplamente aceitas e adotadas e, portanto, são repetidas várias vezes - muitas vezes sem serem questionadas ou validadas por dados ou testes de usabilidade. Eles se tornaram padrões de design estabelecidos . E muitas vezes muito pobres . Aparecendo de novo e de novo entre as reclamações dos usuários durante os testes.

Nesta nova série de artigos, vamos examinar mais de perto alguns desses padrões de design frustrantes e explorar alternativas melhores , juntamente com muitos exemplos e perguntas a serem lembrados ao criar ou projetar um. Esses insights são provenientes de pesquisas de usuários e testes de usabilidade realizados por você e colegas da comunidade e, claro, todos eles serão referenciados em cada uma das próximas postagens.

Começaremos com um padrão humilde e aparentemente inofensivo que todos já experimentamos em algum momento - o infame seletor de aniversário que muitas vezes é inacessível, lento e complicado de usar. Já escrevemos sobre os seletores de data e hora perfeitos com muitos detalhes, mas os seletores de aniversário merecem uma conversa separada.

UX frustrante: menu suspenso/widgets de aniversário a partir de 2021

Toda vez que você se candidatar a um emprego, abrir uma conta bancária ou reservar um voo, provavelmente terá que digitar sua data de nascimento . Obviamente, a entrada é uma data e, portanto, não deve ser muito surpreendente ver interfaces usando um widget semelhante a data-picker-calendar (nativo ou personalizado) ou um menu suspenso para solicitar essa entrada específica .

Provavelmente, podemos identificar as razões pelas quais essas opções são frequentemente preferidas. Do ponto de vista técnico, queremos garantir que a entrada esteja correta e detectar erros antecipadamente . Nossa validação deve ser à prova de balas o suficiente para validar a entrada, fornecer uma mensagem de erro clara e explicar exatamente o que o cliente precisa fazer para corrigi-lo. Nós simplesmente não temos todos esses problemas com um menu suspenso ou um widget de calendário. Além disso, podemos evitar facilmente qualquer diferença de localidade ou formatação fornecendo apenas as opções que se encaixam na conta.

Pode parecer que a melhor maneira de evitar que erros aconteçam é projetar uma interface do usuário de forma que os erros sejam difíceis de cometer. Isso pode significar ser estrito e explícito no design do formulário – basicamente permitindo apenas entradas bem formadas. Afinal, fornecer uma entrada mal formada é impossível se todas as escolhas disponíveis estiverem bem formadas. Mas, embora a entrada seja realmente bem formada, ela não precisa ser precisa, especialmente se fornecer essa entrada for cansativo e frustrante.

Na prática, também cometemos erros semelhantes com requisitos de senha muito complicados e rigorosos. Não é incomum ver as pessoas ficarem tão irritadas com esses requisitos que colocam senhas em uma nota adesiva na tela ou as escondem em um arquivo personal.txt na área de trabalho, apenas para poder digitá-las novamente, se necessário. Senhas de Wi-Fi corporativas e um SuperPIN complexo para banco online são bons exemplos disso em ação.

Acontece que as pessoas são muito criativas em dobrar as regras a seu favor, então quando um sistema não é utilizável, não é seguro; e quando uma entrada de formulário não é utilizável, os dados que recebemos serão menos precisos e levarão a mais erros. Em última análise, é claro que isso levaria a situações em que os usuários são bloqueados e forçados a abandonar a interface do usuário, pois não podem fazer nenhum progresso.

Há um outro lado dessa moeda também. É claro que poderíamos eliminar toda a complexidade e sempre fornecer um único campo de entrada, permitindo que os usuários digitem o que preferirem. Na prática, isso significa que eles realmente digitarão o que preferirem, geralmente de maneira mal estruturada e ineficiente.

No caso de uma entrada de aniversário, em testes de usabilidade, os clientes digitam qualquer coisa de julho a julho a 06 a 6 , muitas vezes com delimitadores aleatórios e alguns erros de digitação ao longo do caminho, e com uma ordem mista de dias, meses e anos. Validar essa entrada após o envio não serve bem aos usuários porque eles não sabem qual formatação de entrada funcionaria. Obviamente, também não atende bem às nossas necessidades.

Com nosso design, precisamos fornecer uma orientação respeitosa e direta , juntamente com uma implementação técnica acessível. Isso nos leva a algumas desvantagens comuns dos seletores de data e menus suspensos nativos.

As armadilhas dos seletores de data nativos e listas suspensas

Infelizmente, os seletores de data nativos , solicitados por <input type="date"> , trazem muitos pesadelos de acessibilidade. No momento da escrita, quando usados ​​imediatamente, eles não são uma opção muito acessível para praticamente qualquer tipo de entrada de data. Não apenas existem muitos problemas de leitor de tela, mas também problemas de foco e layout, mensagens de erro confusas e genéricas.

Eu vi um bom número de implementações desabilitando completamente a entrada do teclado (veja acima), exigindo que os clientes usem exclusivamente o widget de calendário do seletor de data nativo. E isso é dolorosamente, dolorosamente lento. Sem um fallback de entrada de teclado, os usuários precisam embarcar em uma longa jornada entre dias, meses e anos, levando dezenas e dezenas de toques ou cliques .

Embora saibamos a data imediatamente, a interface nos pede para navegar entre as datas e, em seguida, encontrar nossa data na visão geral mensal assim que chegarmos lá. Essa é a razão pela qual essas experiências são frustrantes.

Sob essa luz, os menus suspensos são muito mais rápidos e fáceis de navegar. Eles são acessíveis por padrão e, em vez de navegar entre meses e anos, basta localizar os números corretos em 3 listas - dias, meses e anos. Mas os drop-downs ainda são lentos. Eles têm problemas de zoom. Apertar as opções roláveis ​​é cansativo. Eles ocupam muito espaço. A lista de anos é longa. E ao especificar a entrada, precisamos tocar no controle, rolar (geralmente mais de uma vez), localizar e selecionar o destino e continuar para o próximo menu suspenso. Também não é emocionante.

Portanto, não é incomum ver menus suspensos considerados a interface do usuário de último recurso e geralmente substituídos por botões (por exemplo, para filtros), alternâncias, controles segmentados ou caixas de preenchimento automático que combinam a flexibilidade de uma caixa de texto com a garantia de um <select> - caixa. Dropdowns não são ruins em si; é apenas os usuários gastam muito mais tempo do que o necessário preenchendo os dados neles.

E então há uma pergunta sobre valores padrão . Enquanto com as listas suspensas geralmente não usamos nenhuma entrada ( mm/dd/yyyy ), com um seletor de data precisamos fornecer algum ponto de partida para a visualização do calendário. Neste último caso, ironicamente, a data de “início” costuma ser mais ou menos a data de preenchimento do formulário, por exemplo , 15 de maio de 2021 . Isso não parece ótimo, é claro, mas qual deve ser a data certa ? Precisamos começar de algum lugar, certo?

Bem, não há realmente uma data certa embora. Poderíamos começar cedo ou tarde, 3 meses atrás ou amanhã, mas no caso de um selecionador de aniversário, todas essas opções são pura suposição. E, como tal, eles são um pouco frustrantes: sem nenhuma entrada, os clientes podem precisar rolar de 1901 até o final da década de 1980 e, com algum conjunto de entradas, precisarão corrigi-lo, muitas vezes pulando décadas para frente e para trás. Essa interação exigirá uma precisão impecável na rolagem.

Não importa qual escolha façamos, estaremos errados quase o tempo todo . É provável que isso seja diferente para um site de reserva de hotel ou um serviço de entrega de comida e muitos outros casos de uso – mas não entrada de aniversário. Isso nos leva à conversa sobre como avaliar objetivamente o quão bem projetada é uma entrada de formulário.

Avaliando a qualidade do design do formulário

O design pode ser visto como uma questão muito subjetiva. Afinal, todos parecem ter suas próprias opiniões e preferências sobre a abordagem correta para um determinado problema. Mas ao contrário de qualquer tipo de auto-expressão ou arte, o design deve resolver um problema. A questão, então, é quão bem um projeto particular resolve um problema particular. Quanto mais inequívoca a representação da intenção do designer, menos erros os clientes cometem, quanto menos eles são interrompidos, melhor o design. Esses atributos são mensuráveis ​​e objetivos .

Na minha própria experiência, os formulários são o aspecto mais difícil da experiência do usuário. Existem muitas facetas difíceis, desde microcópia e layout de formulário até validação em linha e mensagens de erro. Acertar os formulários geralmente requer a exibição de erros de back-end e erros de terceiros corretamente no front-end e a simplificação de uma estrutura subjacente complexa em um conjunto de campos de formulário previsíveis e razoáveis. Isso pode facilmente se tornar um pesadelo frustrante em aplicativos legados complexos e integrações de terceiros.

Assim, quando se trata de design de formulários , em nossos projetos, sempre tentamos medir a qualidade de uma determinada solução com base nos 9 atributos a seguir:

• Modelo mental
  Quão bem nosso design de formulário se encaixa no modelo mental do cliente? Ao solicitar dados pessoais, precisamos perguntar exatamente o mínimo necessário para ajudar nossos clientes a começar. Não devemos solicitar detalhes pessoais ou confidenciais (sexo, aniversário, número de telefone), a menos que tenhamos uma boa razão para isso e expliquemos na interface do usuário.
• Complexidade
  Quantos elementos de entrada exibimos por página, no celular e no desktop? Se um formulário contiver de 70 a 80 campos de entrada, em vez de exibi-los todos em uma página ou usar um layout de várias colunas, pode ser uma boa ideia usar um padrão de lista de tarefas para dividir a complexidade em partes menores e gerenciáveis.
• Velocidade de entrada
  De quanto tempo e esforço o cliente precisa para preencher os dados corretamente? Para uma determinada entrada, quantos toques/pressionamentos de tecla/operações são necessários para preencher o formulário com os dados fornecidos com precisão, supondo que nenhum erro seja cometido ao longo do caminho.
• Acessibilidade
  Ao falar sobre a velocidade de entrada, precisamos garantir o suporte a vários modos de interação, principalmente usuários de leitores de tela e usuários de teclado. Isso significa definir rótulos adequadamente, botões grandes, rótulos colocados acima do campo de entrada e erros comunicados adequadamente, entre muitas outras coisas.
• Escalabilidade
  Se alguma vez precisássemos traduzir a interface do usuário para outro idioma ou adaptá-la para outro formato, quão simples seria e quantos problemas isso causaria? (Um exemplo típico de uma solução problemática é um padrão de rótulo flutuante, e falaremos sobre isso em um post separado.)
• Gravidade das interrupções
  Com que frequência interrompemos os clientes, seja com spinners de carregamento, validação inline antecipada ou tardia, congelando partes da interface do usuário para ajustar a interface com base na interface do usuário fornecida (por exemplo, quando um país é selecionado), a frequência de dados pré-preenchidos incorretamente, ou dados incorretamente corrigidos automaticamente?
• Taxa de sucesso do formulário
  Quantos clientes completam com sucesso um formulário sem um único erro? Se um formulário for bem projetado, a grande maioria dos clientes não verá nenhum erro. Por exemplo, isso requer que toquemos no preenchimento automático do navegador, a ordem de tabulação é lógica e fazer edições é convencional e óbvio.
• Velocidade de recuperação
  Quão alta é a proporção de clientes que conseguem descobrir o erro, corrigi-lo e passar para a próxima etapa do formulário? Precisamos rastrear com que frequência as mensagens de erro aparecem e quais mensagens de erro são mais comuns. É também por isso que muitas vezes é uma boa ideia passar pelo suporte ao cliente e verificar com eles primeiro o que os clientes costumam reclamar.
• Taxa de falha do formulário
  Quantos clientes abandonam o formulário? Isso geralmente acontece não apenas por causa da complexidade do formulário, mas também porque os clientes não conseguem encontrar uma maneira de corrigir um erro devido a validadores agressivos ou botões "enviar" desabilitados. Isso também acontece porque o formulário pede muitas informações confidenciais e pessoais sem um bom motivo.

Para entender como um formulário funciona, realizamos estudos de usabilidade com clientes que acessam a interface em sua própria máquina – seja dispositivo móvel, tablet, laptop ou desktop – em seu próprio sistema operacional, em seu próprio navegador. Pedimos para gravar a tela, se possível, e usar um protocolo de pensamento em voz alta, para acompanhar onde, como e por que os erros acontecem. Também estudamos a rapidez com que o cliente está se movendo de um campo de formulário para outro, quando para e pensa e quando a maioria dos erros acontece.

Obviamente, o grande número de toques ou cliques nem sempre sugere que a entrada foi direta ou complicada. Mas alguns modos de entrada podem ser mais propensos a gerar erros ou causar confusão, e outros podem ser discrepantes , exigindo apenas muito mais tempo em comparação com outras opções. É isso que buscamos nos testes.

Agora, vamos ver como podemos aplicá-lo ao problema de entrada de aniversário.

Projetando uma entrada de aniversário melhor

Se alguém lhe perguntar pelo seu aniversário, você provavelmente terá uma sequência específica de dígitos em mente. Pode ser ordenado em dd/mm/yyyy ou mm/dd/yyyy , mas será uma sequência de 8 dígitos que você repete em todos os tipos de documentos desde muito jovem.

Podemos explorar esse modelo simples do que é uma entrada de aniversário com um campo simples de entrada única que combinaria todas as três entradas – dia, mês e ano. Isso significaria que o usuário digitaria apenas uma sequência de 8 números, permanecendo no teclado o tempo todo.

No entanto, essa abordagem traz alguns problemas:

• precisamos dar suporte à formatação e mascaramento automáticos,
• precisamos explicar a posição da entrada dia/mês,
• precisamos dar suporte ao comportamento do botão Backspace na entrada,
• precisamos rastrear e ocultar/mostrar/exibir permanentemente o mascaramento,
• precisamos dar suporte a saltos para um valor específico (por exemplo, mês),
• precisamos minimizar os cliques de raiva e a navegação na entrada para alterar um valor específico em dispositivos móveis,
• Se a criação automática não for usada, precisamos criar um conjunto de regras de limpeza e validação para suportar qualquer tipo de delimitador.

Em seu livro sobre Padrões de Design de Formulários, Adam Silver argumenta que usar várias entradas em vez de uma entrada raramente é uma boa ideia, mas é uma boa opção para datas . Podemos comunicar claramente o que cada entrada representa e podemos destacar a entrada específica com estilos de foco. Além disso, a validação é muito mais fácil e podemos comunicar facilmente qual parte específica da entrada parece ser inválida e como corrigi-la.

Podemos fazer a transição automática do usuário de uma entrada para a próxima quando a entrada for concluída ou permitir que os usuários se movam entre os campos por conta própria. À primeira vista, o primeiro parece melhor, pois a entrada exigiria apenas 8 dígitos, digitados um após o outro. No entanto, quando as pessoas corrigem erros, geralmente precisam de buffers de entrada – espaço dentro do campo de entrada para corrigir a entrada existente.

Por exemplo, é comum ver pessoas digitando 01, percebendo que cometeram um erro, alterando a entrada para 010 e removendo o primeiro 0, apenas para terminar com uma string invertida (e correta) — 10. uma transição automática de um campo para outro, podemos estar causando menos problemas e tornando a interface do usuário um pouco mais previsível e fácil de lidar.

Para explicar a entrada, precisaríamos fornecer rótulos para o dia, mês e ano e talvez também mostrar um exemplo da entrada correta. Os rótulos não devem ser rótulos flutuantes, mas podem ficar confortavelmente acima do campo de entrada, junto com quaisquer dicas ou exemplos que queiramos exibir. Além disso, todas as entradas também podem ser destacadas no foco.

Ao longo dos anos, não consegui identificar um único problema com essa solução ao longo de anos de testes, e não é surpreendente o padrão usado no Gov.uk também.

Quando você precisa de um selecionador de datas, afinal

Embora a solução acima seja provavelmente mais do que suficiente para uma entrada de aniversário, pode não ser boa o suficiente para situações mais gerais. Podemos precisar de uma entrada de data que seja menos literal do que um dia de nascimento, em que os clientes terão que escolher um dia em vez de fornecê -lo (por exemplo, “ primeiro sábado de julho” ). Para este caso, poderíamos aprimorar os três campos de entrada com um widget de calendário que os usuários também poderiam usar. Uma entrada padrão dependeria da data atual ou de uma data futura que a maioria dos clientes costuma escolher.

Adam fornece um exemplo de código simples para o padrão de data memorável em seu NoStyle Design System. Ele resolve muito trabalho de desenvolvimento e evita muitos problemas de acessibilidade, e tudo isso evitando tocar em widgets de calendário ou rolar desnecessáriamente em rodas suspensas.

Empacotando

Claro, um bom controle de formulário depende do tipo de entrada de data que estamos esperando. Para planejadores de viagens, onde esperamos que os clientes selecionem uma data de chegada, uma entrada flexível com uma consulta de calendário pode ser útil.

No entanto, quando perguntamos aos nossos clientes sobre sua data de nascimento , estamos solicitando uma data muito específica - uma string muito específica, referindo-se a um dia, mês e ano exatos. Nesse caso, um drop-down é desnecessário. Nem é uma pesquisa de calendário, padronizando para um valor mais ou menos aleatório. Se você precisar de um, evite seletores de data nativos e listas suspensas nativas, se possível, e use uma solução personalizada acessível. E conte com três campos de entrada simples, com rótulos e explicações colocados acima do campo de entrada.

Também publicamos uma longa obra sobre como projetar um seletor de data e hora perfeito, juntamente com listas de verificação que você pode usar para projetar ou construir um.

Artigos relacionados

Se você achar este artigo útil, aqui está uma visão geral de artigos semelhantes que publicamos ao longo dos anos - e mais alguns estão chegando.

• Configurador responsivo perfeito
• Comparação perfeita de recursos
• Controle deslizante perfeito
• Acordeão Perfeito
• Form Design Patterns Book por Adam Silver, publicado no SmashingMag
• Assine nossa newsletter por e-mail para não perder as próximas.