Imagine um mundo em que todos os botões estão desativados por padrão . Normalmente é cinza, sutil e ligeiramente fora de foco, muitas vezes com pouco contraste e um rótulo de texto suave que é um pouco difícil de decifrar. Não está destinado a permanecer desativado para sempre. Ele se torna ativo eventualmente, uma vez que uma entrada bem formada é fornecida. Mas antes que possa dar vida à página com sua extravagância de gradiente de cores, ela apenas fica lá, calma e silenciosamente, cuidando da própria vida. Você gostaria de viver neste mundo?
É verdade que pode haver muito boas razões para desativar os botões por padrão. Afinal, como designers e desenvolvedores, queremos tornar mais difícil para nossos usuários cometer erros. Queremos evitar saltos desnecessários para a frente e para trás entre as mensagens de erro. Queremos garantir que a entrada esteja perfeitamente correta antes mesmo de os dados serem enviados para o servidor. E queremos indicar que algo importante está faltando antes que os usuários sigam para a próxima etapa.
Portanto, investimos tempo e esforço em uma validação inline resiliente e confiável . E tentamos o nosso melhor para fornecer feedback útil à medida que os usuários vão de um campo de entrada a outro. E, é claro, desabilitamos os botões por padrão para evitar cliques e toques prematuros que só levarão à valsa com mensagens de erro.
Essa abordagem pode funcionar muito bem para alguns cenários, mas acontece para ser um padrão de design desastroso para muitos cenários, muitas vezes ao ponto de os clientes ficarem completamente bloqueados, sem uma única chance de transmitir sua intenção à interface. Neste artigo, veremos problemas comuns de usabilidade com botões desabilitados, como consertar esses problemas e quando desabilitar botões realmente faz sentido. Começaremos do início, verificando quando os botões desabilitados causam mais problemas do que ajuda.
Parte de: Padrões de design
Parte 1: Perfect Accordion Parte 2: Perfect Responsive Configurator Parte 3: Selecionador de data e hora perfeito Parte 4: Comparação perfeita de recursos Parte 5: Perfect Slider Parte 6: Selecionador de aniversário perfeito Parte 7: Menus Mega-dropdown perfeitos Parte 8: Filtros perfeitos Parte 9: Botões desativados Assine nossa newsletter por e-mail para não perder as próximas. Como os usuários lidam com interfaces desativadas
Sempre que algo na interface é desativado, é um indicador de que algo está errado . Essa observação aparentemente óbvia pode não ser óbvia à primeira vista. Por exemplo, e se você quiser desmarcar uma caixa de seleção, mas a interface não permitir que você faça isso? Qual é exatamente o problema? Há algum problema com sua conexão com a Internet? Há algum problema com os privilégios do usuário? Você precisa esperar e torcer pelo melhor, ou prefere atualizar a página? E se você atualizar a página, todos os dados que você digitou com tanto cuidado e ponderação persistirão no formulário ou desaparecerão para sempre?
Quando encontramos um botão desativado, a situação não é muito diferente. Estamos bloqueados, mas não sabemos por quê. Pode ser que algo mais esteja faltando para que possamos seguir em frente. Ou esquecemos algumas letras miúdas em algum lugar. Ou talvez tenhamos cometido um erro de digitação em um dos campos de entrada. Ou não preenchemos os dados da maneira certa. Ou talvez não haja nenhum erro de nossa parte, e é um bug do sistema que está totalmente fora de nosso controle.
Existem tantas coisas que podem estar fazendo com que o botão seja desativado, e com mais frequência do que não os usuários são basicamente deixados na floresta, tendo que descobrir qual é a peça que faltava no quebra-cabeça. Nessas situações, eles geralmente mostram dois tipos de comportamentos ligeiramente diferentes , e esses comportamentos dependem do que exatamente está inacessível na IU.
Quando grandes partes da interface estão desativadas
Observar clientes interagindo com o estado desabilitado revela alguns padrões de usabilidade comuns. Quando grandes partes da interface estão desativadas , a maioria dos clientes presumirá que o sistema está ocupado e que algum processo está acontecendo em segundo plano na página. E porque algo está acontecendo, eles geralmente exercem uma boa dose de paciência primeiro. Eles ficarão sentados esperando que um botão giratório apareça ou a página volte eventualmente. Quanto mais valiosa for a entrada, mais tempo eles ficarão sentados lá e esperando.
Você provavelmente se comportará da mesma maneira. Por que é que? Acontece que fazemos isso apenas para evitar interrupções ou interrupções do processo em andamento. Assim como não sabemos se o gato de Schoredinger está vivo ou não sem olhar para a caixa, simplesmente não sabemos se a reserva foi aprovada ou não até olharmos o sistema, ou falarmos com alguém que o faça.
Se algo inesperado acontecer durante o processo de reserva, ou se acidentalmente apertarmos um botão errado na hora errada, seremos deixados de fora sem saber o que realmente aconteceu. Podemos ter mais garantias assim que recebermos um e-mail de confirmação, mas mesmo assim, não teremos certeza a menos que possamos entrar no sistema e verificar nossa reserva. E se o e-mail não chegar, também não seremos muito mais espertos.
Se quisermos descobrir o que aconteceu, temos que embarcar em uma longa jornada cheia de saltos de um cliente departamento de suporte para outro e às vezes passam horas em widgets de bate-papo tentando obter garantias de que o cartão não será cobrado duas vezes, ou de fato cancelamos uma assinatura.
Interrompendo um processo em andamento parece arriscado e imprevisível , então preferimos apenas sentar e esperar em frente a uma interface desativada-o limite de paciência é grande o suficiente para não entrarmos em toda aquela trabalheira e dificuldade para descobrir imediatamente.
No entanto, eventualmente, até mesmo esse limite é atingido e os usuários começarão a mover o ponteiro do mouse cautelosamente pela tela ou tentarão começar a mexer no teclado, ou tente rolar para cima e para baixo em seus dispositivos móveis. Se isso não funcionar, eles passarão para o próximo estágio, tentando trazer a página de volta à vida com algumas dezenas de cliques de raiva teimosos ou toques.
E se isso também não funcionar, alguns vão tirar uma captura de tela da interface como prova ou referência e talvez tentarão abrir a mesma página em outra aba do navegador. Usuários experientes chegariam ao ponto de abrir a página em outro navegador porque alguns sistemas desconectam usuários que tentam fazer login na mesma conta em várias guias.
O motivo de todo esse problema é que nós, como usuários, não queremos perder o estado e os dados da página desativada. Podemos ter digitado todos os dados corretos e escolhido todas as configurações corretas e talvez até mesmo nos dado ao trabalho de encontrar um código de desconto que funcione e até mesmo ter criado uma mensagem de presente perfeita. Portanto, no mínimo, devemos tentar capturar todo o trabalho que já fizemos e preencher novamente os dados em outra guia ou janela, em vez de fazer todo o trabalho duro novamente.
Quando apenas um único botão está desativado
O comportamento acima pode parecer esperado para páginas que bloqueiam a entrada do usuário totalmente, mas certamente deve ser diferente nos casos em que apenas uma pequena parte da interface-vamos diga um humilde botão “Continuar”-não está acessível? Ironicamente, os mesmos problemas aparecem com botões autônomos também, embora reconhecidamente em menor grau.
Com os botões desativados, como o resto da interface é acessível, os usuários parecem ter mais confiança de que há um
Um problema que aparece quando os usuários encontram um botão desativado no final do processo, especialmente no celular. Muitos não percebem se o botão foi desativado desde o início ou se há algo em sua entrada que o desativou ao longo do caminho. Algumas pessoas até reabrem a mesma página em outra guia para verificar qual era o estado inicial.
Assim, uma vez que o formulário em uma página parece estar preenchido, os usuários vão imediatamente para o“ Continuar ”quase no piloto automático. Se esse botão estiver desativado, a primeira coisa que quase se pode sentir ao observar os movimentos dos usuários é uma desaceleração massiva de interação . É literalmente como se os usuários estivessem batendo em uma parede. Algumas pessoas vão querer verificar se o botão está realmente desativado, passando o mouse sobre ele, tentando clicar/tocar nele ou usar a tecla Tab para acessar o botão-muitas vezes clicando várias vezes para ver se ele realmente responderá. Na maioria das vezes, não vai acontecer muita coisa.
Se o botão não responder, os usuários primeiro procuram os suspeitos de costume-formatação errada, pontuação ausente ou caracteres de acento que causaram o problema. Se não ajudar, a maioria dos usuários percorrerá todo o formulário , geralmente campo por campo, de cima para baixo e vice-versa, e tentará eliminar todos os possíveis problemas que possam estar causando o estado de desativação.
Por exemplo, é comum ver pessoas redigitando o número do telefone, com e sem +, com e sem zero à esquerda, com e sem espaços vazios. Às vezes, eles até redigitam toda a entrada campo por campo, porque presumem que o navegador pode ter recebido dados”incorretos”com o preenchimento automático do navegador que foi usado para alguns campos de entrada.
Na verdade , eles experimentam todas as combinações possíveis de formatação de rua, referências de número de pedido, datas e horas e sobrenomes e saudações e tudo mais-o que em muitos aspectos nada mais é do que adivinhação, porque nunca sabemos como o aplicativo funciona e quais mudanças de entrada afetarão seu comportamento.
Esse é um bom exemplo de uma experiência verdadeiramente frustrante. E, é claro, normalmente assumimos que todo esse aborrecimento é facilmente evitável com uma validação inline de última geração que detectará os erros antecipadamente. Acontece que muitas vezes não é tão simples.
A validação em linha nunca é à prova de balas
Em teoria, tudo o que abordamos nas seções anteriores nunca deveria acontecer. Afinal, não é isso que a validação inline deve corrigir em primeiro lugar? Em vez de mostrar mensagens de erro após todas as entradas terem sido feitas, nós as mostramos uma a uma conforme os usuários cometem seus erros-geralmente depois de deixar o campo de entrada. Mas com que frequência ele falhou em você?
Já aconteceu de seu endereço de entrega não ter sido aceito por um validador de endereço-talvez porque o prédio acabou de ser construído recentemente? Ou talvez você tenha usado uma sintaxe perfeitamente válida, mas ligeiramente complicada para evitar spam, por exemplo, *[email protected] , * mas o validador de e-mail assumiu que o caractere + não pode ser um parte do e-mail?
E se você ainda não tiver um e-mail comercial, mas o serviço não aceitar um endereço do Gmail? Ou talvez haja alguns dados que você não deseja fornecer-por exemplo, idade, sexo, aniversário ou um número de telefone-e embora sejam destacados como opcionais, a interface não permite a passagem de um valor vazio?
Embora existam muitos cenários em que a validação inline funciona bem, existem o mesmo número de exceções e casos extremos quando a validação inline não funciona :
quando um endereço postal não pode ser confirmado por um validador de endereço ligeiramente desatualizado ou sugestões automáticas, quando um não o número de imposto em conformidade (TIN/VAT) não valida, embora seja perfeitamente válido, mas ainda não é padronizado entre os países, quando algum tipo de proteção anti-spam é usado no formulário, mas está bloqueado por um bloqueador de anúncios agressivo, quando o usuário bloqueia o rastreamento , mas a entrada de localização deseja desesperadamente detectar a localização do usuário e quebras, quando extensões de navegador de terceiros preenchem dados (por exemplo, códigos de cupom), mas são eventualmente bloqueado pelo sistema, sem como continuar, quando o usuário salva sua entrada em um complexo formulário um dia, retorna eventualmente, mas o botão “Continuar” está desabilitado porque os documentos enviados estão sendo processados. quando qualquer entrada é baseada em um determinado grupo de clientes frequentes e uma entrada perfeitamente válida não atende aos requisitos personalizados para eles, quando um e-mail tem prefixos ou caracteres perfeitamente válidos, mas a validação inline não é muito precisa e não t reconhecer certos personagens.
Na prática, mesmo a validação inline mais sofisticada pode apresentar falhas às vezes . E quando falha, falha muito. Um usuário que por acaso é bloqueado por um validador embutido não tem absolutamente nenhuma chance de enviar o formulário com sucesso porque o botão de envio estará sempre inacessível. Essa situação garante uma taxa de abandono de 100% para esses clientes.
É claro que pode haver apenas um punhado de pessoas tendo essa experiência, ou alguns milhares em um determinado dia. Rastrear quantas pessoas realmente acabaram nessa situação é um bom começo para entender a gravidade dos botões desativados para sua empresa.
Não só esse é o custo. Por sua natureza, a validação em linha é um limite rígido com requisitos muito específicos e rígidos. No entanto, muitas vezes os usuários se encontram em situações complexas que não podem ser previstas com antecedência. Talvez a maioria dos detalhes sejam conhecidos e os prazos estejam se aproximando, mas alguns documentos estão faltando e, portanto, toda a entrada deve ser abandonada.
Isso geralmente resulta em um aumento nas ligações e consultas de suporte ao cliente ou apenas clientes insatisfeitos que cancelam suas contas e nunca olham para trás.
De muitas maneiras, lidar com botões desativados pode ser parecido com jogar um dado. Os usuários podem ter sorte e campos de entrada incorretos serão destacados ou podem ter menos sorte e a interface não fornecerá nenhuma pista significativa. Eles então terão que encontrar e corrigir esses problemas, passar pela validação e, finalmente, desbloquear o botão todo-poderoso para continuar. Isso é frustrante no desktop, mas fica ainda mais frustrante no celular quando o botão geralmente não está visível porque está fora da tela na parte inferior da página.
Como Matthew Standage notes , “quando desativamos um botão em um formulário, estão frequentemente desativando a frase de chamariz-aquela coisa na página que tentamos encorajar os usuários a clicar para prosseguir com sua jornada. “E, como tal, é uma tarefa muito perigosa e frágil , porque nós nunca saiba com certeza absoluta o quão à prova de balas nosso código é, mesmo que ele possa ser fortemente testado.
As desvantagens dos botões desativados
Os exemplos acima indicam um problema muito comum que está na própria natureza de muitas implementações. Botões desativados não explicam o que há de errado . Eles comunicam que algo está errado, mas muitas vezes não é bom o suficiente. Como resultado, muitas vezes os usuários ficam se perguntando o que realmente está faltando e, consequentemente, são totalmente bloqueados.
Sem falar nos muitos pesadelos de acessibilidade que surgem. Como Adam Silver observa em seu excelente livro “ Form Design Patterns ”, os botões normalmente desabilitados não são focalizáveis e, portanto, os usuários podem não os alcance com um teclado. A razão pela qual geralmente pulamos o foco nesses botões é porque eles não podem realmente ter interação. (Veremos abaixo que há espaço para melhorias, como veremos).
Por sua natureza, os botões desativados também apresentam contraste insuficiente , pois devem ter uma aparência diferente em comparação com os botões normais. Como tal, eles também são difíceis de ler, pois geralmente estão acinzentados. Eles contam com JavaScript e validação em linha, e no fato de que os usuários podem identificar e corrigir erros facilmente-o que pode ser difícil de fazer de uma forma complexa em uma tela estreita, por exemplo.
E então há uma questão de tempo . Em que ponto devemos ativar um botão desativado ? A maioria das implementações habilita o botão apenas se todas as entradas necessárias parecerem bem formadas ou/e tiverem sido verificadas por um validador embutido. Essa é definitivamente a última hora para mudar de direção, mas e as situações em que isso poderia estar acontecendo antes?
E se um cliente estiver abrindo sua conta bancária e precisar verificar seu local de residência fiscal, junto com alguns outros documentos? Ou, talvez, se alguma entrada não puder ser verificada imediatamente, mas precisar ser enviada por proxy por meio de outro serviço, mas esse serviço continua expirando? Ou talvez alguns fornecedores não tenham enviado suas cotações finais ainda, mas o projeto precisa ser adicionado ao sistema com urgência?
Em todos esses cenários, os usuários não têm todos os documentos necessários em mãos no momento em que preenchem o formulário. Agora imagine que todos esses serviços fornecem uma janela de 14 dias após a abertura da conta, quando os documentos que faltam podem ser enviados. Tecnicamente, os clientes ainda devem ser capazes de prosseguir sem esses documentos, mas, para isso, eles precisam escolher”Enviar mais tarde”para cada documento ausente à medida que preenchem o formulário.
Então quando devemos habilitar o botão desabilitado? Devemos alterar o estado apenas quando o usuário tiver solicitado o envio dos documentos mais tarde para todos eles, ou devemos deixá-los passar, mesmo que eles não tenham optado (e lembrá-los de que precisamos que eles sejam carregados em 14 dias) ? A maioria de nós concordará que a primeira opção é provavelmente mais óbvia, mas apenas se o usuário puder identificar a opção de enviar documentos mais tarde. A segunda opção provavelmente vai aumentar a conversão e trazer mais leads.
O ponto principal é: quanto mais lógica condicional desse tipo tivermos em nossos fluxos de usuário-ela pode se tornar bastante complicada em grandes formulários empresariais e B2B-mais cautelosos precisamos ser ao acionar esse botão.
Tudo isso para não dizer que os botões desabilitados devem sempre ser evitados a todo custo. Eles funcionam bem quando atendem a um propósito muito pequeno e muito específico.
Quando os botões desativados (e os estados) funcionam bem
Imagine que você está comprando um par de jeans que por acaso está à venda. A interface informa que há exatamente um item restante, tão cheio de esperança que você corre para a página do produto, escolhe rapidamente o seu tamanho, adiciona o item ao carrinho-apenas para perceber que o item não está mais disponível . Essa não é a experiência do usuário mais edificante. Aqui, desabilitar o botão “adicionar ao carrinho” quando uma opção não estiver disponível é apenas razoável para evitar confusão e frustração.
Ou talvez você esteja prestes a transferir grandes fundos de uma conta bancária para outra. Você verificou todos os campos de entrada, o valor, o destinatário, o IBAN e o SWIFT e revisou todas as taxas e está pronto para continuar-felizmente, um botão verde brilhante está ali esperando por você para continuar. E bem naquele momento, cheio de foco e entusiasmo, seu mouse escorrega ou seu dedo pula sobre a tela sensível ao toque-e você pressiona aquele botão verde brilhante duas vezes.
O que vai acontecer? Você provavelmente não deseja enviar os fundos duas vezes. E você também não gosta de pular entre o aplicativo de autenticação de 2 fatores e a interface do banco-no entanto, o sistema lhe enviou dois códigos de confirmação e não é óbvio qual você deve usar para confirmar o pagamento.
Portanto, ter um botão desativado depois de pressionado uma vez é um bom indicador de que o estado mudou e que algo está acontecendo e que nada mais precisa ser feito para que a operação prossiga e que você precisa apenas sentar e esperar que a interface volte. É aí que os botões desativados são úteis.
Quando uma opção ou um recurso não está disponível ou algo está acontecendo em segundo plano, precisamos comunicá-lo com antecedência e claramente. Uma mudança visível no botão ajuda nisso, mas também podemos explicar por que o botão está desabilitado e o que exatamente está acontecendo. Por exemplo, poderíamos alterar o rótulo no botão para dizer “Adicionando ao carrinho…” com um indicador de carregamento em loop para tornar mais óbvio o que exatamente está acontecendo.
Comunicar isso algo não é possível é tão importante quanto evitar que os usuários cometam erros caros. Aqui estão alguns cenários em que isso pode ser útil:
para evitar compras erradas : se o preço depende de alguns atributos, é razoável desativar o botão e ajustar seu rótulo enquanto o preço é sendo ajustado, para evitar reservas duplas : assim que um botão for clicado, é razoável desabilitar o botão e substituir um CTA por um botão giratório de progresso ou alterar o rótulo para “Esperando…”. Uma dica pode fornecer mais ajuda e informações sobre o que está acontecendo. Poderíamos então mudar o rótulo mais uma vez se levar muito tempo para obter uma resposta do servidor. Obviamente, também queremos parar de ouvir cliques/tap após o primeiro clique/toque (as exceções são botões Desfazer e steppers, onde você espera que os clientes toquem no mesmo botão várias vezes-ter um botão desativado provavelmente não é uma ideia muito boa). para validar o login mágico/código SMS ou para validar uma contagem de caracteres: aí, manter os botões desabilitados até que a entrada seja concluída pode ser razoável. No entanto, é uma boa ideia testar se um botão”Validar”ativo funcionaria pior. As chances são altas de que não.
Desativar botões pode ser uma boa ideia em alguns cenários, afinal. Mas provavelmente podemos fazer melhor do que um botão esmaecido com contraste insuficiente. Vamos dar uma olhada em algumas técnicas para tornar os botões desabilitados um pouco mais inclusivos.
Como tornar os botões desabilitados mais inclusivos
E se nossa implementação depender de botões desabilitados ou devido a limitações técnicas e restrições legadas, é incrivelmente difícil Afaste-se deles? Em seu excelente artigo sobre Como tornar os botões para deficientes mais inclusivos , Sandrina Pereira destaca algumas técnicas excelentes (e trechos de código) para tornar os botões desabilitados melhores se você tiver que usá-los.
Aqui estão algumas estratégias úteis que Sandrina sugeriu:
alterar o cursor em um botão desabilitado para indicar que os usuários não podem interagir com ele (cursor: não permitido), mostre uma dica ou uma dica explicando porque o botão está desabilitado; se um cliente usa um mouse/toque, podemos mostrar uma dica de ferramenta ao passar o mouse, clicar ou tocar, e quando um usuário navega para o botão por meio da tecla”Tab”, podemos acionar a dica de ferramenta também (no entanto, o botão deve ser focalizável), evite o clique programaticamente via JavaScript usando o atributo aria-disabled e, assim, evitando a perda temporária do foco do teclado enquanto o formulário está sendo enviado (o que seria o caso apenas com o atributo disabled ), aria-disabled ainda focalizará o botão e anunciará que ele existe, mas que ainda não está ativado; da mesma forma que você pode perceber visualmente, use regiões ao vivo ARIA para anunciar conteúdo dinâmico, evite eventos de ponteiro: nenhum em CSS; realmente evita um clique do mouse, mas não impede o foco e a navegação do teclado.
Como alternativa para a dica ou dica, podemos guiar o usuário para os erros no formulário, seja com um link para o resumo do erro na parte superior da página ou com links de salto para campos de entrada específicos que parecem conter erros. E poderíamos apenas incluir uma dica ao lado do botão desativado para explicar por que ele está desativado (conforme mostrado abaixo).
Com todos esses pequenos ajudantes no lugar, podemos explicar muito melhor o que está realmente errado e como corrigi-lo. Mas se quisermos reduzir as taxas de becos sem saída e abandono mais agressivamente, podemos ir um pouco mais longe.
Sempre forneça uma saída
Como a realidade é complexa, às vezes é incrivelmente difícil para uma interface para prever todas as opções que os clientes podem querer escolher com antecedência. Muitas vezes, o contexto do usuário é simplesmente imprevisível e é influenciado por coisas que estão fora de nosso alcance. Portanto, no caso de uma entrada malformada ou de um erro, devemos dar aos nossos clientes o benefício da dúvida e fornecer uma maneira de preencher o formulário, mesmo que ele não atenda inteiramente aos nossos requisitos ou expectativas.
Uma técnica útil que descobrimos em testes de usuário é não apenas adicionar uma dica ao lado de um botão desativado que explica o que está errado, mas também adicionar um link de “saída” abaixo dele. O link solicita que os clientes entrem em contato com o suporte ao cliente caso não possam prosseguir.
O botão literalmente diz:“ Não consegue continuar? Informe-nos e entraremos em contato com você. ” Ao clicar no link, o usuário pode deixar seu e-mail ou número de telefone e optar por ser contatado pelo atendimento ao cliente. Ou podemos ir ainda mais longe, enviando automaticamente um e-mail para o suporte ao cliente com todos os detalhes digitados no formulário em nome do cliente, com a opção de retornar a ligação ou responder por e-mail.
Outra opção é permitir que os clientes continuem apesar dos erros , por exemplo mesmo que o endereço postal não pareça estar correto ou um número de telefone pareça estar errado. É claro que precisamos notificá-los de que algo parece estar errado, pedir que revejam e verifiquem suas sugestões e peça permissão para contatá-los caso algum problema apareça. Podemos querer consultar os erros mais uma vez antes que eles cliquem no botão’Comprar agora’.
Agora, essas pequenas alterações não levarão o abandono a 0, mas pelo menos nos dão a chance de mantenha o cliente caso ele não possa prosseguir e faça seus negócios resolvendo dificuldades técnicas para ele, em vez de descarregar esses problemas para ele.
Precisamos de validação em linha?
Com essas melhorias implementadas, pode ser uma boa ideia revisitar a função da validação embutida. São tantas as questões que precisam ser discutidas-quando devemos começar a validar, quando acionamos um validador se um usuário está editando um campo válido ou inválido, quando mostramos mensagens de erro ou confirmação de que a entrada está correta. Todas essas perguntas merecem um artigo separado, mas em geral, manter a validação in-line e, ao mesmo tempo, fornecer uma saída é razoável, mas não precisa ser acompanhada de botões desabilitados.
Na verdade, a validação in-line is likely to be more helpful without a disabled button as users might get a better overview of the correct and incorrect input by having erroneous input fields highlight on submit. That, of course, requires buttons to be accessible at all times. In fact, it’s not such a bad idea at all.
An Alternative To Disabled Buttons
To avoid all the hassle customers have to endure with disabled buttons, we could make the experience much more straightforward by keeping the “Continue” button accessible at all times, and using the click to communicate to the user what’s actually wrong.
Below is a good overall strategy that always proves to be working without any usability issues:
validate the input on submit, on submit, explain that there are errors and show how many errors there are (as a tooltip or an error message), if there is only 1 error, point users directly to the input fields that contains the error (with a simple text link), if there are more errors, show an error summary on the top of the page and show a link to the error summary on submit. 
Enable the button, then show errors when needed. (Image source: Disabled Buttons Don’t Have To Suck)
Simple, straightforward, accessible, easy to implement, and without any reliance on code to be working flawlessly to bring a disabled button back to life.
If, however, user’s selection needs to done, perhaps we could get away by relying on frequently used default values instead of asking the user to make a selection explicitly. For example, Blue Apron provides a default selection for its number of recipes delivered per week, and so the “Select” button is active because it always indicates the next step.
And sometimes disabled buttons could be replaced with something slightly more actionable. In the case when an item is no longer available, for example, we could include the number of available items in the size selector. If an option is unavailable, we could show that the option isn’t available rather than hiding it altogether.
Alternatively, we could add a hint above the button explaining that the item is out of stock, or even allow users to get notified once it’s back in stock again. Below is an example of this pattern on Zalando.
Whenever dealing with disabled buttons, we might want to ask ourselves if there is any better way to communicate the options that the user has, and think about the ways connect with them despite the errors — with a default selection, tooltips and hints, as well as actionable calls to action (e.g. be notified about updates).
Wrapping Up
You can’t know what you can’t measure. If you already have an implementation with a disabled button, study how many people actually end up in locked-out situations and can’t proceed. That will give you a good start to understand how severe disabled buttons are for your business.
If you need to use disabled buttons, consider ways to make them focusable and useful by also making them more inclusive and providing a way out for customers to send all the details to the customer support. If you don’t need to make the buttons disabled, validate on submit and guide users directly to errors with sensible error messages. Either way, inline validation can be helpful in giving users a sense of progress as they are making their way through the form, but make sure that users can proceed even if inline validation fails.
That should be enough to avoid frustration and hassle when dealing with disabled buttons, and hopefully will clear a path towards an accessible and simple form that has fewer abandonments and faster completion.
Disabled Buttons Checklist
As usual, here’s a checklist with pretty much everything to ask and double check when designing or building an interface with disabled buttons:
Do we need the button to be disabled by default (e.g. item is unavailable)? If not, can we keep it enabled and validate user input on submit? If not, can we rely on default values to keep the button enabled by default? When should the button become disabled (e.g. prevent double bookings)? Do we want to grey out any part of the interface along with the disabled button? Do we want to use a skeleton screen animation along with the disabled button? Do we want to use a loading spinner for the UI to indicate that the system is busy? Do we want to use a progress indicator on the button to indicate progress? Should the wording on the button be different when it’s disabled? Does it have sufficient color contrast in the disabled state? Do we want to add a note under the button explaining why it is disabled? Do we keep the disabled button focusable? What happens when a user hovers or taps on the disabled button? What happens when a user tries to activate or focus on the disabled button? Do we change the cursor to not-allowed to indicate that the action isn’t allowed? Do we want to use a tooltip explaining why the button is disabled? Do we prevent the click via JavaScript by using aria-disabled? Do we use ARIA live regions to announce dynamic content? Do we avoid pointer-events: none as it doesn’t prevent focus/keyboard navigation? Do we guide users towards errors when they tap/click/tab to the disabled button? When do we enable a disabled button? Can we add a link that sends all user’s input to support if they are locked out? In that case, do we ask users for their consent to be contacted? Do we use inline validation (positive or negative)? When and how do we show error messages? Do we include an option to continue even if inline validation fails? Do we need to update the state of the button after every user input? How will the button change while updating its state? Do we change the label of the button (“Updating…”) while it’s updating? Do we change the colors of the button while it’s updating? Do we want to add a loading spinner while the button is updating? Should we stop listening to click/tap after the first click/tap? Do we not stop listening to click/tap for Undo buttons and steppers? Can we make the disabled button sticky on narrow screens? Do we track how many people can’t proceed and abandon the flow altogether? If applicable, can we test if a design without disabled buttons performs better?
Part Of: Design Patterns
Part 1: Perfect Accordion Part 2: Perfect Responsive Configurator Part 3: Perfect Date and Time Picker Part 4: Perfect Feature Comparison Part 5: Perfect Slider Part 6: Perfect Birthday Picker Part 7: Perfect Mega-Dropdown Menus Part 8: Perfect Filters Part 9: Disabled Buttons Subscribe to our email newsletter to not miss the next ones.
Further Resources
“Why Heuristics Are Only Rules Of Thumb: The Case Of The Disabled Button,” Matthew Standage, UX Collective “Why You Shouldn’t Include Disabled Interaction Elements In Your Design System,” Chris Atherton, UX Collective “Disabled Buttons Suck,” Hampus Sethfors, Axess Lab “Disabled Buttons Don’t Have To Suck,” Justine Win, Medium
