Project Snapshot
One app, four incompatible services.
In 2023, Taiwan's second-largest convenience store chain set out to merge its grocery services into one app: vouchers, frozen delivery, standard delivery and in-store pickup. Each ran on its own logistics, payment timing and fulfilment rules. The backend could not change, so the checkout had to absorb the complexity.
The brief was simple: merge the cart. Three years later, the client rebuilt their logistics around the same structure.
Result
Launched Q1 2024. Validated by the client's logistics rebuild in 2026.
+15%
Retention rate
+20%
Average order value
2026
Logistics rebuild confirmed the architecture
Problem
Users came for vouchers and stopped there
3,000+ survey responses showed 80% of active users came only to redeem vouchers. Focus groups confirmed cross-category demand, strongest among family shoppers.
Four services, four rule sets
Separate logistics streams, payment timing and tracking logic: one checkout would break at every reconciliation point, however the interface looked.
Naming it: a governance problem at the checkout layer
I raised it in a stakeholder meeting: a routing and payment governance problem that needed logistics, payment and category teams to resolve. That alignment could not happen in time, so the design proceeded without it.
From Constraint to Checkout Logic
Decision 1 — What could not change
Each category team kept its own logistics, fulfilment rules and revenue tracking. Backend restructuring was out of scope, and with it any solution that needed cross-team coordination underneath.
Decision 2 — The problem nobody had named
A single order spanning services with different fulfilment rules could not be processed as one. I raised this as a researcher whose brief said nothing about checkout architecture: without grouping and split orders, consolidation was not possible.
Decision 3 — Group by fulfilment type, not by backend
The only lever left was the checkout. I grouped the cart by the semantics of fulfilment type rather than the backend of the moment, so the structure could survive rule changes nobody could predict. That became the smart cart.
Solution
The grouping and split-order mechanism
Items group automatically by fulfilment type. Each group carries its own address, fee, threshold and delivery date, and settles as a sub-order under one checkout. Users see one cart. The backend keeps its streams.
In-store pickup as a separate checkout path
One conflict could not be absorbed: paying at the counter cannot share a settlement with delivery orders. I separated it as its own checkout path, a hypothesis at the time, validated later in testing.
Research was the brief. Wireframes were the handover.
Written recommendations let every stakeholder imagine a different solution, so I translated the findings into flow wireframes the internal team could build from. Smart cart shipped and is live today.
Inside the Smart Cart
Feature 1 — Auto-grouping, from cart to tracking
Auto-grouping routes items by fulfilment type, from cart to tracking. Delivery method is chosen at add-to-cart, and the cart groups items with no manual input. The same grouping restructured order tracking: eight ambiguous status tabs became three layers, each showing only what its logistics type needs.
Feature 2 — Costs surface when they matter
Fulfilment labels and costs surface only when they affect the user's decision. Fulfilment type is visible from the product page. Each group shows its own timeline, fee and free-shipping threshold; the delivery step consolidates the total. In testing, costs only made sense anchored to their group.
Feature 3 — In-store pickup: a separate transaction
In-store pickup is framed as a separate transaction. Paying at the store and paying online are different tasks in users' heads. The in-store group surfaces as its own card, cart switching preserves both carts, and pay-at-pickup issues its own confirmation, barcode and store guidance.
Try the flow
Two Years Later
The 2026 rules
In 2026 the client restructured their logistics. Frozen became store pickup only. Standard kept home delivery and store pickup. Vouchers stayed independent. In-store pickup kept its separate checkout path.
Why the architecture held
These are the same conflicts I had named in 2023 as needing cross-department alignment to resolve. The smart cart survived the restructure because its grouping followed the semantics of fulfilment, so the backend could change underneath it. The rules are observable in the live app today.
Outcome
Launched Q1 2024. Shipped across the homepage, product pages and the unified checkout flow.
+15% retention, +20% average order value.
The 2026 rebuild confirmed the architecture.
Checkout abandonment also fell, most visibly around the delivery cost step.
Reflection
The reframe was the most important design decision
The brief was a research and design task; the real problem was logistics governance. Recognising that before design began changed everything downstream.
Crossing the brief was worth it
Extending from research into architecture was outside my role on paper, and it is what made the checkout architecture possible.
What I would do differently
Pull logistics and ops in earlier, and quantify the payment timing conflict during research so it enters prioritisation as data.
