A mockup built from the design screens. Phase 2 is in progress and has no capture in the app yet.
In 30 seconds
- The app's checkout was still a single webview scroll with one generic delivery date, while SAP was already splitting orders across several origins. Pickup and delivery couldn't share a cart, and boat delivery was treated as an exception.
- I designed the flow's architecture and split the rollout into two phases: first four steps without touching the visuals, then the full design system. Packages, in-store pickup and boat delivery now show up inside the flow.
- Phase 1 is live and Phase 2 is in progress. The flow handles three methods in one cart and 39 postcodes served by boat, and it was instrumented with the data team before launch; the KPIs haven't closed yet.
- Bemol Digital
- Senior Product Designer
- Product Design
- App & Web
- Phase 1 shipped · Phase 2 in progress
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 backend already knew how to split the order. The screen didn't.
Three problems the interface was hiding
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.
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.
Delivery by boat treated as an edge case
For remote customers, boat delivery is the only option there is. Treated as an edge case, it would have worked in the capital and failed exactly the people with no alternative.
The strategic decision: a two-phase rollout
The decision that weighed most on this project was about the order of delivery.
I split the rollout in two: first the structure, then the visuals. Phase 1 broke the single scroll into steps without touching the design system. Phase 2 applies the full system, with what Phase 1 taught us in production. If both had shipped together, there would be no way to tell which change moved the numbers.
The step logic, still wearing the old visuals.
The design system applied across the whole flow.
Each sub-order becomes a visible delivery group, with its own deadline.
Store pickup and home delivery in the same flow, which was Problem 2.
Embarcação is no 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 Port of Manaus, where boats depart daily to communities across the interior.
The interface had to say so plainly instead of hiding it behind a generic estimate. A customer who knows the boat leaves on Thursday can plan around it, and one who sees a vague range of days can't.
The size of the problem
What the flow had to resolve, before any performance number. The postcodes served by boat are in Amazonas, Pará and Acre.
- 3
- Methods in one cart
- 39
- Postcodes served by boat
Measurable from day one
We instrumented the flow before launching, alongside the data team. Each of the four steps is a funnel stage, which is what makes these numbers measurable.
- —
- VTEX ↔ SAP deadline accuracy
- —
- Checkout conversion, via Databricks
- —
- Pickup adoption in mixed carts
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
- 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
- Design system components, built with the DS team
- VTEX and SAP integration, with engineering
- Usability rounds run with the research team
Reflections
Two things that stayed with me from this one.
The picture I keep is a customer in a riverside community you can only reach by boat, finishing a purchase and getting it days later by boat. The checkout was built with that person in mind.
The change that mattered most barely shows in the visuals: breaking one scroll into four steps. It shipped before a single new component existed.