2026

Um checkout pensado para a Amazônia

O checkout do Bemol ainda era um webview enquanto o backend já tinha crescido além dele. Este projeto expõe o que já acontecia, e faz funcionar para o cliente.

Empresa
Bemol Digital
Papel
Senior Product Designer
Escopo
Product Design
Canais
App e Web
Status
Fase 1 no ar · Fase 2 em andamento

Checkout antigo vs. redesign

  • O checkout antigo em webview ao lado do redesign em quatro etapas

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 ponto de partida

  • Checkout antigo como uma rolagem única em webview

    Uma rolagem única em webview: endereço, entrega, pagamento e resumo sem estrutura de etapas.

A lacuna não estava no backend. Estava entre o backend e o cliente.

Três problemas, nomeados separadamente

  1. Problema 1

    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.

  2. Problema 2

    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.

  3. Problema 3

    Entrega por embarcação tratada como exceção

    Para quem mora longe, embarcação é a única opção que existe. Desenhá-la como caso de borda deixaria a interface honesta na capital e inútil no interior.

A decisão estratégica: rollout em duas fases

A decisão mais consequente deste projeto não aconteceu no Figma.

Dividir o rollout em dois: primeiro a estrutura, depois o sistema visual. A Fase 1 quebrou a rolagem única em etapas discretas sem tocar no design system. A Fase 2 aplicou o sistema inteiro, com refinamentos aprendidos em produção.

Entregar as duas juntas tornaria impossível saber qual mudança moveu os números.

Fase 1: MVF estrutural

  • Checkout dividido em quatro etapas sequenciais

Acertar a lógica antes do visual.

Fase 2: redesign completo

  • Checkout redesenhado com o design system do Bemol aplicado

Dívida visual, paga por inteiro.

Pacotes, visíveis

  • Divisão de pacotes exibida como grupos de entrega distintos

    Cada sub-pedido vira um grupo de entrega visível, com prazo próprio.

Retirada e entrega, um carrinho

  • Seleção de loja para retirada dentro do fluxo de checkout

    Retirada na loja e entrega em casa convivendo num fluxo só. O Problema 2, respondido.

Embarcação: inclusão digital, 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.

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 quinta-feira consegue se planejar; quem vê uma faixa vaga, não.

De onde vem o prazo

  • O Porto de Manaus, de onde saem os barcos para as comunidades ribeirinhas

    O Porto de Manaus, de onde saem barcos diariamente para comunidades do interior.

Entrega por embarcação, dentro do fluxo

  • Opção de entrega por embarcação exibida no checkout

Quatro etapas, instrumentadas

  • As quatro etapas do checkout, cada uma um estágio mensurável do funil

    Cada etapa é um estágio do funil, e é isso que torna os KPIs abaixo mensuráveis.

O tamanho do problema

O que o fluxo passou a resolver, antes de qualquer número de desempenho.

1 → 4
De uma rolagem única para etapas discretas
3
Modalidades de entrega convivendo no mesmo carrinho
39
CEPs atendidos por embarcação, no Amazonas, Pará e Acre

Mensurável desde o primeiro dia

A observabilidade foi construída antes do lançamento, não remendada depois.

Precisão de prazo VTEX ↔ SAP· pendente
Conversão do checkout, via Databricks· pendente
Adoção de retirada em carrinho misto· pendente

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ê

Christofer

  • 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

Com o time

  • 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

As melhores decisões de design nem sempre são visíveis.

Um cliente numa comunidade ribeirinha, acessível só por barco, concluindo uma compra e recebendo dias depois por embarcação. É para isso que este checkout existe.

A mudança que mais importou não tem assinatura visual: quebrar uma rolagem em quatro etapas. Ela foi para produção antes de existir um único componente novo.