Verdadeiras mentiras de interfaces de usuário otimistas

Três interfaces de usuário (UIs) vão para um pub. O primeiro pede uma bebida, depois vários outros. Algumas horas depois, ele pede a conta e sai do bar bêbado. A segunda UI pede uma bebida, paga adiantado, pede outra bebida, paga e assim por diante, e em algumas horas sai do bar bêbado. A terceira interface do usuário sai do pub já bêbada imediatamente após entrar - ela sabe como os pubs funcionam e é eficiente o suficiente para não perder tempo. Você já ouviu falar desse terceiro? É chamado de “IU otimista”.

Recentemente, depois de discutir a otimização do desempenho psicológico em várias conferências dedicadas ao desenvolvimento front-end e UX, fiquei surpreso ao ver quão pouco o tópico do design otimista da interface do usuário é abordado na comunidade. Francamente, o termo em si nem é bem definido. Neste artigo, descobriremos em que conceitos se baseia, veremos alguns exemplos e revisaremos seu histórico psicológico. Depois disso, revisaremos as preocupações e os principais pontos sobre como manter o controle sobre essa técnica de UX.

Leitura adicional no SmashingMag:

• O usuário é o web designer anônimo
• Projetando interfaces de usuário baseadas em cartão
• Interfaces de conversação: onde estamos hoje?
  

Mas antes de começarmos, verdade seja dita, nenhuma coisa poderia ser chamada de “IU otimista”. Em vez disso, é o modelo mental por trás da implementação de uma interface. O design de UI otimista tem sua própria história e lógica.

Era uma vez

Há muito tempo – quando a palavra “tweet” se aplicava principalmente a pássaros, a Apple estava à beira da falência e as pessoas ainda colocavam números de fax em seus cartões de visita – as interfaces web eram bastante ascéticas. E a grande maioria deles não tinha nem um pingo de otimismo. Uma interação com um botão, por exemplo, pode seguir um cenário semelhante ao seguinte:

1. O usuário clica em um botão.
2. O botão é acionado em um estado desabilitado.
3. Uma chamada é enviada para um servidor.
4. Uma resposta do servidor é enviada de volta à página.
5. A página é recarregada para refletir o status da resposta.

Isso pode parecer bastante ineficiente em 2016; no entanto, surpreendentemente, o mesmo cenário ainda é usado em muitas páginas da Web e aplicativos e ainda faz parte do processo de interação de muitos produtos. A razão é que é previsível e mais ou menos à prova de erros: o usuário sabe que a ação foi solicitada do servidor (o estado desabilitado do botão indica isso) e uma vez que o servidor responde, a página atualizada indica claramente o fim desta interação cliente-servidor-cliente. Os problemas com esse tipo de interação são bastante óbvios:

• O usuário tem que esperar. Até agora, sabemos que mesmo o menor atraso no tempo de resposta do servidor tem um efeito negativo na percepção do usuário de toda a marca, não apenas nesta página em particular.
• Toda vez que o usuário obtém uma resposta à sua ação, ela é apresentada de forma bastante destrutiva (uma nova página é carregada, em vez da existente sendo atualizada), o que quebra o contexto da tarefa do usuário e pode afetar sua linha de pensamento. Embora não estejamos necessariamente falando de multitarefa neste caso, qualquer mudança de contexto mental é desagradável. Portanto, se uma ação não é inerentemente destinada a trocar de contexto (o pagamento online é um bom exemplo de quando uma troca é natural), a troca configuraria um tom hostil de diálogo entre usuário e sistema.

Bons tempos não tão velhos

Então, a chamada Web 2.0 chegou e proporcionou novos modos de interação com as páginas da web. O núcleo deles eram XMLHttpRequest e AJAX. Esses novos modos de interação foram complementados por “spinners”: a forma mais simples de indicador de progresso, cujo único objetivo era comunicar ao usuário que o sistema está ocupado realizando alguma operação. Agora, não precisamos recarregar a página depois de obter uma resposta do servidor; poderíamos apenas atualizar uma parte da página já renderizada. Isso tornou a web muito mais dinâmica, permitindo experiências mais suaves e envolventes para os usuários. A interação típica com um botão agora pode ser assim:

