Como a KINTO Join encontrou o verdadeiro ponto de abandono no seu fluxo de carona
A KINTO Join é um app móvel para deslocamentos sustentáveis até o trabalho. A funcionalidade Booked Carpool permite que motoristas planejem uma carona com antecedência e registrem a viagem no dia do trajeto para que ela conte.
91%
dos motoristas que abriram a reserva no dia registraram a viagem
1 em cada 3
motoristas nunca voltou ao app no dia da partida
1 tarde
da configuração até identificar o ponto de abandono
O desafio
Quando o Booked Carpool foi lançado, a demo correu bem e o time passou para o próximo item do roadmap. Semanas depois, surgiu uma pergunta simples. Alguém está realmente usando?
O time conseguia ver quantas pessoas abriam a tela e quantos toques ela recebia. Mas esses números não mostravam se os motoristas recebiam o que a funcionalidade prometia. Essa promessa era a certeza, uma viagem garantida com antecedência e um trajeto registrado sem esforço extra.
Além disso, o fluxo não acontece de uma vez só. Um motorista pode reservar na segunda à noite e registrar a viagem na terça de manhã. Para ver o quadro completo, o time precisava de uma medição que acompanhasse os motoristas ao longo de várias sessões e dias.
Normalmente conseguimos dizer quantas pessoas abriram a tela. Conseguimos tirar um gráfico de toques. Mas esses números raramente nos dizem o que realmente importa: se a funcionalidade está resolvendo o problema que deveria resolver, para a pessoa que deveria ajudar.
A solução
Sima Ercevic, UX Lead Designer na KINTO Join, aplicou três ferramentas da UXCam ao mesmo fluxo. Os funis mostraram onde os motoristas abandonavam. As gravações de sessão mostraram o porquê. Os mapas de calor mostraram o que chamava a atenção deles na tela.
Ele configurou um funil de três etapas. Os motoristas criavam uma reserva, abriam a reserva no dia da partida e começavam a registrar a viagem. Em um mês, cerca de 64% dos motoristas que reservaram uma carona chegaram a registrá-la.
O funil mostrou onde estava a perda. Cerca de 91% dos motoristas que abriram a reserva no dia registraram a viagem, então a última etapa funcionava. O verdadeiro problema vinha antes. Quase um terço dos motoristas nunca voltou ao app naquele dia.
As gravações de sessão trouxeram o porquê. Em uma sessão, um motorista abriu os detalhes da viagem, deslizou e conferiu de novo antes de iniciar o trajeto. Essa pequena checagem dupla é invisível em um funil, mas mostra uma pessoa se certificando de que escolheu a viagem certa.
O mapa de calor da tela de reservas confirmou o resto. Os toques se concentravam nos cards de reserva, as visitas duravam só alguns segundos e os rage taps apareceram em menos de 1% das visitas. Quando os motoristas chegavam à tela, a experiência funcionava.
A configuração foi leve. Sima marcou alguns momentos-chave do fluxo e passou de uma pergunta a uma resposta clara na mesma tarde.
O que fez tudo se encaixar para mim não foi uma funcionalidade específica, mas essa conexão: os números e o comportamento humano por trás deles estão a um clique de distância.
O que vem a seguir?
Os dados afastaram o time da ideia de redesenhar a tela de reservas. A oportunidade está antes de os motoristas abrirem o app, no momento em que precisam de um empurrãozinho para voltar no dia da viagem.
Sima também quer que a medição vire um hábito. Em vez de guardar a análise para os grandes lançamentos, o objetivo é definir alguns momentos-chave para quase todas as funcionalidades que o time lança.
Você pode saber mais sobre o app na página de produto da KINTO Join.
Leia o artigo completo de Sima, Measuring Feature Success Without Losing Sight of the User, no Medium (em inglês).
Se definir alguns momentos-chave é barato, a pergunta deixa de ser “essa funcionalidade é importante o suficiente para ser medida?”. Ela passa a ser “por que lançaríamos qualquer coisa sem saber se funcionou?”.