Contexto: E-commerce · Pós-compra
Meu papel: Product Designer
Time: Product Owner · Tech Lead · Dev Lead · Developers · QA
Atuação: Análise e clusterização de feedback · Investigação com Logística · Definição de hipótese e métrica · UX/UI · Prototipação
Problema
Os status mostravam o avanço da entrega, mas clientes ainda relatavam dificuldade para entender onde seus pedidos estavam.
Descoberta
A limitação não estava apenas na interface: cada transportadora fornecia diferentes níveis de informação sobre o trajeto.
Direção
Começar pelas transportadoras com dados mais completos e medir se maior transparência sobre a localização reduziria as reclamações.
Primeiro precisávamos ouvir melhor
A dificuldade em acompanhar entregas já era uma dor conhecida pelo time de SAC. Mas precisávamos entender como essa percepção aparecia dentro da própria experiência digital e criar uma forma de acompanhá-la ao longo do tempo.
Propus ao Product Owner incluir uma pesquisa de satisfação diretamente na página de acompanhamento do pedido:
“As informações para acompanhar o seu pedido foram úteis?”
O cliente poderia responder Sim ou Não. Nas respostas negativas, abríamos um campo para que ele pudesse explicar o motivo.
Isso nos deu um sinal contínuo sobre a experiência e, principalmente, acesso à voz dos clientes no contexto em que o problema acontecia.
Os comentários revelaram um padrão
Analisei e agrupei os comentários negativos por temas para identificar os problemas mais recorrentes na experiência.
A falta de clareza sobre a localização do pedido apareceu entre os três principais temas identificados.
Os clientes recebiam atualizações sobre o andamento da entrega, mas ainda demonstravam dificuldade para responder a uma pergunta aparentemente simples: Onde está o meu pedido agora?
O que os clientes diziam
“’O seu pedido está na unidade da Transportadora mais próxima de você.’ Não poderia informar a localidade? Do jeito que está, não acrescenta nenhuma informação útil."
“Seria útil ter a data estimada de entrega. Dizer que está com a transportadora mais proxima do meu local não quer dizer nada”
“Talvez fosse interessante dizer se o produto está na cidade de destino, pois não está claro qual é a unidade da transportadora mais próxima de nossa residência.”
O status explicava a etapa, mas não a localização
A experiência existente já comunicava diferentes momentos da entrega: quando o pedido estava com a transportadora, quando seguia entre unidades e quando estava a caminho do endereço do cliente.
Mensagens como:
“O seu pedido está na unidade da transportadora mais próxima de você.”
informavam o progresso da entrega, mas ainda deixavam uma lacuna:
Qual unidade? Em qual cidade?
Percebemos que havia uma diferença entre informar o estágio da entrega e oferecer visibilidade sobre a localização do produto.
Nossa hipótese passou a ser que complementar os status existentes com informações de cidade e estado poderia tornar o acompanhamento mais útil e reduzir os comentários negativos relacionados à falta de localização.
Para mostrar mais, primeiro precisávamos saber mais
Uma mudança aparentemente simples na interface revelou uma dependência muito maior: a experiência só poderia mostrar os dados que recebíamos das transportadoras.
Em parceria com o time de Logística, solicitamos um levantamento das informações disponibilizadas pelas principais transportadoras.
Foi quando identificamos um cenário fragmentado.
Cada transportadora utilizava seus próprios sistemas e padrões de acompanhamento. Algumas forneciam informações detalhadas sobre as movimentações do produto, incluindo cidade e estado. Outras disponibilizavam apenas parte do trajeto.
O problema era maior do que parecia
DE
Como podemos mostrar melhor onde está o pedido?
PARA
Como criar uma experiência consistente a partir de dados que não são consistentes?
Mais cobertura ou mais consistência?
A diferença na qualidade dos dados nos colocou diante de uma decisão: priorizar cobertura, esperar por maior consistência ou começar menor para aprender mais rápido.
Usar os dados disponíveis
Maior cobertura
Exibir a localização sempre que estivesse disponível permitiria alcançar mais pedidos.
Risco
A informação poderia aparecer em uma etapa e desaparecer na seguinte, criando uma experiência inconsistente.
Esperar todas as transportadoras
Maior cobertura e consistência
Esperar a adequação dos sistemas permitiria oferecer uma experiência mais completa para mais pedidos.
Risco
Dependeríamos de mudanças de diferentes transportadoras antes mesmo de validar se maior visibilidade reduziria as reclamações.
Começar com dados confiáveis
Experiência consistente · Aprendizado mais rápido
Começar pelas transportadoras que já forneciam dados completos permitiria oferecer uma experiência consistente e testar a hipótese sem depender de mudanças externas.
Trade-off
A solução estaria disponível inicialmente para uma parcela menor dos pedidos.
- Decisão escolhida
Por que seguimos por esse caminho?
Começar em menor escala nos permitiria observar se maior transparência sobre a localização realmente reduziria as reclamações antes de discutir a expansão da solução com as demais transportadoras.
Aprender antes de escalar
A decisão também definiu nossa estratégia de rollout.
Começaríamos pelos pedidos atendidos por transportadoras com maior qualidade de dados e acompanharíamos a incidência de comentários negativos relacionados à localização.
Nossa hipótese era:
Se oferecermos informações mais precisas sobre onde o pedido está, esperamos reduzir as reclamações relacionadas à falta de visibilidade durante a entrega.
O plano era utilizar esse aprendizado não apenas para avaliar a experiência, mas também como evidência para discutir a importância de dados mais detalhados com as demais transportadoras.
Como mediríamos
Recorrência de comentários negativos relacionados à localização do pedido na pesquisa da página de acompanhamento.
Transformando dados logísticos em informação para o cliente
Com a estratégia definida, trabalhamos na evolução da experiência de acompanhamento.
Em vez de substituir os status existentes, a proposta os complementava com as informações de localização disponíveis, permitindo ao cliente entender não apenas o que estava acontecendo com sua entrega, mas também onde aquela movimentação estava acontecendo.
Explorei alternativas de conteúdo e refinamos a proposta internamente com os stakeholders, considerando clareza para o cliente e compatibilidade com os dados fornecidos pelas transportadoras.
A solução foi prototipada, mas não realizamos testes com usuários antes do encerramento da minha participação no projeto.
Além da interface
A investigação mostrou que a granularidade das informações fornecidas pelas transportadoras não tinha apenas valor operacional: ela afetava diretamente a experiência que conseguíamos oferecer ao cliente.
A partir das discussões do projeto, o time de Logística passou a considerar informações como cidade e estado relevantes para futuras contratações e renovações de transportadoras.
Meu envolvimento terminou antes do rollout. Por isso, não acompanhei se esses requisitos foram formalmente incorporados aos contratos nem os resultados da solução após uma eventual implementação.
O que levei desse projeto
Comecei investigando comentários sobre uma experiência digital e terminei entendendo parte da complexidade por trás de uma cadeia logística.
O projeto mostrou que uma melhoria aparentemente simples na interface pode depender de sistemas, dados e decisões que estão muito além dela. Em vez de esperar pelo cenário ideal, buscamos uma forma de começar com informações confiáveis, aprender em menor escala e usar evidências para orientar uma possível expansão.
Esse projeto reforçou uma prática que passei a levar para outros desafios de produto: entender o sistema por trás da experiência antes de tentar simplificar aquilo que aparece na tela.