A Checkout Built for the Amazon Region — Bemol App Redesign
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.
The Bemol checkout was one of the last areas of the app still running as a webview — a browser-rendered page embedded in a native app shell. Switching to native wasn't just a visual upgrade: it meant gaining access to system navigation, scroll performance, haptic feedback, and the full Bemol design system component library. It's also the most conversion-critical surface in the product.
This project introduces Multi-Fulfillment: a single order can split across multiple shipping origins (physical stores and distribution center), each with its own real delivery deadline, with the option to combine home delivery and in-store pickup (BOPIS) in the same cart. 91% of the Bemol customer base uses the app. Everything here was designed mobile-first.
Company
Bemol Digital
Scope
Product Design
Role
Lead Product Designer
Channels
App & Site Bemol
Status
In progress · 2026
Before: the old webview checkout
The old checkout was a single long scroll — one webview page that handled address, delivery options, payment, and order summary without any step structure. The flow documentation shows a sprawling branching tree with multiple decision points, where the customer navigated the entire process as a continuous, undifferentiated scroll.
Old webview flow
The old checkout was a single, unbroken scroll — address, delivery options, payment and summary stacked without step structure. The backend was already splitting orders into sub-orders with distinct origins; the interface gave the customer no signal of it.
The problem
Bemol's checkout displayed a single, imprecise delivery deadline. Meanwhile, the backend (SAP) was already splitting orders into multiple sub-orders with distinct shipping origins — "ORDER-01", "ORDER-02" — but customers had no visibility into this during or after purchase.
Three root causes drove this gap: the delivery deadline calculation did not reflect the actual shipping origin; the system used a single "darkstore" account for all fulfillment, bypassing real store stock and geographic proximity; and customers receiving multiple packages had no prior context, generating confusion, distrust, and support contacts.
These limitations directly impacted conversion and confidence in the delivery promise.
The opportunity
Multi-Fulfillment exposes what's already happening in the backend at the right moment in the customer journey. A single order can now display distinct packages with separate deadlines:
"Package 1 — Shipped from Store X · Delivery in up to 1 business day"
"Package 2 — Shipped from the Distribution Center · Delivery in up to 3 business days"
The project also enables BOPIS (Buy Online, Pick Up In Store) to coexist with home delivery in the same cart — a capability the platform has never had. Seller selection uses VTEX's White Label Seller heuristic combined with Google Maps geolocation polygons to calculate real, origin-specific deadlines per customer CEP.
The strategic decision: a two-phase rollout
The most consequential design decision on this project didn't happen in Figma — it was the decision to split the rollout into two deliberate phases, each with a distinct purpose.
Phase 1 — Structural MVF (Minimum Viable Frontend): The primary effort is on the backend: making the fulfillment split work reliably in production. On the frontend, the checkout keeps its existing visual structure. Only the minimum interface changes required for the new logic are shipped — package breakdown display, new components where existing ones couldn't support the multi-fulfillment scope, and targeted state updates. This is not a redesign. It's the thinnest possible surface needed to get the feature in front of real users.
Phase 2 — Full Design System Application: Once the feature is validated in production, the full Bemol design system is applied to the entire checkout. The checkout was one of the last areas of the app still on the old visual stack, so Phase 2 serves two purposes: evolving the multi-fulfillment UX and closing the product's visual debt on its most conversion-critical surface.
This approach manages technical and design risk simultaneously. The feature gets validated under real conditions before a heavier redesign investment. And the redesign, when it comes, builds on proven UX patterns rather than hypotheses.
Phase 1 — Structural MVF
Get the logic right before the visuals.
Frontend scope for Phase 1 is deliberately constrained. The changes visible to the customer are limited to what's strictly required to expose the new backend behavior:
Package breakdown in the cart: Before reaching checkout, the customer sees how their order splits across shipping origins — giving context before committing to a purchase.
New components for multi-delivery groups: Displaying independent delivery deadlines per package required new components where the existing checkout library couldn't be extended for the multi-fulfillment scope.
BOPIS selection flow: A mixed cart (some items for pickup, others for delivery) introduces a contextual store selector per item group, with per-store availability state.
All existing visual patterns — typography, colors, layout — are preserved. The goal is to validate the logic and UX patterns with real users before any redesign investment.
Cart — Package breakdown
Before reaching checkout, the customer sees how their order splits across shipping origins — Package 1 from Store X, Package 2 from the Distribution Center, each with its own delivery window. This is the first moment the split becomes visible in the product. Context before commitment.
V1 — Delivery flow
Step-based navigation replaces the single scroll. Each step has a defined scope. The delivery group component lists packages independently — separate deadlines per origin, not averaged into one imprecise date. The customer sees exactly what arrives when, and from where.
V1 — BOPIS / Pickup flow
A mixed cart — some items for pickup, others for home delivery — triggers a contextual store selector per item group. Availability is checked per store in real time. Only one BOPIS store is allowed per order; the interface enforces this constraint before the customer commits, not after.
V1 — Exception states
When a BOPIS item is unavailable at the selected store, or when a geographic polygon doesn't cover the customer's postal code, the interface offers a graceful fallback to home delivery rather than a blocking error. Cancellation constraints — BOPIS store changes after order confirmation require customer service — are surfaced at decision time, not at support time.
Phase 2 — Full checkout redesign
Visual debt, paid in full.
With Phase 1 validated in production, Phase 2 applies the full Bemol design system to the checkout end-to-end. This represents both the evolution of the multi-fulfillment experience and the closure of the checkout's visual debt.
The phase includes full typography, spacing, and color alignment with the current product; refined component architecture for the multi-delivery display — iterating on Phase 1 patterns with real usage data; and a unified checkout experience that reflects both the brand evolution and the platform's new capabilities.
The screen above isolates the central moment: the first time a customer sees their order split into distinct packages with separate delivery windows. The sequence below expands that into the complete V2 journey — cart with package breakdown, delivery group selection, and order confirmation, across the full Bemol design system.
V2 — Delivery flow
Phase 2 applies the full Bemol design system end-to-end. The 6 V1 delivery scenarios consolidate into 5; typography, spacing and component architecture are rebuilt from the ground up. The UX logic validated in Phase 1 is preserved — Phase 2 is refinement, not reconsideration.
V2 — BOPIS / Pickup flow
The 7 V1 BOPIS scenarios consolidate into 3. The embarcação modality — exclusive to riverside communities served by boat routes, where no road delivery is available — gets a dedicated state distinct from standard BOPIS and home delivery. Phase 2 is where this constraint becomes visible design, not just a business rule.
Key design challenges
Communicating package splits without creating anxiety: Showing "your order will arrive in two separate deliveries" is a design problem. The visual language must clearly distinguish packages while maintaining the perception of a single, coherent order. Getting the balance wrong erodes trust — either by making the split feel unexpected or by making the checkout feel more complex than it is.
BOPIS + Delivery in one cart: A customer can pick up one item in store and have another delivered home — in the same checkout flow. Designing the selection hierarchy (which items go where, availability per store, what happens when a BOPIS item is out of stock at the chosen location) required careful IA work with significant edge case coverage. The single-store rule isn't purely a UX simplification — it reflects an operational boundary in the VTEX and SAP integration, which supports only one store per sub-order. The team chose not to engineer around it because it aligned with a simpler selection model and fewer potential failure states. A technical constraint that became a deliberate UX decision.
Embarcação — Digital inclusion, not an edge case
The Port of Manaus, where boats depart daily to river communities across the Amazon interior.
River shipping (embarcação) isn't a fallback option for customers in remote areas — it's the only option. E-Commerce Caboclo serves riverside communities across the Amazon interior where no road exists. For these customers, a dedicated formulário customizado in the checkout isn't a special feature: it's the interface through which they access the same digital retail that urban customers take for granted.
The all-or-nothing rule — select embarcação for any item, and all other modalities disappear — is operationally grounded. Splitting one order between terrestrial and river routes would break the logistics chain. The design challenge is enforcing this constraint clearly without framing these customers as exceptions. Removing alternatives is not the same as creating a lesser path.
Cancellation constraints and expectation-setting: After order confirmation, BOPIS store changes aren't allowed via the app — changes require customer service. The UI needs to communicate this constraint before purchase, not after. The stakes aren't high for most users — but for the customer who commits to in-store pickup and then needs to change their mind, surfacing this limit early is the difference between informed choice and frustrated surprise.
Dynamic delivery deadlines: Deadlines are calculated by VTEX using geographic polygons — not static rules. The interface must handle variability gracefully: a store that doesn't cover a specific CEP, two packages with identical deadlines that should still be visually distinct, express delivery availability differences between origins. Static copy would break; the UI has to be built for variability.
Every edge case mapped here was a real customer scenario, not a theoretical one.
Observability & defined KPIs
Measurable from day one.
One of the first decisions on this project was to build observability infrastructure before launch — ensuring the feature is measurable from day one, not retrofitted afterward.
Technical SLA: Delivery simulation success rate across the VTEX ↔ SAP integration, measured continuously.
Checkout conversion: Data pipeline via VTEX ↔ SAP ↔ Databricks to track conversion before and after Multi-Fulfillment. The baseline is the current checkout conversion rate.
BOPIS adoption: Percentage of orders using the combined BOPIS + Delivery mode — a new metric that didn't exist before this feature.
Delivery deadline accuracy: Correlation between the deadline shown at checkout and the actual delivery date, tracked post-shipment.
Reflections
The best design decisions aren't always visible.
The most significant design work on this project happened away from the canvas. The two-phase rollout decision — the one that protects the team from over-investing in a redesign before the core logic is proven in production — was a product design decision, even though it doesn't appear in any deliverable.
Working at the intersection of UX and complex business rules requires the designer to understand the system deeply. I've spent significant time with the VTEX White Label Seller documentation, SAP suborder logic, and Google Maps polygon constraints — not to become an engineer, but to design experiences that reflect the system's actual behavior rather than a simplified abstraction of it. When the rules are complex, the interface has to be honest about that complexity — or manage it gracefully on the user's behalf.
