2026

A checkout built for the Amazon region

The Bemol checkout was still a webview while the backend had already outgrown it. This project exposes what was already happening, and makes it work for the customer.

Company
Bemol Digital
Role
Senior Product Designer
Scope
Product Design
Channels
App & Web
Status
Phase 1 shipped · Phase 2 in progress

Old checkout vs. redesign

  • The old webview checkout next to the redesigned four-step checkout

Before: the old webview checkout

The old checkout was a single long scroll: a webview handling address, delivery options, payment and order summary with no step structure at all.

It showed one delivery deadline, calculated from a generic darkstore account rather than the real origin of each item.

The starting point

  • Old checkout as a single long webview scroll

    One long webview scroll: address, delivery, payment and summary with no step structure.

The gap wasn't in the backend. It was between the backend and the customer.

Three problems, named separately

  1. Problem 1

    One deadline for orders that were already split

    SAP was already breaking orders into sub-orders shipping from different origins, but the interface showed a single generic deadline. The customer learned about the split only when the first package arrived alone.

  2. Problem 2

    Pickup and delivery couldn't coexist in one cart

    A customer picking up one item in store and having another delivered had no way to express that in a single flow. The selection hierarchy had to make both explicit without doubling the number of steps.

  3. Problem 3

    Delivery by boat treated as an edge case

    For remote customers, embarcação is the only option there is. Designing it as an exception would have made the interface honest for the capital and useless for the interior.

The strategic decision: a two-phase rollout

The most consequential decision on this project didn't happen in Figma.

Splitting the rollout in two: first the structure, then the visual system. Phase 1 broke the single scroll into discrete steps without touching the design system. Phase 2 applied the full system end to end, with refinements learned in production.

Shipping both at once would have made it impossible to tell which change moved the numbers.

Phase 1: structural MVF

  • Checkout broken into four sequential steps

Get the logic right before the visuals.

Phase 2: full redesign

  • Redesigned checkout with the Bemol design system applied

Visual debt, paid in full.

Packages, made visible

  • Package split shown as distinct delivery groups

    Each sub-order becomes a visible delivery group, with its own deadline.

Pickup and delivery, one cart

  • Store selection for pickup within the checkout flow

    Store pickup and home delivery coexisting in a single flow. Problem 2, answered.

Embarcação: digital inclusion, not an edge case

E-Commerce Caboclo serves riverside communities across the Amazon interior, reachable only by boat. Deadlines there depend on river schedules, not road logistics.

The interface had to state that plainly instead of hiding it behind a generic estimate: a customer who knows the boat leaves on Thursday can plan; one who sees a vague range cannot.

Where the deadline comes from

  • The Port of Manaus, where boats depart to river communities

    The Port of Manaus, where boats depart daily to communities across the interior.

Delivery by boat, in the flow

  • Boat delivery option shown in the checkout

Four steps, instrumented

  • The four checkout steps, each one a measurable funnel stage

    Each step is a funnel stage, which is what makes the KPIs below measurable.

The size of the problem

What the flow had to resolve, before any performance number.

1 → 4
From a single scroll to discrete steps
3
Fulfillment methods coexisting in one cart
39
Postcodes served by boat across Amazonas, Pará and Acre

Measurable from day one

Observability was built before launch, not retrofitted after it.

—
VTEX ↔ SAP deadline accuracy· pendente
—
Checkout conversion, via Databricks· pendente
—
Pickup adoption in mixed carts· pendente

What didn't ship

  • Changing the pickup store after confirmation

    Blocked by the order service: once confirmed, the store is fixed. We set the expectation in the interface instead of promising something the backend couldn't honour.

  • Per-package delivery tracking in Phase 1

    The tracking service returned one status per order, not per sub-order. Showing separate packages without separate tracking would have created a question we couldn't answer.

  • Fully dynamic deadlines at cart level

    VTEX calculates by geographic polygon, and resolving that before an address exists wasn't possible. The deadline appears once the address does.

Who did what

Christofer

  • Flow architecture and the decision to split the rollout in two phases
  • Step structure of the checkout, the piece that carried Phase 1 on its own
  • Interaction design for package splits, pickup and boat delivery
  • KPI definition together with data, before launch

Com o time

  • Design system components, built with the DS team
  • VTEX and SAP integration, with engineering
  • Usability rounds run with the research team

Reflections

The best design decisions aren't always visible.

A customer in a riverside community, reachable only by boat, completing a purchase and receiving it days later via embarcação. That's what this checkout is for.

The change that mattered most has no visual signature: breaking one scroll into four steps. It shipped before a single new component existed.

pt