Ebook Salll · Nº 26 · Experiência de compra
Quando a espera vira dúvida.
Depois do clique, a interface precisa reconhecer a intenção, explicar a espera e confirmar apenas o que o servidor confirmou.
Ebook Salll · Nº 26 · Experiência de compra
Depois do clique, a interface precisa reconhecer a intenção, explicar a espera e confirmar apenas o que o servidor confirmou.
O elevador pode estar vindo. O botão pode ter registrado o toque. Mas, sem luz, som ou mudança de estado, a única informação disponível é o silêncio. A mão volta. O segundo clique não nasce necessariamente de impaciência. Nasce da dúvida sobre o primeiro.
Em uma compra, essa dúvida fica cara. A busca parece quebrada. A variante troca de cor, mas conserva o preço anterior. O frete gira sem dizer o que consulta. O carrinho sobe para dois itens. O pagamento fica mudo no único momento em que repetir a ação pode duplicar uma cobrança.
O relatório de Walter Doherty e Ahrvind Thadhani, publicado pela IBM em 1982, reuniu observações e estudos sobre terminais profissionais. A tese era forte: quando pessoa e computador não ficam esperando um pelo outro, a produtividade pode crescer mais do que a redução isolada do tempo da máquina sugeriria.
O relatório apresenta condições de 0,25 s, 0,30 s e 0,84 s e defende respostas abaixo de um segundo. Não executa um experimento que compare 399 ms a 401 ms, nem declara 400 ms como fronteira humana universal.
Havia 75 sessões de 15 engenheiros, cinco profissionais num pequeno teste e observação de 390 usuários do NIH, além de casos com amostra não reportada.
A evidência histórica sustenta perseguir resposta rápida. A revisão moderna mostra que percepção, preferência e desempenho variam por tarefa, modalidade e expectativa.
Miller, em 1968, propôs tempos diferentes para 17 situações conversacionais. Não eram resultados de um experimento sistemático, mas estimativas informadas. A revisão de Attig e colegas mostra por que o contexto vence o slogan: toque, arraste, escrita, consulta e tarefa complexa têm sensibilidades diferentes.
O Interaction to Next Paint, INP, mede do início de um clique, toque ou tecla até o próximo frame apresentado. A meta de até 200 ms no percentil 75 é útil para o primeiro relógio: o momento em que a página reconhece a intenção. Ela não mede o fim de um XHR nem a confirmação de frete, estoque ou pagamento.
“O sistema recebeu minha ação?” Mede o paint do estado pressionado, do texto de espera ou de outro retorno visual. INP ajuda aqui.
“O resultado verdadeiro já voltou?” Mede rede, processamento, sucesso, erro, timeout e reconciliação com o servidor.
Num experimento do Google Search, injetar de 100 a 400 ms causou entre 0,2% e 0,6% menos buscas por usuário. É evidência causal de que pequenas diferenças podem importar em busca. O desfecho não era compra, e o estudo não publicou o tamanho amostral. A magnitude não deve virar benchmark de checkout.
“Recebi”, “estou processando”, “confirmei” e “não sei se terminou” são mensagens diferentes. Colapsá-las é a origem de muito duplo clique, duplicidade e falsa confirmação.
O clique entrou. O controle mudou no próximo frame. Nenhuma promessa sobre o resultado ainda.
Há trabalho em andamento. O texto nomeia a operação e preserva contexto.
O servidor devolveu o estado final. Preço, estoque, pedido ou pagamento estão conciliados.
Falha confirmada e resultado desconhecido pedem instruções diferentes.
Um timeout depois de enviar um pagamento não prova que a cobrança falhou. Pode significar apenas que a resposta não chegou. A tela precisa consultar o status antes de oferecer uma nova tentativa. Em outro extremo, “sem estoque” não pode ser o fallback de um erro de captura ou validação.
Indicadores de progresso ajudam quando transformam incerteza em informação. No estudo de Myers com 48 voluntários, versões com indicador foram avaliadas melhor e 86,1% disseram preferi-lo. Isso não prova redução de abandono. Mostra preferência num sistema da década de 1980.
Serve para escopo curto e localizado. Em espera longa, precisa de contexto, etapa ou saída segura.
Ajuda a reservar layout e antecipar forma. Não deve redesenhar a página quando o conteúdo chega.
Mostre percentual somente quando o backend consegue estimá-lo. Um número falso troca dúvida por decepção.
“Consultando CEP” e “Buscando transportadoras” funcionam se correspondem ao processamento real.
Skeletons não venceram de modo confiável. Um estudo acadêmico com 14 pessoas encontrou médias favoráveis ao skeleton, mas nenhuma diferença significativa. Um teste aplicado com 136 participantes encontrou pior avaliação para skeleton que para spinner e tela vazia. Os métodos são limitados e os resultados apontam em direções diferentes.
Lee, Chen e Hess testaram 1.025 pessoas e mostraram que informação temporal e distração reduzem espera percebida por caminhos diferentes. Informação reduz incerteza. Distração muda a atenção. Nenhum dos dois caminhos autoriza estimativa falsa.
Optimistic UI mostra temporariamente o estado que a pessoa tentou criar enquanto a ação acontece. A documentação do React ensina o padrão, o estado pendente e o rollback. Ela não demonstra aumento de confiança ou conversão.
A proteção também precisa existir no backend. A RFC 9110 alerta que requisições não idempotentes não devem ser repetidas automaticamente sem garantia adicional. APIs de pagamento usam chaves de idempotência para reconhecer a mesma intenção e devolver o mesmo resultado. Desabilitar o botão no navegador não resolve retry de rede, duas abas ou reenvio do cliente.
No experimento de compra simulada de Dabholkar e Sheng, 252 pessoas esperaram 3 s ou 30 s em diferentes etapas de uma reserva de viagem. Espera percebida previu melhor a intenção declarada de abandonar que o tempo objetivo. Atrasos mais cedo pareceram mais longos. O estudo não observou abandono real e usou atrasos extremos, mas reforça a necessidade de medir cada etapa, não apenas a média do site.
Num estudo de busca com 40 participantes, mais cliques e consultas apareceram tanto em engajamento quanto em frustração. Telemetria de “rage click” é útil para localizar episódios, não para nomear sozinha a emoção.
O controle reconheceu o primeiro toque antes da repetição?
O segundo clique criou outra requisição ou foi absorvido pela mesma intenção?
Houve sucesso, erro, reconciliação ou abandono durante estado pendente?
Confirmação também afeta confiança. Reynolds-McIlnay e Morrin encontraram, em quatro experimentos com interfaces de varejo simuladas, benefícios da confirmação auditiva em condições específicas. Isso não transforma som em padrão obrigatório. O áudio pode ser intrusivo e não atende quem não o ouve. Ele é reforço, nunca substituto do estado visível e programático.
A WCAG 2.2, no critério 4.1.3 Status Messages, nível AA, exige que mensagens sobre resultado, espera, progresso e erro possam ser determinadas programaticamente sem receber foco. “Buscando”, “18 resultados” e “Nenhum resultado” são exemplos do próprio material da W3C.
Use `role="status"` ou live region adequada. Informe fase, conclusão e erro. Não anuncie cada frame nem cada ponto percentual.
`prefers-reduced-motion` remove pulsação e deslocamento não essenciais. O conteúdo estático continua explicando a espera.
Mantenha o foco no controle acionado quando a atualização não muda o contexto. Erro e resultado continuam localizáveis.
O critério 3.3.4 protege submissões financeiras com reversão, verificação ou confirmação antes do estado definitivo.
Meça INP e confirme que pressionado, pendente ou texto de status são pintados antes de trabalho pesado.
Nenhum badge, total ou mensagem de sucesso pode antecipar a confirmação do servidor.
Timeout de pagamento e falha de conexão precisam consultar status antes de oferecer nova tentativa.
Percentual representa progresso real. Etapa nomeada corresponde ao backend. Skeleton preserva a estrutura final.
Use idempotência e deduplicação no servidor. Botão desabilitado é só uma camada do controle.
“Não encontrado”, “fora de estoque” e “erro de captura” nunca compartilham o mesmo estado.
Status sem roubar foco, progresso nomeado e movimento reduzido preservam acesso à mesma informação.
Cruze feedback pintado, request, repetição, reconciliação, resultado e saída por etapa.
Uma interface confiável não promete que tudo será instantâneo. Ela reconhece a intenção rápido, reduz o tempo real, explica o que acontece e reserva a palavra “concluído” para quando a verdade voltou.
É assim que o primeiro clique deixa de pedir um segundo.
Nota de transparência: resultados de busca, sistemas profissionais e laboratórios explicam mecanismos dentro de seus métodos. Aplicações em comércio eletrônico são identificadas como recomendações ou hipóteses quando não há experimento direto. Nenhuma correlação foi apresentada como causalidade.