1. O usuário clica em um botão.
2. O botão é acionado em um estado desabilitado e um botão giratório de algum tipo é mostrado no botão para indicar que o sistema está funcionando.
3. Uma chamada é enviada ao servidor.
4. Uma resposta do servidor é enviada de volta à página.
5. O estado visual do botão e da página são atualizados de acordo com o status da resposta.

Esse novo modelo de interação abordou um dos problemas mencionados do antigo método de interação: a atualização da página acontece sem uma ação destrutiva, mantendo o contexto para o usuário e engajando-o na interação muito melhor do que antes.

Esse tipo de padrão de interação tem sido amplamente utilizado em todos os meios digitais. Mas um problema permanece: os usuários ainda precisam aguardar uma resposta do servidor. Sim, podemos fazer nossos servidores responderem mais rápido, mas não importa o quanto tentemos acelerar a infraestrutura, os usuários ainda precisam esperar. Novamente, os usuários não gostam de esperar, para dizer o mínimo. Por exemplo, pesquisas mostram que 78% dos consumidores sentem emoções negativas como resultado de sites lentos ou não confiáveis. Além disso, de acordo com uma pesquisa realizada pela Harris Interactive para o Tealeaf, 23% dos usuários confessam xingar em seus telefones, 11% gritaram com eles e 4% realmente jogaram o telefone quando tiveram um problema com uma transação online. Os atrasos estão entre esses problemas.

Mesmo que você mostre algum tipo de indicador de progresso enquanto o usuário espera, a menos que você seja muito criativo com o indicador, hoje em dia isso simplesmente não é suficiente. Na maioria das vezes, as pessoas se acostumaram com os spinners que indicam a lentidão de um sistema. Os spinners agora estão mais associados à espera puramente passiva, quando o usuário não tem outra opção além de aguardar a resposta do servidor ou fechar a guia ou o aplicativo completamente. Então, vamos dar um passo para melhorar esse tipo de interação; vejamos este conceito de uma UI otimista.

IU otimista

Como mencionado, uma UI otimista nada mais é do que uma maneira de lidar com a interação humano-computador. Para entender as principais ideias por trás disso, continuaremos com nosso cenário de “usuário clica em um botão”. Mas o princípio será o mesmo para praticamente qualquer tipo de interação que você queira tornar otimista. De acordo com o Oxford English Dictionary:

op-ti-mis-tic , adj. esperançoso e confiante no futuro.

Vamos começar com a parte “confiante no futuro”.

O que você acha: Com que frequência seu servidor retorna um erro em alguma ação do usuário? Por exemplo, sua API falha com frequência quando os usuários clicam em um botão? Ou talvez falhe muito quando os usuários clicam em um link? Francamente, acho que não. Claro, isso pode variar com base na API, carga do servidor, nível de tratamento de erros e outros fatores que você, como desenvolvedor front-end ou especialista em UX, pode não estar disposto a se envolver. for estável e previsível e o front-end comunicar adequadamente as ações legítimas na interface do usuário, o número de erros em resposta às ações iniciadas pelo usuário será bastante baixo. Eu iria tão longe a ponto de afirmar que eles nunca deveriam ir acima de 1 a 3%. Isso significa que em 97 a 99% dos casos em que o usuário clica em um botão em um site, a resposta do servidor deve ser bem-sucedida, sem erros. Isso merece ser colocado em uma perspectiva melhor:

Pense nisso por um momento: se tivéssemos 97 a 99% de certeza sobre uma resposta de sucesso, poderíamos estar confiantes sobre o futuro dessas respostas – bem, pelo menos muito mais confiantes sobre o futuro do que o gato de Schrõdinger. Poderíamos escrever uma história totalmente nova sobre interação de botões:

1. O usuário clica em um botão.
2. O estado visual do botão é acionado instantaneamente no modo de sucesso.

É isso! Pelo menos do ponto de vista do usuário, não há nada mais do que isso - sem espera, sem olhar para um botão desabilitado e nem outro botão giratório irritante. A interação é perfeita, sem que o sistema interfira grosseiramente para lembrar o usuário sobre si mesmo.

