Pizza Hut Malaysia
Omnichannel
B2C Commerce
QSR
Led end-to-end omnichannel transformation for Pizza Hut Malaysia — won a $5M 5-year engagement, fixed an 85% top-of-funnel drop-off across and modernised the ecosystem for ~4.9M customers.
Year
2025 - 2026
Services
Product Strategy, Research, UX Architecture, Lead Design, Stakeholder Management, Design QA
At a glance
Outcome: Won a $5M engagement (3+2 years) to rebuild Pizza Hut Malaysia’s digital ordering across channels.
Scale: ~4.9M customers (client base).
Platforms: Mobile app, Web, Self-checkout/Kiosk, backed by Fynd Commerce OMS (which I own as design lead).
Timeline: Pitch (May 2025) → Build (from Jul 2025) → Phase 1 ship Apr 2026.
My role: Design Lead + Design SPOC + primary client presenter. I owned product strategy, research, UX architecture, and end-to-end UI flows; we executed with engineering through dev reviews and QC.
Team: I led 2 designers (Mobile + Web & Tablet) + partnered tightly with Engineering + Product + Client stakeholders
Problem
PHM’s owned channels had demand, but the ordering funnel leaked before users could reliably see the right menu and pricing for their location.
Macro channel problem (where orders come from): Order volume was heavily split across Offline takeaway (38%) and Food Aggregators (36%), while owned digital lagged (App 17%, Website 2%). That’s a margin + loyalty + data ceiling unless owned conversion improves. Owned channels had meaningful AOV headroom (e.g., Website AOV ~RM 40.99, App AOV ~RM 35.84, BYOD ~RM 58.69) - the problem wasn’t value; it was funnel leakage.
Funnel reality (where users drop): Web conversion lagged massively vs app: Web user CR ~5.3% vs iOS ~32.5% and Android ~33.9%. The single biggest leak was localisation on web: 101,294 sessions → 79% engaged → only 15% “localise success” → 11% add-to-cart → 8% checkout → 5% purchase. That means ~85% of users failed before we could even show accurate menu/pricing (the point where QSR ordering becomes “real”). Checkout also underperformed on web: 63% completion vs App ~80%.
User pain (qual + quantified): From review analysis + UX findings, the most recurring problem clusters were:
App crashes & technical bugs (16.3%) including checkout/payment instability.
Location & address issues (12.4%) (GPS overrides, pin loops, “area not covered” shown late).
Payment & pricing issues (8.5%).
Delivery service issues (11.1%) and order-management gaps (7.2%).
Product constraint that made this harder: ~70% of transactions were combos, so we couldn’t “simplify” by removing complexity - we had to make complex ordering feel effortless and resilient to stock/pricing changes.
Before opening Figma, I audited PHM's existing app and 3 competing QSR platforms in the region. Every single one had the same failure: localisation was treated as a screen, not a system state. That audit became the design thesis — fix localisation as infrastructure, not as UI.
Pitch that won the deal
We had 2 days to make the pitch real. We produced 150+ screens with end-to-end flows across onboarding → localisation → browsing → combos → checkout, and presented it on-site in Malaysia.
What mattered: we didn’t sell screens - we sold a working omnichannel system:
Localisation and checkout conversion
Mix & Match (Combo Builder)
Kiosk / Self-checkout
App + Web omnichannel parity
Loyalty / Value Meals
AI-assisted checkout (later phase)
What I optimised for
Users don’t think in “modules.” They think: “Show me what I can order, at my location, right now - fast.” So my core bet was:
Make localisation invisible when possible.
Make it reversible when needed.
Never allow it to corrupt cart validity, pricing integrity, or store serviceability. That single bet shaped architecture, UI, and dev rules.
Targets (pre-launch)
These were defined before launch to keep the team honest and instrumentation-ready.
North-star: Increase purchase conversion on owned channels by fixing early trust + friction.
Localisation: Web "localise success": 15% → ≥80% (Equivalent to >80% reduction in localisation drop-off). App: 65% → ≥80%. Address/GPS failure events: -50%.
Add-to-cart: Web ATC rate: 11% → ≥18%. Combo completion: ≥95% once a user starts a combo flow (no dead ends).
Checkout: Web checkout completion: 63% → ≥75%. Reduce “session expired” occurrences: -50%.
Retention drivers: Increase reorder conversion: +20%. Increase rewards engagement: +25%.
What we built and why it worked
1) Auto-localisation that doesn’t feel like a gate The original experience forced users to “set context” before they could meaningfully browse, and it failed often. I redesigned localisation as a system, not a screen:
Mode-scoped contexts: separate state for Delivery vs Pickup with Delivery as default, so switching modes doesn’t destroy intent or data.
Auto-assign store when location is available; confirm when needed; never silently override manual choice; Reassign only on meaningful change or invalid selection.
Cart revalidation: When location/store changes, items may become unavailable or prices can update; user gets an explicit “what changed” moment instead of silent corruption.
2) Mix & Match combo engine that enforces validity Because combos drove ~70% of transactions, the combo flow had to be conversion-grade and ops-grade. I shipped a combo builder that is:
Stateful and step-based (clear progress; users always know “where am I?”).
Resilient to inventory + pricing realities (Out-of-stock items are visibly sold out + not selectable).
Designed for swapping, not restarting.
Dynamic pricing updates live and reflects natively in cart.
3) Checkout + reliability improvements tied to measurable drop-offs The funnel showed web checkout completion at 63% vs app ~80%, so I treated checkout as a reliability program, not just UI polish.
Reduced ambiguity in delivery/pickup context at checkout (so users don’t discover serviceability late).
Designed failure-aware states (clear recovery when payment/session fails).
Closed the loop with OMS constraints (store hours, serviceability, order lifecycle) so the UI matches operational truth.
How we executed
I ran the project with a “decisions stay traceable” discipline:
I facilitated and presented client workshops as the SPOC.
We documented workshop outcomes directly inside Figma, then replayed deltas in the next cycle.
I converted decisions into dev notes with edge cases so implementation matched intent.
AI-accelerated delivery:
Synthesised research + requirements into structured decision docs.
Used AI-assisted prototyping workflows to validate end-to-end journeys early (refer to Figma Make Prototype).
Partnered with engineering using AI-assisted dev/QC loops (Cursor AI) to catch UI/UX regressions faster.
What we shipped
Localisation system (delivery + pickup contexts, address, store selection, validation).
Menu discovery + customisation foundations.
Mix & Match combo builder with validity + OOS + dynamic price behaviour.
Cart + checkout flows aligned with OMS constraints.
Self-checkout/kiosk journey foundations.
What’s next
Roadmap items are quarterly rollouts (e.g., loyalty revamp, coupon redemption, vouchers, etc.). I explicitly scoped these for next phases to protect the Apr 2026 ship date and avoid destabilising localisation + checkout.
Phase 1 estimated to be launched April 2026. Post-launch metric tracking is instrumented — conversion results against targets to be updated.
Learnings
If I were starting over, I'd instrument localisation failure events in the prototype phase itself — we caught several edge cases late in QC that earlier telemetry would have surfaced in weeks, not days before launch.
I'd lock the prototype-approval step as a formal client sign-off gate earlier in the process. We used prototypes to validate direction internally, but getting explicit client sign-off on the prototype before Figma work began would have eliminated 2 rounds of late-stage structural feedback on flows we'd already detailed.
Combo complexity was flagged in our research but I underestimated how much it would affect checkout reliability. I'd make the combo-to-checkout flow a dedicated QA stream from sprint 1 — not something we stress-tested fully until the final phase.
