Desenhando uma calculadora de custo de viagem
Figma
Pesquisa
Design UX/UI
Liderei o redesign de uma feature subutilizada do app Trizy, o Calculador de Custo de Viagem. O que começou como correção de usabilidade virou um pivot de negócio: a restrição técnica que quase matou a feature acabou virando a semente do modelo de assinatura do app.
Resumo
Sobre o produto
O Trizy é um aplicativo mobile que auxilia motoristas de caminhão oferecendo uma interface simples para comunicação com empregadores e clientes. O app cobre agendamento de carga e descarga, negociação de frete, check-in em pátio e outras tarefas operacionais.
Sobre a equipe
Atuei como product designer, com apoio do time de Dados para analytics, do time de Desenvolvimento para integração do serviço, e da squad de Pesquisa para coordenar as sessões de teste. O time de product design utilizou o modelo Double Diamond, dividindo o processo em descoberta e entrega.
Meu papel
Liderei o design de produto da pesquisa à entrega:
Pesquisa: planejei e conduzi as entrevistas com usuários e as sessões de usabilidade que revelaram o descompasso entre expectativa do usuário e o que a feature efetivamente entregava.
Arquitetura de serviço: escopei a integração com a API de roteamento de terceiros e defini o contrato de requisição e resposta junto ao time de Desenvolvimento.
UX/UI: desenhei o novo fluxo de entrada, a tela de resultados, os estados de loading e erro, e a tela de paywall para o tier de assinatura.
O time de Dados forneceu o analytics original que sinalizou o problema de abandono. A squad de Pesquisa ajudou a coordenar as sessões de teste. O time de Desenvolvimento conduziu a implementação e o build de front-end.
Sobre a persona do usuário
Nossa base de usuários é composta por motoristas de caminhão com idade média de 42 anos. Para o Calculador de Custo de Viagem especificamente, o que importa é o contexto de decisão:
Motoristas calculam margem operacional para decidir se aceitam um frete. A diferença entre uma viagem lucrativa e uma que dá prejuízo pode estar em alguns pontos percentuais.
A maioria já tem um modelo mental de custo de viagem (combustível, pedágio, refeições, hospedagem), geralmente feito de cabeça ou no papel.
São céticos com cálculos automatizados e só confiam num número que conseguem destrinchar linha por linha.
Familiaridade limitada com interfaces cheias de formulário significa que cada campo extra custa taxa de conclusão.
Essas restrições direcionaram o desenho do formulário, o layout de breakdown dos resultados, e a decisão de mostrar custos linha a linha (combustível, pedágio, custos adicionais) em vez de apenas um total.
Discovery
O problema
O app Trizy já tinha um Calculador de Custo de Viagem desde o início, mas o analytics contava uma história estranha: o botão estava recebendo cliques, mas a maioria dos usuários não completava o fluxo. A feature não estava tecnicamente quebrada. Tinha alguma outra coisa errada.
A pesquisa
Abordamos o problema de abandono com dois métodos:
Revisão de analytics: confirmou que o calculador era um dos itens mais clicados no menu principal, mas só uma pequena fração dos usuários completava o fluxo existente.
Entrevistas com usuários e sessões de usabilidade: conduzimos motoristas pela feature existente perguntando o que esperavam versus o que receberam.
O padrão foi consistente. Usuários esperavam uma estimativa de custo automatizada baseada em informações da rota, não um caderno de despesas manual. Um motorista resumiu bem:
"Eu consigo fazer isso com uma calculadora. Eu estava esperando algo a mais"
usuário insatisfeito
Isso reformulou o problema: a feature não estava quebrada, ela era a feature errada para a expectativa que estava criando.
A solução
Expandimos a feature para entregar a experiência automatizada que os usuários de fato esperavam. A nova versão se conectava a uma API de roteamento de terceiros que recebia origem, destino, categoria do veículo, número de eixos, consumo de combustível e preço do combustível, e retornava distância da rota, tempo de viagem, custo de pedágio e custo de combustível. O usuário podia adicionar despesas customizadas (refeições, hospedagem, manutenção) por cima, e o app retornava o custo total da viagem em segundos.
Delivery
Esbocei o fluxo de integração com a API externa e alinhei o contrato de requisição e resposta com o time de Desenvolvimento. Após reuniões de alinhamento para resolver questões técnicas, o back-end estava operacional.
Para a UI, a prioridade era clareza. A persona não era tech-savvy, e o formulário tinha mais campos que a versão original. A densidade de informação precisava parecer digerível, não opressora.
A tela abre com origem, destino e paradas opcionais. O usuário então seleciona a categoria do veículo, já que o preço do pedágio varia conforme o tipo, e o número de eixos. Dois campos opcionais pedem consumo de combustível e preço do combustível. As últimas opções são a preferência de rota (mais eficiente, mais curta, evitar pedágios) e uma caixa de seleção para a viagem de volta.
Tocar no botão primário chama a API externa e navega para a página de Rota da Viagem em alguns segundos. A página de resultados mostra o mapa, distância, tempo de viagem e o breakdown dos custos (pedágio, combustível, despesas adicionais). O usuário pode alternar entre até três rotas alternativas para comparar os totais.
Decisões de interface
Algumas escolhas moldaram a nova UI:
Ordem do formulário por carga cognitiva. Origem, destino e paradas primeiro (alta familiaridade), depois veículo e preferências de rota, e os campos opcionais (consumo e preço do combustível) por último, para que o usuário pudesse submeter mesmo sem esses dados.
Defaults inteligentes. O app preenchia automaticamente o consumo de combustível com base no perfil de veículo do usuário e o preço do combustível com base em médias regionais, ambos editáveis. Reduziu fricção para motoristas que não andam com os números exatos na cabeça.
Resultados como breakdown, não como total único. Pedágio, combustível e custos adicionais recebem cada um sua própria linha. Motoristas não confiam num número único e grande, confiam num número que conseguem auditar.
Três opções de rota. Mais eficiente, mais curta e evitar pedágios. O custo de cada uma é mostrado lado a lado para o trade-off ficar visível.
Paywall enquadrado como upgrade, não como muro. Na terceira consulta gratuita do dia, um banner pequeno sinaliza o limite. O paywall propriamente aparece só na quarta tentativa, com os três resultados anteriores ainda acessíveis.
Fatores limitantes
A API de roteamento era um serviço pago. O app era gratuito. Sem um plano, o custo de cada consulta escalaria linearmente com o uso e corroeria a unit economics.
A liderança vinha pressionando o time a encontrar novas fontes de receita, e publicidade estava fora de cogitação. O Calculador de Custo de Viagem virou a porta de entrada.
Desenhamos um tier de assinatura que agrupava:
Consultas ilimitadas no Calculador de Custo de Viagem (usuários gratuitos tinham três por dia)
Navegador GPS
Cupons exclusivos e serviços de parceiros
Usuários gratuitos atingiam o limite diário naturalmente se usassem o calculador mais que algumas vezes por semana, que é o padrão real de comportamento de motoristas ativos comparando fretes. O paywall era acionado no momento de maior intenção: logo depois que o usuário preenchia o formulário e tocava em calcular a quarta viagem do dia.
Resultados
Nas primeiras semanas após o lançamento da nova funcionalidade, tivemos algumas centenas de usuários. Marcamos cada evento e botão para acompanhar adoção e identificar pontos de drop-off. O Calculador de Custo de Viagem virou um dos pontos de entrada com maior conversão para o tier de assinatura. Até agora, tivemos um número crescente de usuários com uma assinatura ativa do calculador de viagens e outros recursos premium.
Conclusão
Esse projeto mudou minha forma de pensar sobre design pós-lançamento. O dado que precisávamos para encontrar a oportunidade já estava lá, parado num dashboard de analytics que ninguém estava olhando de perto. A feature não estava falhando por má implementação, estava falhando porque ninguém tinha questionado se o conceito original batia com a expectativa do usuário.
Três coisas que levei desse trabalho:
Taxa de clique sem taxa de conclusão é uma armadilha. Um botão sendo pressionado não é validação da feature por trás dele.
Restrições podem ser o próprio design. O custo da API quase matou a feature, e acabou moldando o modelo de negócio.
Design de paywall é design de produto. Onde o muro fica, como ele é apresentado e o que o usuário continua acessando define se o upgrade soa justo ou punitivo.
Se eu fizesse de novo, investiria numa cadência estruturada de revisão pós-lançamento para que a próxima feature subutilizada seja pega em semanas, não numa revisão trimestral de analytics.
Matheus Gomes / 2025