Do ponto de vista do desenvolvedor, o ciclo completo se parece com isso:

1. O usuário clica em um botão.
2. O estado visual do botão é acionado instantaneamente no modo de sucesso.
3. A chamada é enviada para o servidor.
4. A resposta do servidor é enviada de volta para a página.
5. Em 97 a 99% dos casos, sabemos que a resposta será bem-sucedida e, portanto, não precisamos incomodar o usuário.
6. Somente no caso de uma solicitação com falha o sistema se manifestará. Não se preocupe com isso por enquanto - chegaremos a esse ponto mais adiante no artigo.

Vejamos alguns exemplos de interações otimistas. Você provavelmente está familiarizado com os botões “curtir”, encontrados no Facebook e no Twitter. Vamos dar uma olhada neste último.

Começa, obviamente, com o clique do botão. Mas observe o estado visual do botão quando o usuário não estiver mais pressionando ou passando o mouse sobre o botão. Ele muda para o estado de sucesso instantaneamente!

Vamos ver o que está acontecendo na aba “Rede” das ferramentas de desenvolvimento do nosso navegador neste exato momento.

A guia “Rede” mostra que a solicitação do servidor foi enviada, mas ainda está em andamento. O número do contador de “curtidas” ainda não foi incrementado, mas com a mudança de cor, a interface está comunicando claramente o sucesso ao usuário, mesmo antes de ter recebido uma resposta do servidor.

Depois que uma resposta bem-sucedida é recebida do servidor, o contador é atualizado, mas a transição é muito mais sutil do que a mudança instantânea de cor. Isso fornece ao usuário uma experiência suave e ininterrupta, sem nenhuma espera percebida.

Outro exemplo de interação otimista é visto no Facebook, com seu próprio botão de curtir. O cenário é bem parecido, exceto que o Facebook atualiza o contador instantaneamente, junto com a cor de sucesso do botão, sem esperar a resposta do servidor.

Uma coisa a notar aqui, no entanto. Se observarmos o tempo de resposta do servidor, veremos que é um pouco mais de 1 segundo . Considerando que o modelo RAIL recomenda 100 milissegundos como o tempo de resposta ideal para uma interação simples, isso normalmente seria muito longo. No entanto, o usuário não percebe nenhum tempo de espera nesse caso devido à natureza otimista dessa interação. Agradável! Este é outro exemplo de otimização de desempenho psicológico .

Mas vamos ser sinceros: ainda há 1 a 3% de chance de o servidor retornar um erro. Ou talvez o usuário esteja simplesmente offline. Ou, mais provavelmente, talvez o servidor retorne o que é tecnicamente uma resposta de sucesso, mas a resposta contém informações que precisam ser processadas pelo cliente. Como resultado, o usuário não receberá um indicador de falha, mas também não podemos considerar a resposta um sucesso. Para entender como lidar com esses casos, devemos entender por que e como as IUs otimistas funcionam psicologicamente em primeiro lugar.

A psicologia por trás das interfaces de usuário otimistas

Até agora, não ouvi ninguém reclamar das interações otimistas mencionadas nas principais redes sociais. Então, digamos que esses exemplos nos convenceram de que UIs otimistas funcionam. Mas por que eles funcionam para os usuários? Eles funcionam simplesmente porque as pessoas odeiam esperar. É isso, pessoal! Você pode pular para a próxima parte do artigo.

Mas se você ainda está lendo, provavelmente está interessado em saber por que é assim. Então, vamos cavar um pouco mais fundo no fundamento psicológico dessa abordagem.

Uma UI otimista tem dois ingredientes básicos que valem a pena uma análise psicológica:

• a resposta rápida à ação do usuário;
• o tratamento de possíveis falhas no servidor, na rede e em outros lugares.

Resposta rápida à ação do usuário

