Todo time de produto já viu este ticket. Um cliente escreve dizendo que clicou em Salvar e nada aconteceu. Um engenheiro confere os logs. Salvou. O registro está lá, correto, com data e hora, exatamente como deveria. Nada está quebrado, e o ticket continua totalmente válido.
Na mesma semana chega um ticket diferente. Um cliente pergunta se existe algum jeito de editar vários registros de uma vez. Existe. O controle está na barra de ferramentas há dois anos, a poucos centímetros de onde essa pessoa trabalha todos os dias.
Os dois casos são falhas de adoção, e chegam aos seus relatórios com a mesma cara: uma funcionalidade com uso decepcionante. Mas eles são opostos. O segundo usuário não encontrou a porta. O primeiro passou por ela e não conseguiu saber se tinha chegado. Se você tratar os dois do mesmo jeito, um deles recebe uma solução que piora a experiência dele.
O cientista cognitivo e designer Donald Norman deu a essas duas falhas nomes que vale a pena tomar emprestado, porque ter duas palavras em vez de uma muda o que você constrói. Ele as chamou de golfo de execução e golfo de avaliação. Um fica antes da ação, o outro fica depois dela, e a interface é a única coisa capaz de atravessar qualquer um dos dois.
Este guia mostra o que os dois golfos significam, como os sete estágios da ação se traduzem nas perguntas que os seus usuários realmente fazem, por que o momento da ação é uma linha divisória que o seu funil não enxerga, cinco sinais de cada golfo em dados que você já tem, seis soluções para cada lado, o que medir e qual metade do trabalho cabe à orientação dentro do produto e qual metade cabe ao próprio produto.
Principais conclusões
- O golfo de execução é a distância entre o que o usuário quer alcançar e as ações que a sua interface deixa visíveis e compreensíveis. É a distância antes do clique.
- O golfo de avaliação é a distância entre o que o seu produto realmente fez e o que o usuário consegue entender pela tela. É a distância depois do clique.
- Eles deixam rastros opostos. Um golfo de execução deixa um evento faltando. Um golfo de avaliação deixa eventos a mais: repetições, reversões, recarregamentos, um ticket que começa com as palavras deu certo?.
- O seu funil conta a ação, então registra um golfo de avaliação como sucesso. É por isso que o segundo tipo de distância passa anos sem correção enquanto os times continuam adicionando mais orientação ao primeiro.
- A orientação fecha o golfo de execução: um tooltip no controle, um hotspot naquilo que ninguém abre, um tour disparado na página onde a tarefa começa, um checklist que continua disponível. O feedback fecha o golfo de avaliação: uma mudança de estado visível, uma mensagem de sucesso que nomeia o que mudou, um próximo passo claro.
- Adicionar orientação a um golfo de avaliação piora o problema. O usuário nunca esteve perdido. Dizer de novo o que ele deve fazer, quando a pergunta dele é o que aconteceu, só adiciona ruído a um momento que já é incerto.
O que são o golfo de execução e o golfo de avaliação? (significado e definição)
Golfo de execução: definição
O golfo de execução é a distância entre o objetivo que o usuário tem em mente e as ações que a interface oferece para chegar lá. Ele é largo quando o usuário não consegue saber o que é possível, não sabe qual controle faz o que ele quer ou não consegue operar esse controle corretamente depois de encontrá-lo. Tudo nele acontece antes de a ação ser executada.
Golfo de avaliação: definição
O golfo de avaliação é a distância entre o novo estado do sistema e o que o usuário consegue perceber, interpretar e comparar com o objetivo original. Ele é largo quando o produto mudou alguma coisa e a tela não diz isso, diz de um jeito que o usuário não entende ou diz num lugar para onde o usuário não está olhando. Tudo nele acontece depois de a ação ser executada.
Os dois termos vêm de Donald Norman, cujo argumento mais amplo era que a maior parte do que chamamos de erro do usuário é, na verdade, uma propriedade do design: ou a interface faz a ponte sobre essas duas distâncias, ou não faz, e culpar a pessoa que está do lado errado de um golfo não explica nada. Os nomes foram cunhados tanto para objetos físicos quanto para software, e é por isso que funcionam tão bem num produto SaaS, onde nada é físico e cada pista que o usuário recebe precisa ter sido colocada ali de propósito por alguém.
O jeito útil de guardar a ideia é este: a sua interface precisa falar duas vezes sobre cada funcionalidade que tem. Antes da ação, ela precisa dizer: isto existe, se aplica a você, fica aqui e vai fazer isto. Depois da ação, ela precisa dizer: deu certo, isto mudou, o resultado foi para cá e agora você pode fazer isto. A maioria dos produtos é razoavelmente boa na primeira frase e surpreendentemente ruim na segunda, porque a primeira frase é o assunto das revisões de design e dos projetos de onboarding, enquanto a segunda é considerada óbvia por quem construiu a funcionalidade.
Essas duas frases têm nomes próprios na literatura de design. Feedforward é a informação que ajuda o usuário a prever o que uma ação vai fazer antes de se comprometer com ela. Feedback é a informação que diz a ele o que de fato aconteceu. Uma caixa de confirmação que explica o que está prestes a ser excluído é feedforward. Um toast que nomeia o que foi excluído e oferece desfazer é feedback. Um produto pode ter muito de um e quase nada do outro, e os sintomas não vão se parecer em nada.
A frase que vale escrever no quadro branco: um usuário que não age tem um problema de execução, e um usuário que age e depois age de novo tem um problema de avaliação. O primeiro é uma lacuna no que o seu produto diz a ele. O segundo é uma lacuna no que o seu produto responde a ele.
Vale ser preciso sobre o que esses golfos não são. Eles não são a mesma coisa que dificuldade. Uma tarefa realmente complicada pode ter um golfo de execução estreito, porque a interface é honesta e legível em cada etapa, e uma tarefa trivial pode ter um golfo enorme, porque o único controle que a executa está escondido atrás de um ícone que ninguém reconhece. Eles também não são a mesma coisa que fricção, que diz respeito ao esforço que um caminho exige quando você já está nele. Os golfos dizem respeito a se o caminho é visível, para começo de conversa, e se você consegue saber que chegou ao fim dele.
Os sete estágios da ação, traduzidos para times de produto
Os dois golfos fazem parte de um modelo mais longo sobre como uma pessoa faz qualquer coisa. Norman descreveu sete estágios, e eles são mais úteis para um time de produto do que parecem à primeira vista, porque cada estágio falha de um jeito diferente e cada falha tem uma solução diferente. Leia os sete como as sete perguntas que um usuário faz a si mesmo durante uma tentativa de realizar uma tarefa.
O objetivo se forma na cabeça do usuário. Tudo entre o objetivo e a ação é o golfo de execução, e tudo entre a ação e o veredito é o golfo de avaliação.
| Estágio | O que o usuário está perguntando | Como é quando ele falha | Golfo |
|---|---|---|---|
| 1. Objetivo | O que eu quero de verdade aqui? | O usuário ainda não tem objetivo. Está só explorando, ou alguém mandou que ele fizesse login. | Nenhum |
| 2. Planejar | Isso é mesmo possível neste produto? | Ele supõe que não, então nem procura. Em vez disso, monta uma gambiarra numa planilha. | Execução |
| 3. Especificar | Qual controle faz isso? | Ele sabe que existe, vasculha três menus e depois pesquisa na sua central de ajuda. | Execução |
| 4. Executar | Consigo operar isso corretamente? | Ele preenche o formulário errado, escolhe a opção errada, desiste no terceiro campo. | Execução |
| 5. Perceber | Alguma coisa mudou? | A tela parece idêntica. Talvez tenha aparecido um spinner. Ele aperta o botão de novo. | Avaliação |
| 6. Interpretar | O que isso significa? | Algo mudou e ele não consegue decifrar. Um status virou Pendente e ninguém disse por quanto tempo. | Avaliação |
| 7. Comparar | Era isso que eu queria? | Ele não consegue ligar o resultado ao objetivo, então não sabe se segue em frente ou se começa de novo. | Avaliação |
Duas coisas saltam aos olhos quando você tem essa tabela na frente. A primeira é que seis dos sete estágios podem falhar por causa de algo que a sua interface disse ou deixou de dizer, e só o primeiro está realmente fora do seu controle. A segunda é que quase toda configuração de analytics de produto que existe instrumenta o estágio quatro e nada mais. Você sabe quantas pessoas clicaram no botão. Não faz ideia de quantas delas conseguiram saber o que o botão fez.
Os estágios também explicam um padrão que os times de suporte reconhecem na hora: a mesma funcionalidade gerando dois tipos completamente diferentes de ticket. Como eu exporto isso é uma falha do estágio três. Minha exportação funcionou é uma falha do estágio cinco. Os dois são sobre a mesma funcionalidade, chegam na mesma fila e pedem respostas opostas. Se o seu time trata os dois escrevendo um artigo de ajuda melhor, só um deles melhora.
A ação é a linha divisória, e o seu funil não consegue enxergá-la
Aqui está a parte que muda o seu jeito de trabalhar. Os dois golfos causam baixo uso de funcionalidades, baixa ativação e volume de suporte, mas deixam impressões digitais completamente diferentes nos seus dados de eventos, e só uma dessas impressões é do tipo que um relatório de funil foi feito para notar.
Um golfo de execução produz um evento que falta, e todo relatório de funil foi feito para mostrar isso. Um golfo de avaliação produz eventos duplicados e um recarregamento, que o seu funil lê como uma etapa concluída.
Um golfo de execução subtrai. O evento que importa nunca dispara, a etapa nunca é alcançada, o funil de onboarding mostra um precipício num ponto específico, e alguém abre um ticket no seu time de produto perguntando por que ninguém usa o editor em massa. É um problema visível, bem compreendido e bem servido de ferramentas. Existe uma indústria inteira de dashboards para ele.
Um golfo de avaliação soma. O evento dispara, depois dispara de novo, às vezes uma terceira vez. Há um recarregamento de página no meio. Pode haver um desfazer, a exclusão da duplicata que a repetição criou ou uma visita à sua central de ajuda trinta segundos depois de uma ação bem-sucedida. Depois o usuário pergunta a um colega ou escreve para o suporte para saber se deu certo. No seu funil, esse usuário converteu. Na revisão semanal, essa funcionalidade está indo bem.
A armadilha: como os golfos de avaliação são registrados como sucessos, o único lugar onde eles aparecem é no volume de suporte e no feedback qualitativo, que são justamente os dois sinais que os times de produto descartam como anedóticos. Uma funcionalidade pode ter uma taxa de conclusão de noventa por cento e ainda assim gerar toda semana um fluxo constante de mensagens do tipo isso deu certo mesmo?, e nada nos seus relatórios vai ligar uma coisa à outra.
Existe mais uma bifurcação que vale nomear, para que você faça o diagnóstico dentro do golfo certo e não misture os dois. Um golfo de execução tem duas variantes próprias: o usuário nunca abriu o controle, o que é um problema de descoberta, ou o usuário abriu e saiu na mesma hora, o que costuma significar que a palavra no controle queria dizer outra coisa para ele do que quer dizer para você. O nosso guia sobre modelos mentais em UX cobre esse segundo caso por completo, inclusive por que deixar mais destacado um controle mal compreendido aumenta as saídas em vez do uso. Use este guia para descobrir de que lado da ação está o seu problema, e aquele para descobrir por que o lado de antes da ação está falhando.
Cinco sinais de um golfo de execução
Nenhum destes exige um programa de pesquisa. Todos aparecem em dados que você já coleta, ou nas frases que os seus clientes já mandam para você.
Uma funcionalidade lançada há um ano e usada por uma fração minúscula das contas, sem nenhum padrão por plano ou por função. Se ela fosse mal projetada, quem precisa dela usaria e reclamaria. Silêncio somado a baixo alcance costuma significar que ninguém sabe que ela existe. Veja o nosso guia sobre descoberta de funcionalidades.
Os usuários chegam ao resultado, mas em cinco passos quando bastariam dois. Exportam para uma planilha para fazer algo que os seus filtros já fazem. Criam registros um por um ao lado de uma importação em massa. O objetivo está ao alcance, o caminho mais curto não está.
Uma tela com muitas entradas e uma sessão mediana de quatro segundos. Eles encontraram a porta, abriram e não conseguiram saber o que fazer lá dentro. Os estados vazios costumam ser os culpados, e o nosso guia sobre estados vazios trata disso.
Conte esses tickets separadamente de todo o resto da sua fila durante um mês. Uma fila dominada por como eu faço é uma fila dizendo que a sua interface não está respondendo aos estágios dois e três, e é para resolver isso que existe o suporte dentro do produto.
O relatório de golfo de execução mais barato que você pode montar. Cada busca sem resultado é um usuário dizendo, com as próprias palavras, o que queria e não encontrou, e as palavras que ele usou são as que a sua interface deveria estar usando.
Cinco sinais de um golfo de avaliação
Estes são mais difíceis de ver, porque nenhum deles parece uma falha. Cada um é um usuário que fez exatamente o que você queria e depois não conseguiu saber que tinha feito.
Dois eventos de Salvar, dois convites para o mesmo endereço, duas tentativas de pagamento, duas exportações do mesmo relatório. É o sinal de avaliação mais valioso que existe, e quase ninguém tem um alerta para ele. Se duplicatas causam um dano real no seu produto, isso não é um detalhe de UX.
Uma configuração ligada e desligada em menos de dez segundos. Um registro criado e excluído. Uma mudança salva e revertida. O usuário não está experimentando por diversão, está sondando a interface para descobrir o que a ação dele fez, porque a tela não quis contar.
Recarregar uma página é o gesto humano universal para eu não acredito nesta tela. Quando ele se concentra logo depois de uma ação específica, essa ação tem um problema de feedback, não de desempenho. O nosso guia sobre estados de carregamento cobre os casos em que é de fato uma questão de velocidade.
Será que salvou, será que enviou, será que chegou para eles, será que já está no ar. Marque esses tickets separadamente dos de como eu faço. Eles mostram quais ações do seu produto terminam em silêncio, e cada uma delas é uma correção de cinco minutos no texto, não um item de roadmap.
Importações, sincronizações, envios agendados, qualquer coisa assíncrona. O produto fez exatamente o que prometeu, vinte minutos depois, numa tela que o usuário já tinha deixado. Para o usuário, simplesmente nada aconteceu.
Dois desses cinco custam dinheiro diretamente, e não só boa vontade. Ações duplicadas criam dados que o seu cliente depois precisa limpar, o que vira uma conversa com o suporte com um custo por hora bem real, e reversões numa ação paga podem parecer uma contestação de cobrança. Os outros três custam confiança, o que aparece mais tarde e é mais difícil de rastrear. O nosso guia sobre confiança do usuário explica por que um resultado sem explicação causa mais estrago do que um erro visível.
Como fechar o golfo de execução
Tudo deste lado da linha tem a ver com tornar uma funcionalidade visível, legível e alcançável no momento em que o objetivo se forma. São seis movimentos, ordenados pelo quanto custam em relação ao que tiram da sua fila de suporte.
1. Dê ao controle o nome que o usuário dá ao objetivo
Antes de explicar qualquer coisa, confira a palavra. Se os seus usuários dizem enviar a fatura e o seu botão diz Gerar documento, você criou uma falha de estágio três do nada, e nenhuma quantidade de orientação compensa isso por completo. Tire o vocabulário das suas buscas sem resultado e dos seus tickets de suporte, não do seu modelo de dados.
O que isso elimina: a caça. O usuário reconhece o controle em vez de deduzi-lo.
2. Coloque a resposta no elemento, não num documento
Uma pergunta que se responde em uma frase deve ser respondida onde surge. Um tooltip preso ao campo que confunde as pessoas não custa nada para ler e mantém o usuário dentro da tarefa. Mandá-lo para um artigo da central de ajuda custa uma troca de contexto e, em geral, uma viagem de volta. O nosso guia sobre ajuda contextual mostra como decidir qual pergunta merece qual superfície.
O que isso elimina: a saída do produto para responder a uma pergunta de dez segundos.
3. Sinalize aquilo que ninguém abre
Para uma funcionalidade com alcance quase zero, a intervenção mais barata é um pequeno marcador persistente no próprio controle, exibido só para o segmento ao qual ela se aplica e dispensado assim que a pessoa interage. Um hotspot é um padrão de puxar, e não de empurrar, então ele espera a curiosidade em vez de interromper o trabalho, e é isso que o torna tolerável numa tela que as pessoas usam todos os dias.
O que isso elimina: a invisibilidade de tudo que não está no caminho habitual do usuário.
4. Dispare o walkthrough onde a tarefa começa, não onde a conta começa
Uma tarefa de várias etapas merece uma sequência guiada, mas o gatilho importa mais do que o conteúdo. Um tour que roda uma vez no cadastro atende a um estado que o usuário deixa para trás em dias. Um tour disparado na página onde a tarefa realmente começa atende o usuário por anos, inclusive na terceira vez em que ele faz uma tarefa trimestral. O nosso guia sobre gatilhos de onboarding mostra como escolher entre condições de página, de evento e de segmento.
O que isso elimina: a orientação que só existiu durante a primeira semana.
5. Dê a cada fluxo uma segunda porta
Os usuários pulam coisas, e têm razão: o paradoxo do usuário ativo explica por que quase todo mundo mergulha direto em vez de ler primeiro. O que importa é que pular não seja permanente. Um checklist que continua disponível, em que um item pode abrir a página certa, redirecionar ou iniciar o tour, transforma um fluxo dispensado em algo a que o usuário pode voltar quando tiver um motivo.
O que isso elimina: a decisão sem volta que o usuário tomou nos primeiros cinco minutos.
6. Mostre o que a ação vai fazer antes de o usuário se comprometer
Isso é feedforward, e é a forma mais barata de reduzir ansiedade em software. Uma prévia do número de registros afetados, uma amostra da mensagem que vai sair, uma frase simples dizendo o que acontece em seguida. Mais do que evitar erros, isso faz as pessoas toparem apertar o botão, que é o verdadeiro bloqueio em qualquer coisa irreversível. O nosso guia de microcopy de UX traz as fórmulas.
O que isso elimina: a hesitação que impede o usuário de agir sobre um controle que ele encontrou.
O lado da execução é uma camada que você pode adicionar a uma interface que não vai mudar: um marcador no controle, uma frase no campo, uma sequência na página onde a tarefa começa e uma lista que continua ao alcance.
Como fechar o golfo de avaliação
Tudo deste lado da linha tem a ver com responder a uma pergunta que o usuário já tem: o que acabou de acontecer. Essas soluções costumam ser menores do que as de execução e quase sempre são negligenciadas, o que faz desta a lista de maior retorno do guia.
1. Torne a mudança de estado visível na tela em que o usuário já está
O feedback mais forte não é uma mensagem sobre uma mudança, é a própria mudança, exibida onde o usuário está olhando. Um selo de status que muda, uma linha que aparece numa lista, um contador que se mexe, um campo que agora mostra um valor. Uma mensagem pode passar despercebida. Uma diferença visível naquilo que a pessoa estava olhando, não.
O que isso elimina: a necessidade de confiar numa notificação em vez de ver o resultado.
2. Nomeie o objeto, não a operação
Salvo é a confirmação mais fraca possível, porque confirma que o software rodou, e não que o objetivo do usuário foi atingido. Fatura 1043 enviada para accounts@northfield.co é feedback. Ela nomeia a coisa, a ação e o destino, que é exatamente o conjunto de fatos de que o usuário precisa para comparar o resultado com o que pretendia.
O que isso elimina: a segunda checagem, em outra tela, para confirmar a primeira.
3. Feche os ciclos assíncronos onde quer que o usuário esteja
Tudo o que termina depois precisa dar retorno depois, e precisa dar esse retorno num lugar onde o usuário realmente vai estar. Uma importação concluída, uma sincronização terminada, um envio agendado: essas são as ações com mais chance de terminar em silêncio total. Uma notificação dentro do produto ou um anúncio que aparece na próxima visita do usuário fecha um ciclo que, de outro modo, ficaria aberto para sempre. Os nossos guias sobre notificações in-app e sobre como anunciar mudanças dentro do produto cobrem o lado da entrega.
O que isso elimina: o trabalho que deu certo numa tela que ninguém estava olhando.
4. Diga o que fazer em seguida, não só que terminou
O estágio sete é a comparação com um objetivo, e o objetivo quase nunca é a ação que o usuário acabou de executar: ninguém quer ter salvo uma configuração, as pessoas querem o resultado que a configuração produz. Uma confirmação que termina com o próximo passo fecha a comparação para elas. A sua primeira campanha está agendada para segunda-feira, e você pode ver uma prévia aqui.
O que isso elimina: a pausa em que um usuário que teve sucesso não sabe se já terminou.
5. Faça os erros dizerem o que fazer, e nunca falhe em silêncio
Uma falha silenciosa é o pior golfo de avaliação possível, porque o usuário sai achando que teve sucesso e descobre o contrário por um colega ou por um cliente. Qualquer erro visível, específico e acompanhado da próxima ação é melhor do que um erro calado, e vale a pena auditar o seu produto em busca de ações que podem falhar sem avisar.
O que isso elimina: o tipo de falha que o usuário descobre por outra pessoa.
6. Faça com que errar seja barato e evidente
Desfazer é um mecanismo de feedback, não só um recurso de segurança. Um caminho de volta visível diz ao usuário que sondar a interface é seguro, e é isso que permite a ele avaliar um resultado testando, em vez de escrevendo para o suporte. A combinação a buscar é uma declaração clara do que aconteceu mais um jeito de reverter com um clique.
O que isso elimina: a cautela que transforma uma ação incerta numa conversa com o suporte.
Repare quantos desses seis são texto e layout, e não arquitetura. Essa é a boa notícia do lado da avaliação: a lacuna costuma ser uma frase e uma diferença visível, não uma reconstrução. A má notícia é que ninguém é dono disso. Os problemas de execução são levantados pelos times de growth e de onboarding porque aparecem nos funis. Os problemas de avaliação não são levantados por ninguém, porque o funil diz que está tudo bem, e é por isso que quem é dono da camada de orientação acaba importando tanto quanto o que essa camada contém.
Cada release reabre os dois golfos
Os golfos não são um problema só da primeira sessão. Eles reabrem a cada mudança que você lança, para cada usuário que já tinha um modelo funcional da tela antiga.
Quando você muda um controle de lugar, alarga o golfo de execução para todo mundo que sabia onde ele ficava. Essas pessoas não são iniciantes, então nenhum fluxo de onboarding vai pegá-las, e elas vão procurar no lugar antigo duas vezes antes de abrir um ticket. Quando você muda o que uma ação faz, ou adiciona uma etapa de confirmação, ou torna assíncrono algo que antes era instantâneo, você alarga o golfo de avaliação: a mesma ação que elas já fizeram cem vezes agora produz um sinal diferente, e a leitura treinada que elas tinham da tela de repente está errada.
É por isso que uma nota de release não é uma estratégia de orientação. A nota vive fora do produto, é lida por uma pequena minoria e é esquecida antes da próxima vez que a pessoa mexe naquela tela. O que fecha um golfo criado por um release é um marcador onde a mudança está, exibido para as pessoas afetadas por ela, no momento em que elas chegam à tela. O nosso guia sobre por que os tours de produto quebram trata da outra metade desse problema, que é o fato de a sua orientação existente estar ancorada numa interface que você acabou de mudar.
-
Mudou um controle de lugar
Golfo de execução para os usuários existentes. Sinalize o novo local para o segmento que usava o antigo, e mantenha o marcador no ar por um ciclo de uso completo, e não por uma semana.
-
Mudou o que uma ação faz
Golfo de avaliação. O texto de confirmação precisa mudar junto com o comportamento, senão os usuários treinados vão ler o novo resultado como se fosse o antigo.
-
Tornou algo assíncrono
Golfo de avaliação, e o que mais passa despercebido. Algo que antes terminava enquanto o usuário olhava agora termina depois que ele sai, então precisa dar retorno.
-
Lançou algo novo
Golfo de execução para toda a sua base existente de uma só vez, porque ninguém ali viu isso durante o onboarding. É o caso em que anunciar dentro do produto, ao lado da mudança, faz o trabalho.
Como fechar os dois golfos com o Kompassify
A divisão de trabalho honesta é esta: o golfo de execução pode ser fechado em grande parte com uma camada de orientação sobre uma interface que você não vai mudar, e o golfo de avaliação, na maior parte, não pode, porque a confirmação de uma mudança de estado pertence ao produto que mudou o estado. O que uma camada de orientação e analytics pode fazer no lado da avaliação é ajudar você a encontrar as lacunas e fechar os ciclos mais lentos. As duas metades valem a pena, e só uma delas precisa do seu time de engenharia.
-
Tooltips e hotspots nos elementos reais
Crie selecionando o controle na sua própria tela, sem código, e anexe a frase que responde à pergunta que ele levanta. É a solução direta para as falhas dos estágios dois e três.
-
Tours de produto com analytics por etapa
Guie uma tarefa de várias etapas e veja qual etapa perde gente. Uma etapa também pode esperar o clique real do usuário no elemento, em vez de um botão Próximo, para que a orientação acompanhe o trabalho em vez de narrá-lo.
-
Checklists que continuam disponíveis
Um item pode abrir uma página, redirecionar ou iniciar um tour, o que dá a cada fluxo uma segunda porta e transforma um walkthrough pulado em algo a que o usuário pode voltar. Os itens marcados também são feedback por si só: um progresso que o usuário vê sem precisar perguntar.
-
Anúncios para os ciclos que fecham mais tarde
Um sino e um painel de novidades que podem iniciar um tour a partir de um anúncio e coletar feedback, e é assim que uma mudança que aconteceu depois que o usuário saiu ainda chega até ele.
-
Analytics de produto no-code para encontrar os dois golfos
O uso de funcionalidades lado a lado mostra o alcance quase zero que sinaliza um golfo de execução. O fluxo de usuários e os eventos rastreados são onde você procura a repetição, a reversão e o recarregamento que sinalizam um golfo de avaliação, que é o padrão que nenhum relatório de funil padrão vai mostrar.
-
Segmentação por público e por página em todo fluxo
Assim o marcador num controle que mudou de lugar vai só para quem usava o antigo, e ninguém recebe aviso sobre uma funcionalidade que já usa todos os dias.
O Kompassify é no-code: os fluxos são criados apontando para a sua própria interface, e a mesma camada atende um usuário na primeira semana e um cliente de dois anos, porque o gatilho é a página e o comportamento, e não a data de cadastro. É grátis até 100 usuários ativos mensais, os planos começam em $129 por mês, e ele está em conformidade com o GDPR e hospedado na UE.
Descubra em qual golfo os seus usuários estão
Sinalize os controles que ninguém encontra, responda no próprio elemento e use os relatórios de uso de funcionalidades e de fluxo de usuários para identificar as repetições e reversões que o seu funil está lendo como sucessos. Sem código. Grátis até 100 usuários ativos mensais, planos a partir de $129/mês, em conformidade com o GDPR e hospedado na UE.
Comece grátis →O que medir
Seis números, três para cada golfo. O motivo de separá-los é que um único número de adoção de funcionalidades tira a média dos dois problemas e esconde justamente o que você não está procurando.
| Métrica | Golfo | O que um número ruim significa | O que fazer a respeito |
|---|---|---|---|
| Alcance por funcionalidade | Execução | A funcionalidade é invisível para a maioria das contas a que se aplica. | Sinalize o controle para esse segmento e depois meça de novo o alcance, não os cliques. |
| Taxa de entrada até a primeira ação | Execução | As pessoas chegam à tela e não fazem nada. Encontraram a porta, mas o lado de dentro não era legível. | Corrija o estado vazio e coloque uma frase no primeiro controle. |
| Buscas sem resultado | Execução | Os usuários estão pedindo coisas com palavras que a sua interface não usa. | Renomeie antes de explicar, e confira a mesma lista um mês depois. |
| Taxa de repetição em 60 segundos | Avaliação | A ação foi concluída e a tela não disse isso de forma convincente. | Torne a mudança de estado visível e nomeie o objeto na confirmação. |
| Taxa de reversão imediata | Avaliação | Os usuários estão sondando a interface para descobrir o que a ação deles fez. | Adicione feedforward antes da ação e um resultado específico depois dela. |
| Tickets do tipo será que como parcela da fila | Avaliação | Ações específicas do seu produto terminam em silêncio. | Marque por ação, corrija no texto as três mais barulhentas e acompanhe o volume da marcação. |
O abandono por etapa é o lado da execução tornado visível: a etapa em que as pessoas saem é o estágio da tarefa que a sua interface não está explicando.
Dois desses seis provavelmente não estão no seu analytics hoje. A taxa de repetição e a taxa de reversão imediata precisam de um evento na ação e de um pouco de intenção sobre a janela de contagem, e quando você as tem, elas costumam ser os dois números mais acionáveis da lista, porque cada uma aponta para uma frase específica numa tela específica. Os nossos guias sobre rastreamento de eventos e análise comportamental mostram como configurá-las sem um time de dados, e o session replay é o jeito mais rápido de confirmar como uma repetição realmente aconteceu.
Os dois golfos: o que fazer e o que evitar
✅ Faça
- Pergunte de que lado da ação está a confusão antes de escolher uma solução.
- Marque os tickets de suporte como como eu faço ou será que, e conte os dois separadamente.
- Crie alertas para ações repetidas numa janela curta.
- Nomeie o objeto e o resultado em toda confirmação.
- Dê retorno sobre tudo o que termina depois que o usuário sai.
- Termine uma mensagem de sucesso com o próximo passo, não com um ponto final.
- Revise os dois golfos depois de qualquer release que mude um controle de lugar ou de comportamento.
- Corrija a palavra no controle antes de adicionar orientação para explicá-la.
❌ Evite
- Responder a todo problema de adoção com mais um tour.
- Tratar uma taxa de conclusão de noventa por cento como prova de que um fluxo foi entendido.
- Deixar que Salvo seja a confirmação inteira de uma ação importante.
- Permitir que qualquer ação falhe em silêncio.
- Supor que um spinner conta como feedback depois que some.
- Colocar uma nova funcionalidade só num changelog ou num e-mail de release.
- Destacar mais um controle mal compreendido e chamar isso de descoberta.
- Descartar mensagens do tipo deu certo? como usuários que não leem com atenção.
A versão em um parágrafo
Toda tarefa que um usuário tenta tem duas distâncias. Antes de agir, ele precisa descobrir se o que quer é possível, qual controle faz aquilo e como operá-lo: esse é o golfo de execução, e ele se fecha com orientação, com as palavras nos seus controles e com respostas colocadas nos elementos que levantam perguntas. Depois de agir, ele precisa descobrir se algo mudou, o que isso significa e se corresponde ao que queria: esse é o golfo de avaliação, e ele se fecha com mudanças de estado visíveis, com confirmações que nomeiam o objeto em vez da operação e com retorno sobre o trabalho que termina depois que ele já saiu. Os dois golfos produzem baixa adoção de funcionalidades, e o seu funil só mostra um deles, porque um usuário que age e não consegue saber o que aconteceu é registrado como uma conversão. Separe os seus problemas de adoção pelo lado da ação em que estão, conte as repetições e as reversões com o mesmo cuidado com que conta os abandonos, e pare de responder a um golfo de avaliação com mais orientação: aquele usuário nunca esteve perdido, e dizer de novo o que ele deve fazer não responde à pergunta que ele está fazendo.
Perguntas frequentes
O que é o golfo de execução?
O golfo de execução é a distância entre o que o usuário quer alcançar e as ações que a sua interface deixa visíveis e compreensíveis para ele. Ele é largo quando o usuário não consegue saber se algo é possível no seu produto, não sabe qual controle faz aquilo ou não consegue operar esse controle corretamente depois de encontrá-lo. Tudo nesse golfo acontece antes de a ação ser executada, e é por isso que ele se fecha com orientação: as palavras nos seus controles, um tooltip no campo que confunde as pessoas, um marcador na funcionalidade que ninguém abre e uma sequência guiada disparada na página onde a tarefa começa.
O que é o golfo de avaliação?
O golfo de avaliação é a distância entre o novo estado do seu sistema depois de uma ação e o que o usuário consegue de fato entender pela tela. Ele é largo quando o seu produto mudou alguma coisa e a interface não diz isso, diz de um jeito que o usuário não consegue decifrar ou diz num lugar para onde o usuário não está olhando. Tudo nesse golfo acontece depois da ação, e é por isso que ele se fecha com feedback, e não com orientação: uma mudança de estado visível, uma confirmação que nomeia o objeto e o resultado, um retorno sobre o trabalho que terminou mais tarde e um próximo passo claro.
Qual é a diferença entre o golfo de execução e o golfo de avaliação?
A ação separa os dois. O golfo de execução cobre tudo até a execução da ação, inclusive ela, e a pergunta do usuário é o que eu posso fazer aqui e onde. O golfo de avaliação cobre tudo depois da ação, e a pergunta do usuário é deu certo e o que mudou. Eles também deixam rastros opostos nos seus dados: um golfo de execução significa que o evento nunca dispara, enquanto um golfo de avaliação significa que o evento dispara mais de uma vez, é revertido ou é seguido de um recarregamento da página e de uma mensagem para o suporte.
Quem criou os conceitos de golfo de execução e golfo de avaliação?
Os dois termos vêm do cientista cognitivo e designer Donald Norman, como parte de um modelo de sete estágios que descreve como as pessoas agem sobre o mundo e depois julgam o resultado. O argumento mais amplo dele era que a maior parte do que se registra como erro do usuário é, na verdade, uma propriedade do design: ou a interface faz a ponte sobre essas duas distâncias, ou deixa a pessoa ilhada de um dos lados, e chamar a pessoa de descuidada não explica nada e não resolve nada.
Quais são os sete estágios da ação?
Objetivo, planejar, especificar, executar, perceber, interpretar e comparar. O objetivo se forma na cabeça do usuário. Planejar, especificar e executar formam o golfo de execução: isso é possível, qual controle faz isso, consigo operá-lo. Perceber, interpretar e comparar formam o golfo de avaliação: algo mudou, o que isso significa, é o que eu queria. A parte útil para um time de produto é que seis dos sete estágios podem falhar por causa de algo que a interface disse ou deixou de dizer, enquanto a maioria das configurações de analytics só instrumenta o quarto.
Por que um golfo de avaliação não aparece no analytics de produto?
Porque o seu funil conta a ação, e num golfo de avaliação a ação aconteceu. O usuário apertou o botão, o evento disparou, a etapa ficou registrada como concluída e o relatório diz que a funcionalidade está indo bem. A evidência do problema está em sinais que a maioria dos times não acompanha: a mesma ação repetida em menos de um minuto, uma mudança feita e desfeita logo em seguida, uma página recarregada logo depois de um sucesso e tickets de suporte que começam com salvou? ou chegou para eles?. Enquanto você não contar isso, um golfo de avaliação fica invisível para todo mundo, menos para o seu time de suporte.
Como saber se devo adicionar orientação ou corrigir o feedback?
Pergunte se o usuário agiu. Se o evento nunca dispara, ou dispara muito abaixo do número de contas a que a funcionalidade se aplica, você tem um golfo de execução e a orientação é a ferramenta certa. Se o evento dispara e depois é repetido, revertido ou seguido de um recarregamento ou de uma mensagem do tipo deu certo?, você tem um golfo de avaliação e mais orientação vai piorar a situação, porque o usuário nunca esteve perdido. Dentro do golfo de execução existe uma segunda bifurcação que vale verificar: nunca aberto indica um problema de descoberta, enquanto aberto e abandonado em segundos costuma indicar que o rótulo significava outra coisa para o usuário do que significa para você.
Qual é a diferença entre feedforward e feedback?
Feedforward é a informação que ajuda o usuário a prever o que uma ação vai fazer antes de se comprometer com ela, como uma prévia de quantos registros serão afetados ou uma frase dizendo o que acontece em seguida. Feedback é a informação que diz a ele o que de fato aconteceu, como um selo de status que muda ou uma mensagem que nomeia o objeto enviado e para onde ele foi. O feedforward estreita o golfo de execução e o feedback estreita o golfo de avaliação, e um produto pode ter muito de um e quase nada do outro.
A orientação dentro do produto consegue fechar o golfo de avaliação, ou isso exige engenharia?
Na maior parte, exige o próprio produto, porque a confirmação de uma mudança de estado pertence à coisa que mudou o estado, e uma camada de orientação sobre a sua interface não consegue inventar um selo de status que não existe. O que uma camada de orientação e analytics faz no lado da avaliação é encontrar as lacunas e fechar os ciclos mais lentos: os relatórios de uso de funcionalidades e de fluxo de usuários mostram as repetições e reversões que o seu funil está lendo como sucessos, e um anúncio dentro do produto pode dar retorno sobre um trabalho que terminou depois que o usuário saiu. O lado da execução, por outro lado, pode ser fechado quase inteiramente sem tempo de engenharia.