Um usuário perdeu um item importante e abriu um ticket de suporte técnico. Outro ficou preso na penetração e desistiu. Um terceiro nunca usou o recurso que deixou sua equipe entusiasmada.
Quando isso acontece, muitas vezes o instinto é culpar o usuário, dando mais destaque ao recurso ou adicionando mais instruções para explicar como usá-lo.
O artigo continua abaixo
Os usuários reais estão ocupados e distraídos. Eles trocam de guia, respondem mensagens, participam de reuniões e tentam realizar o trabalho em intervalos curtos. Eles contam com atalhos, padrões familiares e julgamentos rápidos.
Eles não leem cada palavra, não se lembram de cada instrução ou avaliam com calma cada opção. A maioria de nós não, na maioria das vezes. Os melhores produtos e marketing se baseiam nessa realidade e são construídos em torno dela.
No entanto, as equipes de produto continuam a projetar para um usuário idealizado: alguém que entende a categoria, fala o vocabulário da equipe e tem paciência para explorar. Essa mentalidade incentiva as equipes a confiar na experiência interna, no feedback de usuários avançados ou no ritmo dos concorrentes.
A diferença entre projetar para usuários idealizados e projetar para usuários reais se manifesta de maneiras previsíveis: baixa adoção, esforços repetidos, fadiga de recursos e aumento do esforço necessário antes que o produto agregue valor.
Você pode citar um recurso que continua sendo promovido em um aplicativo que a maioria das pessoas usa e aprendeu a ignorar.
Tendências ocultas por trás de decisões “óbvias” de produtos
A razão pela qual isso acontece não é devido à falta de cuidado ou esforço do cliente. É preconceito. O preconceito pode aumentar silenciosamente nas equipes de produto, design e engenharia ao longo do tempo. Depois de saber como um produto funciona, é difícil lembrar como é não saber. Essa é a maldição do conhecimento.
Na prática, é combinado com excesso de confiança, falso consenso e viés de confirmação. Acreditamos que os usuários entenderão o que entendemos. Tratamos os sinais confusos como uma validação do nosso plano já preferido. Indexamos excessivamente o grupo mais vocal, que geralmente é o dos usuários mais poderosos.
Também decidimos o que é fácil de medir, mesmo que não seja a melhor proxy de valor. Com o tempo, esses pequenos erros resultam em uma UX que é inconsistente para quem está dentro da empresa e muito complexa para todos os demais.
As jornadas de integração de SaaS geralmente ilustram esse problema com clareza. A equipe que vive e respira seu produto geralmente começa a entrar na configuração.
A primeira tela solicita que um novo usuário configure pipelines, escolha gatilhos de automação, defina campos e selecione opções que nunca viu antes. Internamente, faz sentido para nós: precisamos desses dados para fazer o produto funcionar. Na realidade, um novo usuário ainda está tentando responder a perguntas básicas:
O que essa ferramenta faz por mim? Como isso tornará meu dia mais fácil? Qual é a maneira mais rápida de obter a vitória? Quando a primeira experiência é uma linguagem desconhecida e uma longa lista de decisões, muitos usuários param. Alguns abandonam. A equipe projetou sua experiência em um usuário pela primeira vez.
Design baseado em como as pessoas realmente pensam e agem
A psicologia cognitiva e a pesquisa comportamental explicam o porquê. A atenção é limitada. A memória de trabalho é pequena. As pessoas evitam o esforço quando a recompensa não é óbvia. A tomada de decisão diária é emocional e intuitiva, não analítica e deliberada.
O enquadramento do Sistema 1 e do Sistema 2 de Daniel Kahneman é útil aqui. O sistema 1 é rápido e automático. O Sistema 2 é lento e trabalhoso. Para começar, quando um usuário é forçado a pensar no Sistema 2, o produto já está criando atrito.
Um bom produto não elimina totalmente o esforço, mas minimiza o esforço desnecessário e torna o próximo passo óbvio.
Então, como é na prática “projetar para a realidade”?
O primeiro momento de valor começa a ficar visível e rápido. Em vez de liderar com configuração, lidere o produto com uma pequena vitória que prove que vale a pena o tempo do usuário. Em seguida, oriente os usuários para configurações mais profundas quando acharem que o esforço valerá a pena. Isso significa preferir o reconhecimento à lembrança.
Não lembre aos usuários termos internos ou opções de decodificação que só fazem sentido dentro da empresa. Use linguagem familiar, fluxos de trabalho, ícones, exemplos e padrões que reduzam a carga de decisões.
Se as opções avançadas forem importantes, apresente-as mais tarde, quando o usuário tiver contexto. Você não precisa tirar o poder ou simplificar demais o produto. Sequencie e exponha progressivamente a complexidade à medida que os usuários se tornam mais proficientes.
Projetar para a realidade também significa projetar para a disrupção. Os usuários serão redirecionados. Eles estarão de volta mais tarde. Pode ser necessário recomeçar em um dispositivo diferente. Um fluxo que “pausa” ou perde o progresso interromperá silenciosamente a conversão e o uso. Um fluxo que salve a situação, deixe claro os próximos passos e ajude os usuários na recuperação criará confiança e adoção.
Para controlar o preconceito, as equipes precisam de métodos que revelem o comportamento real, não apenas opiniões. Veja usuários tentando realizar tarefas importantes. Peça-lhes que pensem em voz alta enquanto avançam. Use dados comportamentais para ver onde as pessoas desistem e quanto tempo levam para alcançar valor. Conduza experimentos focados que respondam a uma pergunta específica.
Não use testes A/B como uma máquina caça-níqueis para buscar lucros. Use-o como uma ferramenta de aprendizagem. Ao perguntar diretamente aos usuários, trate suas respostas como insights sobre problemas, não como soluções perfeitas. A citação frequentemente atribuída a Henry Ford capta esta ideia: “Se eu tivesse perguntado aos meus clientes o que eles queriam, eles teriam dito um cavalo mais rápido”.
O truque é olhar além do que os clientes dizem em pesquisas e entrevistas e focar no que eles fazem para entender o problema real que estão tentando resolver.
Quando o progresso parar, volte ao problema do usuário
Quando as equipes de produto ficam presas, muitas vezes é um sinal de que é hora de voltar ao problema do usuário, e não apenas continuar iterando na solução atual. A mudança é parar de tentar convencer os usuários e começar a ficar curioso sobre o que realmente os impede.
Quando as equipes observam o comportamento real, testam hipóteses e buscam razões, elas abrem a porta para um trabalho melhor. Eles aprendem o que é realmente confuso, o que é muito difícil, o que os usuários estão tentando alcançar e o que há de “bom” no mundo do usuário.
Isso ajuda a evitar armadilhas comuns, como o viés do status quo, em que as equipes continuam a fazer o que sabem porque a mudança é desconfortável.
Lutar contra o comportamento humano é como lutar contra a gravidade. Você só pode fazer isso por um certo tempo. Nunca seremos completamente objetivos, mas podemos ser muito melhores no reconhecimento dos nossos pressupostos e na utilização de processos simples para os desafiar.
Não existem atalhos.
Produtos melhores vêm do respeito aos humanos em ambos os lados: o usuário ocupado tentando realizar o trabalho e a equipe de construção ocupada. A tarefa é preencher essa lacuna com evidências, clareza e repetição. Quando você projeta para pessoas reais, isso deixa de ser algo que impulsiona a adoção. O produto se torna algo que vence.
Apresentamos o melhor software de plano de negócios.
Este artigo foi produzido como parte do canal Expert Insights da TechRadarPro, onde apresentamos as melhores e mais brilhantes mentes da indústria de tecnologia atualmente. As opiniões expressas aqui são de responsabilidade do autor e não necessariamente da TechRadarPro ou Future plc. Caso tenha interesse em participar, mais informações aqui:
