Pizza Hut Malaysia
Omnichannel
B2C Commerce
QSR
Led end-to-end design for Pizza Hut Malaysia’s ordering experience across app, web and kiosk—a platform with 3.1M active users.
Year
2025 - 2026
Services
Product Strategy, Research, UX Architecture, Lead Design, Stakeholder Management, Design QA
At a glance
Engagement: US$5M potential value across three initial years plus a two-year extension; additional change requests sit outside this scope.
Scale: 3.1M active users in GA’s 1 January–3 August 2026 reporting window.
Platforms: Mobile app, Web, Self-checkout/Kiosk, backed by Fynd Commerce OMS (which I own as design lead).
Timeline: Pitch (Mar 2025), deal closed (May 2025), build from Jul 2025, Phase 1 ship May 2026.
My role: Design Lead, Design SPOC and 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, one on mobile UI and one on desktop, tablet and kiosk, and partnered tightly with Engineering, Product and client stakeholders.
Problem
The June–August 2025 baseline reports informed discovery and delivery after the March pitch. PHM's owned channels had demand, but the ordering funnel leaked before users could reliably see the right menu and pricing for their location.
Web had PHM's largest reported baseline audience: 368,000 monthly active users against 154,000 on Android and 141,000 on iOS, more than both apps combined. Its much lower reported conversion made web ordering a priority.
Macro channel problem (where orders come from): The baseline order mix was Offline takeaway 38%, Food Aggregators 36%, Dine-in 11%, Online takeaway 10% and Delivery 5%. Improving owned-channel ordering was an opportunity to strengthen margin, loyalty and first-party data. Reported AOVs were ~RM 40.99 on the website, ~RM 35.84 on the app and ~RM 58.69 on BYOD.
Funnel reality (where users drop): Reported baseline user conversion was ~5.3% on web, ~32.5% on iOS and ~33.9% on Android. In the July 2025 web session funnel, 101,294 sessions were the baseline: 79% engaged, 16% recorded localisation success, 11% add-to-cart, 8% checkout and 5% purchase. The large gap before recorded localisation made that journey a priority for investigation; it did not establish that every non-completing visitor had encountered a technical failure.
The June 2025 app funnel showed 100% sessions, 80% engaged, 65% localisation success, 40% add-to-cart, 30% checkout and 24% purchase. Similar engagement rates did not establish identical purchase intent. The localisation gap, together with the reported address and GPS problems, guided my focus on how users established ordering context.
Checkout also underperformed on web: 63% completion against App ~80%.
User pain: PHM provided their own review analysis, which ranked the recurring problem clusters as follows. I do not have their methodology, so I treat it as corroboration rather than measurement, but a different method pointed at the same thing the funnel did:
App crashes and technical bugs (16.3%), including checkout and payment instability.
Location and address issues (12.4%): GPS overrides, pin loops, "area not covered" shown late.
Payment and pricing issues (8.5%).
Delivery service issues (11.1%) and order-management gaps (7.2%).
Product constraint that made this harder: ~70% of pre-launch transactions were combos, so we could not simplify by removing complexity. We had to make complex ordering feel effortless and resilient to stock and pricing changes.
Before the pitch I ran a fast audit of PHM's app and its competitive set. Two days did not allow rigorous research. The full analysis came later, covering nine competitors across direct pizza QSR, broader fast food and aggregators, plus DoorDash and Pizza Hut Qatar as benchmarks. Location handling was the weakest module across the set. My read of that evidence became the design thesis: localisation is not a screen you pass, it is a state the order carries. Fix it as infrastructure, not UI.
Pitch that won the deal
We had 2 days to make the pitch real. I led a 3-person design sprint across onboarding, localisation, browsing, combos and checkout, producing 150+ screen states across mobile and desktop, and presented the interactive prototype on-site in Malaysia.
The prototype brought the proposed omnichannel experience to life:
Localisation and checkout conversion
Mix & Match (Combo Builder)
Kiosk / Self-checkout
App + Web omnichannel parity
Loyalty / Value Meals
AI-assisted checkout (pitch concept)
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.
What I designed against
The funnel gave me the priority order: two leaks and one constraint.
Localisation was the largest recorded gap. The baseline web funnel went from 79% engaged to 16% recording localisation success. Our stated goal was to reduce localisation drop-off by more than 80%; that was a target, not a measured result.
Checkout was the second priority. The supplied baseline reported 63% completion on web against ~80% on app, prompting a closer look at payment and recovery states.
Combos were ~70% of pre-launch transactions. Not a leak, a constraint. Complexity could not be removed, only made resilient.
Those three shaped the design decisions below.
What we built and why
1) Auto-localisation that doesn't feel like a gate
The original experience required users to set ordering context before meaningful browsing. I removed that mandatory entry gate and designed localisation as a state that could be established and revised throughout the journey:
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 a manual choice. Reassign only on meaningful change or invalid selection.
Cart revalidation: when location or store changes, items may become unavailable or prices can update. The user gets an explicit "what changed" moment instead of silent corruption.
Fulfilment stays editable at checkout. The same delivery/pickup control appears again in the order details card. A designer optimising for cleanliness deletes the duplicate, but if fulfilment is a state the order carries rather than a choice made once, it has to be changeable at the moment of commitment.
2) Mix & Match combo engine that enforces validity
Because combos drove ~70% of pre-launch transactions, the flow had to support customer choices while respecting inventory and pricing rules. I shipped a combo builder that is:
Stateful and step-based, with clear progress, so users always know where they are.
Resilient to inventory and pricing realities. Out-of-stock items are visibly sold out and not selectable.
Editable by returning to a step and changing a selection while keeping the rest. A separate reset action clears the selections when users want to start again.
Dynamic. Pricing updates live and reflects natively in cart.
One constraint I could not design away: the catalogue hierarchy could not express grouped steps, so a 6-item combo becomes one step per item rather than "add 2 pizzas, add 1 pasta." I could not reduce the step count, so I made the length legible instead: a coach-mark stating how many steps remain, and a completion tick on each finished step. When you cannot remove steps, remove the uncertainty about how many are left.
3) Checkout designed for reliability and recovery
The July 2025 dashboard reported 63% checkout-to-purchase completion on web versus 79.6% on app. Shipping and payment-information counts were close to checkout starts, while purchases were lower. These aggregate recorded step counts pointed to a checkout gap; they did not identify payment failures as its sole cause.
I focused the design on keeping order context visible and giving customers a clear next action when payment, availability or a session changed, while leaving room to investigate form and layout friction.
Reduced ambiguity in delivery and pickup context at checkout, so users don't discover serviceability late.
Designed failure-aware states with clear recovery when payment or session fails, including a pending-payment state that persists across surfaces and re-validates cart contents and store availability on retry rather than assuming the cart survived.
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. The checkout design file documented 13 edge-case sections, including a legibility pass still marked in progress at the time of capture. The separate mobile “Delivering to” confirmation was designed but not yet shipped at the design-review checkpoint.
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).
Contributed to front-end development alongside engineering using AI-assisted dev/QC loops (Cursor AI) to support UI implementation and design QA.
What we shipped
Localisation system: delivery and pickup contexts, address, store selection, validation.
Menu discovery and customisation foundations.
Mix & Match combo builder with validity, out-of-stock and dynamic price behaviour.
Cart and checkout flows aligned with OMS constraints, including payment-status visibility and recovery when items or stores become unavailable.
Self-checkout and kiosk journey, live.
Phase 2 scope: Dine-in, BYOD table ordering and reservations were scoped separately during the workshops, including a QR-entry flow. These are distinct from the Phase 1 delivery described here.
Phase 1 shipped in May 2026
We removed the mandatory localisation gate and shipped connected delivery/pickup contexts, cart revalidation, a configurable combo builder and checkout recovery. My contribution was the end-to-end design of these journeys and the rules customers see when ordering context changes.
The available purchase journey recorded 79.3% checkout-to-purchase completion; desktop completion was 82.4%. These are users progressing between the recorded funnel steps. Desktop is one device segment, and the mobile segment combines app and mobile-web traffic.
Product-view-to-cart completion was 49.3% and cart-to-checkout was 66.0%. Combos accounted for approximately 62.3% of items purchased, keeping combo configuration central to the next iteration. That item share uses a different denominator from the pre-launch transaction share.
The next investigation is discovery: 71.9% of users at the session-start step did not reach a recorded product view. Paid Social and Cross-network together accounted for 40.2% of new users and 3.2% of transactions when grouped by first-user acquisition channel, a signal to investigate rather than proof of the cause. The most-viewed promotional item accounted for 28.7% of item views but had a 0.92% view-to-add-to-cart item ratio. I would investigate campaign targeting, landing-page performance, home and menu visibility, offer clarity and event coverage together before assigning the loss to acquisition or product design.
Measurement note: The reports were collected after Phase 1 launch; GA activity is concentrated from May within the January–August window. The 79.3% blended and 82.4% desktop rates describe different populations from the old 63% web baseline, so they do not establish like-for-like uplift. The supplied exports do not establish a comparable localisation improvement. Ongoing analytics sat client-side.
Learnings
I would make localisation recovery a dedicated UAT checklist early in delivery: GPS denied, no serviceable store, a changed address and a cart affected by a mode switch. These states need the same attention as the successful path.
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; earlier client review could help surface structural feedback before detailed UI work.
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.
The measurement plan should have been a shared delivery requirement. I would agree localisation success/failure events and a step-by-step combo funnel with the client and engineering before launch, validate them during UAT, and define comparable web and app measurement windows. That would let the team assess the design decisions and choose the next iteration with better evidence.
