Mockup com as telas de design. A Fase 2 está em andamento e ainda não tem captura no app.
Em 30 segundos
- O checkout do app ainda era uma rolagem única em webview, com um prazo genérico, enquanto o SAP já dividia o pedido entre várias origens. Retirada e entrega não conviviam no mesmo carrinho, e a entrega por embarcação era tratada como exceção.
- Desenhei a arquitetura do fluxo e dividi o rollout em duas fases: primeiro quatro etapas sem mexer no visual, depois o design system inteiro. Pacotes, retirada na loja e embarcação passaram a aparecer dentro do fluxo.
- A Fase 1 está no ar e a Fase 2 em andamento. O fluxo resolve três modalidades num carrinho e 39 CEPs atendidos por embarcação, e foi instrumentado com o time de dados antes de lançar; os KPIs ainda não fecharam.
- Bemol Digital
- Senior Product Designer
- Product Design
- App e Web
- Fase 1 no ar · Fase 2 em andamento
Antes: o checkout em webview
O checkout antigo era uma rolagem única: um webview cuidando de endereço, entrega, pagamento e resumo do pedido sem nenhuma estrutura de etapas.
Ele mostrava um prazo só, calculado a partir de uma conta darkstore genérica, e não da origem real de cada item.
O backend já sabia dividir o pedido. Quem não sabia era a tela.
Três problemas que a interface escondia
Um prazo só para pedidos que já vinham divididos
O SAP já quebrava o pedido em sub-pedidos saindo de origens diferentes, mas a interface mostrava um prazo genérico. O cliente descobria a divisão quando o primeiro pacote chegava sozinho.
Retirada e entrega não coexistiam no mesmo carrinho
Quem queria retirar um item na loja e receber outro em casa não tinha como expressar isso num fluxo só. A hierarquia de seleção precisava deixar os dois explícitos sem dobrar o número de etapas.
Entrega por embarcação tratada como exceção
Para quem mora longe, embarcação é a única opção que existe. Tratada como caso de borda, ela funcionaria na capital e falharia justamente com quem não tem alternativa.
A decisão estratégica: rollout em duas fases
A decisão que mais pesou neste projeto foi sobre a ordem de entrega.
Dividi o rollout em dois: primeiro a estrutura, depois o visual. A Fase 1 quebrou a rolagem única em etapas sem tocar no design system. A Fase 2 aplica o sistema inteiro, com o que a Fase 1 ensinou em produção. Se as duas saíssem juntas, não daria para saber qual mudança moveu os números.
A lógica das etapas, ainda com o visual antigo.
O design system aplicado ao fluxo inteiro.
Cada sub-pedido vira um grupo de entrega visível, com prazo próprio.
Retirada na loja e entrega em casa no mesmo fluxo, que era o Problema 2.
Embarcação não é caso de borda
O E-Commerce Caboclo atende comunidades ribeirinhas no interior do Amazonas, acessíveis só por barco. Ali o prazo depende do calendário do rio, não da logística rodoviária.
O Porto de Manaus, de onde saem barcos diariamente para comunidades do interior.
A interface precisava dizer isso com todas as letras em vez de esconder atrás de uma estimativa genérica. Quem sabe que o barco sai na quinta consegue se planejar, e quem vê uma faixa vaga de dias não consegue.
O tamanho do problema
O que o fluxo passou a resolver, antes de qualquer número de desempenho. Os CEPs atendidos por embarcação ficam no Amazonas, no Pará e no Acre.
- 3
- Modalidades num carrinho
- 39
- CEPs por embarcação
Mensurável desde o primeiro dia
Instrumentamos o fluxo antes de lançar, junto com o time de dados. Cada uma das quatro etapas é um estágio do funil, e é isso que torna estes números mensuráveis.
- —
- Precisão de prazo VTEX ↔ SAP
- —
- Conversão do checkout, via Databricks
- —
- Adoção de retirada em carrinho misto
O que não foi para produção
Trocar a loja de retirada após a confirmação
Barrado pelo serviço de pedidos: confirmada, a loja fica fixa. Ajustamos a expectativa na interface em vez de prometer o que o backend não sustentava.
Rastreio por pacote na Fase 1
O serviço de rastreio devolvia um status por pedido, não por sub-pedido. Mostrar pacotes separados sem rastreio separado criaria uma pergunta sem resposta.
Prazo totalmente dinâmico no carrinho
A VTEX calcula por polígono geográfico, e resolver isso antes de existir endereço não era possível. O prazo aparece quando o endereço aparece.
Quem fez o quê
- Arquitetura do fluxo e a decisão de dividir o rollout em duas fases
- Estrutura de etapas do checkout, a peça que sustentou a Fase 1 sozinha
- Design de interação da divisão de pacotes, retirada e embarcação
- Definição dos KPIs junto com dados, antes do lançamento
- Componentes do design system, construídos com o time de DS
- Integração VTEX e SAP, com engenharia
- Rodadas de usabilidade conduzidas com o time de pesquisa
Reflexões
Duas coisas que ficaram desta entrega.
A cena que eu guardo é a de um cliente numa comunidade ribeirinha, onde só se chega de barco, fechando a compra e recebendo dias depois por embarcação. O checkout foi feito pensando nele.
A mudança que mais importou quase não aparece no visual: quebrar uma rolagem em quatro etapas. Ela foi para produção antes de existir um único componente novo.