Quando falamos de design de UI otimista, estamos falando de um tempo de resposta ideal na interação humano-computador. E as recomendações para esse tipo de comunicação existem desde 1968. Naquela época, Robert B. Miller publicou seu artigo seminal “Response Time in Man-Computer Conversational Transactions” (PDF), no qual ele define até 17 diferentes tipos de respostas que um usuário pode obter de um computador. Um desses tipos Miller chama de “resposta à ativação do controle” – o atraso entre o pressionamento de uma tecla e o feedback visual. Mesmo em 1968, não deveria ter excedido 0,1 a 0,2 segundos. Sim, o modelo RAIL não é o primeiro a recomendar isso – o conselho existe há cerca de 50 anos. Miller observa, no entanto, que mesmo esse pequeno atraso no feedback pode ser muito lento para usuários experientes. Isso significa que, idealmente, o usuário deve receber o reconhecimento de sua ação em até 100 milissegundos . Isso está chegando ao alcance de uma das ações inconscientes mais rápidas que o corpo humano pode realizar – um piscar de olhos. Por esse motivo, o intervalo de 100 milissegundos geralmente é percebido como instantâneo. “A maioria das pessoas pisca cerca de 15 vezes por minuto e uma piscada dura em média 100 a 150 milissegundos”, diz Davina Bristow, do Instituto de Neurologia da University College London, acrescentando que isso “significa que, no geral, passamos pelo menos 9 dias por ano piscando. ”

Por causa de sua resposta visual instantânea (mesmo antes que a solicitação real seja concluída), uma interface de usuário otimista é um dos exemplos das técnicas de conclusão antecipada usadas na otimização do desempenho psicológico. Mas o fato de que as pessoas gostam de interfaces que respondem em um piscar de olhos não deve ser uma surpresa para a maioria de nós, na verdade. E também não é difícil de conseguir. Mesmo antigamente, desativávamos os botões instantaneamente após serem clicados, e isso geralmente era suficiente para reconhecer a entrada do usuário. Mas um estado desabilitado em um elemento de interface significa espera passiva: o usuário não pode fazer nada a respeito e não tem controle sobre o processo. E isso é muito frustrante para o usuário. É por isso que ignoramos completamente o estado desabilitado em uma interface de usuário otimista — comunicamos um resultado positivo em vez de fazer o usuário esperar.

Lidando com Potencial Falha

Vamos ao segundo aspecto psicológico interessante do design de UI otimista — o tratamento de possíveis falhas. Em geral, muitas informações e artigos estão disponíveis sobre como lidar com erros de interface do usuário da melhor maneira possível. No entanto, embora veremos como lidar com falhas posteriormente neste artigo, o que mais importa em uma interface de usuário otimista não é como lidamos com erros, mas quando fazemos isso.

Os seres humanos organizam naturalmente sua atividade em grupos, encerrados pela conclusão de um propósito ou subpropósito definido subjetivamente. Às vezes nos referimos a esses aglomerados como uma “linha de pensamento”, um “fluxo de pensamento” (PDF) ou simplesmente um “fluxo”. O estado de fluxo é caracterizado pelo prazer máximo, foco energético e concentração criativa. Durante um fluxo, o usuário está completamente absorvido na atividade. Um tweet de Tammy Everts ilustra bem isso:

Na web, as durações de tais aglomerados de atividade são muito mais curtas. Vamos revisitar o trabalho de Robert B. Miller por um momento. Os tipos de resposta que ele cita incluem:

• uma resposta a uma simples consulta de informações listadas;
• uma resposta a uma pergunta complexa em forma gráfica;
• uma resposta para "Sistema, você me entende?"

Ele vincula tudo isso ao mesmo intervalo de 2 segundos no qual o usuário deve obter o tipo de resposta relevante. Sem aprofundar, devemos notar que esse intervalo também depende da memória de trabalho de uma pessoa (referindo-se ao intervalo de tempo em que uma pessoa pode manter uma certa quantidade de informação em sua cabeça e, mais importante, ser capaz de manipulá-la). Para nós, como desenvolvedores e especialistas em UX, isso significa que em 2 segundos de interação com um elemento, o usuário estará em fluxo e focado na resposta que espera. Se o servidor retornar um erro durante esse intervalo, o usuário ainda estará em “diálogo” com a interface, por assim dizer. É semelhante a um diálogo entre duas pessoas, onde você diz algo e a outra pessoa discorda levemente de você. Imagine se a outra pessoa passasse muito tempo concordando com a cabeça (o equivalente à nossa indicação de um estado de sucesso na interface do usuário), mas finalmente dissesse “não” para você. Estranho, não é? Portanto, uma UI otimista deve comunicar a falha ao usuário dentro de 2 segundos do fluxo.

Armado com a psicologia de como lidar com falhas em uma interface de usuário otimista, vamos finalmente chegar aos 1 a 3% de solicitações com falha.

O lado pessimista do design de UI otimista

De longe, a observação mais comum que ouço é que o design otimista da interface do usuário é um tipo de padrão preto – trapaça, se você preferir. Ou seja, ao empregá-lo, estamos mentindo para nossos usuários sobre o resultado de sua interação. Legalmente, qualquer tribunal provavelmente apoiaria esse ponto. Ainda assim, considero a técnica uma previsão ou esperança. (Lembra-se da definição de “otimista”? Aqui é onde damos espaço para a parte “esperançosa”.) A diferença entre “mentir” e “prever” está em como você trata esses 1 a 3% de solicitações com falha. Vejamos como o botão otimista “curtir” do Twitter se comporta offline.

Primeiro, de acordo com o padrão de UI otimista, o botão muda para o estado de sucesso logo após ser clicado - novamente, sem que o usuário pressione ou passe o mouse sobre o botão, exatamente como o botão se comporta quando o usuário está online.

Mas como o usuário está offline, a solicitação falha.

Assim, o mais rápido possível dentro do fluxo do usuário, a falha deve ser comunicada. Novamente, 2 segundos é geralmente a duração de tal fluxo. O Twitter comunica isso da maneira mais sutil possível, simplesmente revertendo o estado do botão.

O leitor consciencioso aqui pode dizer que esse tratamento de falhas poderia ser levado um passo adiante, notificando o usuário de que a solicitação não pôde ser enviada ou que ocorreu um erro. Isso tornaria o sistema o mais transparente possível. Mas há um problema – ou melhor, uma série de problemas:

• Qualquer tipo de notificação que aparecesse repentinamente na tela mudaria o contexto do usuário, levando-o a analisar o motivo da falha, motivo que provavelmente seria apresentado na mensagem de erro.
• Como acontece com qualquer mensagem de erro ou notificação, esta deve orientar o usuário nesse novo contexto, fornecendo informações acionáveis.
• Essas informações acionáveis ​​definiriam ainda outro contexto.

OK, agora todos podemos concordar que isso está ficando um pouco complicado. Embora esse tratamento de erros seja razoável para, digamos, um formulário grande em um site, para uma ação tão simples quanto clicar em um botão de curtir, é um exagero - tanto em termos de desenvolvimento técnico necessário quanto na memória de trabalho dos usuários.

Então, sim, devemos estar abertos sobre falhas em uma UI otimista e devemos comunicá-la o mais rápido possível para que nosso otimismo não se torne uma mentira. Mas deve ser proporcional ao contexto. Para um like com falha, reverter sutilmente o botão ao seu estado original deve ser suficiente - isto é, a menos que o usuário esteja gostando do status de seu outro significativo, caso em que é melhor que a coisa funcione o tempo todo.

Extremo Pessimismo

Uma outra pergunta pode surgir: o que acontece se o usuário fechar a guia do navegador logo após obter um indicador de sucesso, mas antes que a resposta seja retornada do servidor? O caso mais desagradável seria se o usuário fechasse a guia antes mesmo de uma solicitação ser enviada ao servidor. Mas, a menos que o usuário seja extremamente ágil ou tenha a capacidade de diminuir o tempo, isso dificilmente é possível.

Se uma UI otimista for implementada corretamente e as interações forem aplicadas apenas aos elementos que nunca esperam mais de 2 segundos por uma resposta do servidor, o usuário terá que fechar a guia do navegador dentro dessa janela de 2 segundos. Isso não é particularmente difícil com um pressionamento de tecla; no entanto, como vimos, em 97 a 99% dos casos, a solicitação será bem-sucedida, independentemente de a guia estar ativa ou não (só que uma resposta não será retornada ao cliente).

Portanto, esse problema pode surgir apenas para aqueles 1 a 3% que recebem um erro de servidor. Então, novamente, quantos deles correm para fechar a guia em 2 segundos? A menos que eles estejam em uma competição de velocidade de fechamento de guias, não acho que o número seja significativo. Mas se você achar que isso é relevante para seu projeto em particular e pode ter consequências negativas, então empregue algumas ferramentas para analisar o comportamento do usuário; se a probabilidade de tal cenário for alta o suficiente, limite a interação otimista a elementos não críticos.

Não mencionei intencionalmente casos em que uma solicitação é atrasada artificialmente; eles geralmente não se enquadram no design de UI otimista. Além disso, passamos tempo mais do que suficiente no lado pessimista das coisas, então vamos resumir alguns pontos principais sobre a implementação de uma boa interface de usuário otimista.

Regras de ouro

Espero sinceramente que este artigo tenha ajudado você a entender alguns dos principais conceitos por trás do design otimista da interface do usuário. Talvez você seja interessante em experimentar essa abordagem em seu próximo projeto. Se sim, aqui estão algumas coisas que você deve ter em mente antes de começar:

• Um pré-requisito para tudo o que falamos até agora: certifique-se de que a API na qual você está confiando seja estável e retorne resultados previsíveis. Chega de dizer.
• A interface deve detectar possíveis erros e problemas antes que uma solicitação seja enviada ao servidor. Melhor ainda, elimine totalmente qualquer coisa que possa resultar em um erro da API. Quanto mais simples for um elemento de interface do usuário, mais simples será torná-lo otimista.
• Aplique padrões otimistas a elementos simples do tipo binário para os quais nada mais do que uma resposta de sucesso ou falha é esperada. Por exemplo, se um clique de botão assumir uma resposta do servidor como “sim”, “não” ou “talvez” (todos os quais podem representar sucesso em graus variados), esse botão seria melhor sem um padrão otimista.
• Conheça os tempos de resposta da sua API. Isso é crucial. Se você sabe que o tempo de resposta para uma solicitação específica nunca fica abaixo de 2 segundos, provavelmente é melhor espalhar um pouco de otimismo sobre sua API primeiro. Conforme mencionado, uma UI otimista funciona melhor para tempos de resposta do servidor inferiores a 2 segundos. Ir além disso pode levar a resultados inesperados e muitos usuários frustrados. Considere-se avisado.
• Uma interface de usuário otimista não é apenas sobre cliques de botão. A abordagem pode ser aplicada a diferentes interações e eventos durante o ciclo de vida de uma página, incluindo o carregamento da página. Por exemplo, as telas de esqueleto seguem a mesma ideia: você prevê que o servidor responderá com sucesso para preencher os espaços reservados para mostrar ao usuário o mais rápido possível.

O design de UI otimista não é realmente uma novidade na web, nem é uma técnica particularmente avançada, como vimos. É apenas outra abordagem, outro modelo mental, para ajudá-lo a gerenciar o desempenho percebido de seu produto. Baseando-se nos aspectos psicológicos da interação humano-computador, o design otimista da interface do usuário, quando usado de forma inteligente, pode ajudá-lo a criar experiências melhores e mais perfeitas na Web, exigindo muito pouco para implementar. Mas, para tornar o padrão realmente eficaz e evitar que nossos produtos mintam para os usuários, devemos entender a mecânica do design de UI otimista.

Recursos

• “Tempo de Resposta em Transações Conversacionais Homem-Computador” (PDF), Robert B. Miller, Conferência Conjunta de Computadores de Outono, 1968
• “Introducing RAIL: A User-Centric Model for Performance”, Paul Irish, Paul Lewis, Smashing Magazine, 2015
• “Mobile Web Stress: The Impact of Network Speed ​​on Emotional Engagement and Brand Perception,” Tammy Everts, Radware Blog, 2013
• Aplicações do Fluxo no Desenvolvimento Humano e Educação , Mihaly Csikszentmihalyi, 2014
• “Detalhes do design móvel: Evite o Spinner”, Luke Wroblewski, 2013
• “Por que o desempenho é importante, parte 2: gerenciamento de percepção”, Denys Mishunov, Smashing Magazine, 2015