Designing at platform scale across Restaurant Brands International
As Design Lead I owned design governance, delivery quality and cross-stream alignment across RBI's multi-brand digital platform — and inside that remit, ran the discovery this case study is about.
My role & impact
Team & cross-stream leadership
Formally led a 5-designer team across Core FE, Transactions, Engagement and Iberia — guiding solution direction, reviews and delivery quality.
Design governance & review
Reviewed cross-stream work before client reviews, helping teams hold requirement coverage, brand consistency and quality.
Design intake & classification
Co-developed an intake model for design requests, aligning PMs, BAs and stakeholders on effort and workflow before sprints.
Delivery predictability
Introduced Design QA as part of sprint, and ran workshops for developers to enable better Figma inspection and visual regression.
Four workstreams, one remit.
I contributed across strategic discovery, platform delivery, design-system quality and campaign scalability — both hands-on and through cross-stream collaboration.
Design System v02
Partnered with Core FE developers and QA across 31 React components, adding Design QA into the sprint workflow and running Figma inspection workshops to reduce implementation drift early.
Prepaid Offers discovery
Led a revenue-critical discovery outside my assigned stream — defining purchase and redemption flows, feasibility guardrails, support-tool needs, event mapping and Sanity-led campaign considerations.
iOS & Android Live Activity
Co-explored iOS Live Activities and Android Live Updates with the Menu & Delivery designer, using Xcode and Android Studio testbeds to clarify platform constraints and shape realistic order-status experiences.
Dragon Ball Z app takeover
Guided the conversion of a one-off campaign takeover pattern from the US implementation into a scalable, Sanity CMS-driven model — then supported a Phase 1 light-to-medium takeover for Dragon Ball Z across guest apps.
Of the four, one carried the most commercial risk and the least existing pattern. The rest of this study is that one.
Designing Burger King's Buy Now, Redeem Later prepaid model
Burger King could sell meals. The discovery asked whether it could sell future meal value — and what systems needed to change to make that real.
- Whopper Meal£6.49
- Large Fries£1.99
- Diet Coke£1.29
- Total£9.77
- Incl. VAT (20%)£1.63
- Visa ···· 4821 — £9.77
- Grande Caramel Latte£5.50
- Blueberry Muffin£3.25
- Stars Reward-£0.50
- Total£8.25
- Incl. VAT (20%)£1.38
- Mastercard ···· 7392 — £8.25
This is a business opportunity, not a user complaint.
Burger King was not reacting to existing user pain. It was proactively exploring a proven model — one already working in China and across Europe.
“Burger King is exploring the opportunity to decouple the moment of purchase from the moment of consumption, enabling users to prepay and redeem later.”
— Discovery epic, TRX-4681
Capability gap: BK vs best-in-class
Maturity, scored out of 10unrealised float potential
- Starbucks stored value
- $1.77B
- BK stored value
- None
- BK float tracking
- None
Modelled from the Starbucks stored-value benchmark against BK transaction volume. An indicative size for the prize, not a forecast.
Five capability gaps, one unified opportunity
The market gap was visible. The harder question was whether BK's platform could support a decoupled model at all.
Six systems that had never been asked to talk to each other.
Before any UX work could begin, I needed to know whether BK's platform could technically support a decoupled purchase-to-redemption model. Six systems, mapped against six critical readiness themes.
CRM / Media Platform
Persistent ad attribution?
Deep Link / App Routing
Personalised offer deep links?
PSP / Payment
Prepaid payment without fulfilment?
Loyalty / Offers Engine
Store & sync redemption state?
CRM / Engagement
Event-based reminders?
POS / App Redemption
Redeem with minimal disruption?
Not one system was outright ready. That finding is the reason this discovery ran for six months and produced a build-ready spec rather than a concept deck — the design work could not be trusted until the platform questions had answers.
With the feasibility landscape mapped, I needed to frame what we were actually trying to prove before designing anything.
Proving the model before drawing a single screen.
Discovery was structured around five testable hypotheses, each tied to a specific business risk, and tracked through weekly stakeholder calls across the entire duration of the work.
- 1Jun 2025Discovery openedEpic raised; feasibility mapping begins
- 2Jul 2025“Not loyalty” decisionKey frame established: prepaid ≠ Crown Rewards
- 3Jul – AugFlows V1–V3 reviewedDedicated cart, deep-link entry confirmed
- 4Aug 2025UJM & blueprint mapped8-stage journey + 8-stage blueprint complete
- 5Sep – OctEdge cases resolvedUnavailability, refunds, customisation policy
- 6Feb 2026MVP scope finalised22 items explicitly out of scope. Build-ready
Five hypotheses that kept the scope honest
Each one names the risk it exists to retire
Users are willing to purchase prepaid items even if they cannot redeem immediately.
Decoupled model has standalone value. Not contingent on same-visit behaviour.
Reminders within 48–72 hours of expiry significantly increase redemption rates.
CRM timing rules are critical infrastructure. Not optional in MVP.
First-time users engage more with value-led offers; existing users with convenience and variety.
Campaign targeting can serve acquisition and retention as distinct audiences.
Redemption success and satisfaction is higher via in-app QR than at store counters.
Mobile-first redemption flow should be the MVP primary path.
Offer personalisation (drink vs. fries) increases purchase intent.
CRM preference logic is a Phase 2 priority. Must be architected for now.
With the hypotheses framed, I needed to map exactly where users would lose trust on the journey.
Three places where trust breaks.
The eight-stage journey from ad impression to post-redemption surfaces three critical failure points — the moments where the decoupled model stops making sense to users.
Hover any stage to trace it on the curve below.
“This looks like a good deal.”
“Where is this taking me?”
“What's the catch?”
“Hope I'm charged correctly.”
“Did I actually get it?”
“Oh, I forgot this!”
“Hope they accept this.”
“That was smooth.”
Where the trust curve breaks
The three dips are where the decoupled model stops explaining itself
Seven UX opportunity areas
Each one is anchored to a stage, not to a screen
Knowing where trust broke was not enough. One stakeholder decision then removed every shortcut we had for fixing it.
Prepaid is NOT a loyalty feature.
Stakeholders explicitly agreed: prepaid offers are paid discounted offers, not rewards. That single sentence killed several natural UX shortcuts and forced a distinct design path.
Natural shortcuts to Crown Rewards integration, loyalty-adjacent UX patterns and points-accrual mechanics — all removed from scope.
A standalone identity: a “Prepaid” tag across surfaces, a dedicated purchase flow, and a category that could evolve independently of loyalty.
The entire post-purchase confirmation, offer storage experience and redemption flow — we had no existing pattern to borrow from.
It also required new content fields in Sanity CMS — and revealed that no team had yet claimed ownership of prepaid content configuration.
Three flows, one clear path.
The full purchase-to-redemption experience across new users, existing logged-in users and in-restaurant redemption — a dedicated flow, distinct from every existing BK app pattern.
Price and the decoupling promise sit in the same eyeline — nobody taps through to find out what “prepaid” means.
Deep link resolves to the exact offer. Terms are on the purchase screen, not one tap behind it.
“Saved to Offers” is the whole trust fix — it names where the money went before the user has to look.
The “Prepaid” tag and a countdown, not a rewards badge. Distinct identity, per the reframe.
QR first, cashier code as fallback — because POS readiness varies by market and franchisee.
Designed for the edges too
The happy path is the easy half. A prepaid model breaks trust hardest when the money is already spent and something goes wrong — an ad that outlived its campaign, an item the chosen store can't make today.
Every edge state resolves to a next action. None of them dead-end on an apology.
A dead link still ends somewhere useful.
Guide, never override: the offer stays valid, the route changes.
The flows were clear. Keeping them shippable required a different kind of discipline.
We said no to twenty-two things, so we could say yes globally later.
Twenty-two features were explicitly excluded from the MVP — not because they weren't valuable, but because shipping a focused test was more valuable than shipping a complete product.
Test before you scale
The MVP is a deliberate proof point. Every exclusion keeps the test clean — one market, one item, one flow — before global rollout.
Platform readiness first
Six of the 22 were removed because the underlying systems — POS, loyalty sync, deep links — were not yet validated for those scenarios.
Protect the critical path
Scope creep in any of these areas would have delayed the whole MVP. Each “no” protected the one thing that mattered: purchase → store → scan.
From ad_id to “You redeemed this on 17 June at London BK.”
One user tap at the POS triggers a chain across six systems. Each system is a layer — watch a field originate in one layer, then carry down through every layer beneath it, all the way to redemption.
Hover a field to trace how far it has to travel.
Three fields cross a system boundary. Those three are where the experience breaks.
Support visibility: read-only in MVP
Support agents can see the full prepaid record across two tabs — Orders for the purchase, Loyalty for the offer's status. Write access is deliberately out of scope.
The reason is the lineage above: until is_redeemed is the single source of truth across POS and loyalty, a support agent editing state by hand would create a second version of the truth. Visibility answers the call. Control would have created the next one.
Six months, six systems, one concept that did not exist when we started. Here is what held it together.
Seven principles. One I wish I'd used sooner.
Six months of discovery on a concept that didn't exist yet. What platform readiness looked like at the start against the end — and the principles that held the work together.
Platform readiness: before → after discovery
Validated confidence, not technical completion. Hover an axis for the delta.
Seven principles that emerged
- Make prepaid behaviour explicit. Never let users infer what happened to their money.
- Preserve user confidence after purchase. They need to know exactly where the offer went.
- Avoid mixing mental models. Prepaid ≠ loyalty ≠ coupon. Own a distinct identity.
- Keep the MVP operationally constrained. 22 explicit exclusions protect the critical path.
- Support agents need visibility, not control. Read-only access is enough for MVP trust.
- Handle store availability transparently. Guide, don’t override user expectations.
- Measure both purchase AND redemption. Purchase alone doesn’t prove the model works.
Make prepaid behaviour explicit. Never let users infer.
Early flows assumed “buy now, redeem later” would be self-evident from context. It wasn't. The moment the copy and UI said plainly what had happened to the money, comprehension improved. That should have been the starting constraint, not a mid-discovery finding.
Where it landed
Scope finalised Feb 2026 — build-ready, one market, one item, one flow
From a hard-coded app takeover to a reusable, shipped platform model.
We analysed the U.S. team's SpongeBob implementation, defined a tiered takeover model, and shipped it as a Sanity-powered Dragon Ball Z takeover across guest app surfaces.
- Hard-coded per campaign
- One market (US)
- One campaign — SpongeBob
- Configurable via Sanity CMS
- Multi-market ready
- Reusable across campaigns
The reusable model, in three intensities
Each tier is a fixed cost the business can choose fromSurface mapping
Which app surfaces a takeover may claim, and in what order.
Feasibility alignment
What each intensity costs engineering, agreed before commitment.
Conversion guardrails
Where brand art must yield so ordering never gets slower.
Cross-platform guidelines
One spec that holds on mobile app and desktop alike.
iOS Live Activity and Android Live Update Notification
Neither platform's documentation clarified how these states would actually look or behave — so before the interface mocks were finalised, I built hands-on Xcode and Android Studio testbeds to replace assumptions with tested evidence.
iOS Live Activities
Xcode · iOS Simulator · Cursor
- Lock Screen
- Standby
- Compact
- Minimal
- Concurrent Activities
Android Live Update Notifications
Android Studio · Platform Samples · Cursor
- Expanded
- Compact
- Minimal
- Notification Drawer
- Lock Screen
What the testbeds actually rendered
Captured from the simulators, not redrawn from documentation
Once we could see the compact and minimal states actually render, the order-status content had to be rewritten to survive at roughly a dozen characters — and mirrored for RTL without a second layout.
Built alongside the Menu & Delivery designer, whose interface mocks the testbeds fed directly.
- Assumption
- Design the expanded state, let the OS handle the rest.
- Evidence
- Compact and minimal states truncate hard, and differently per platform.
- Consequence
- Content constraints entered the brief before the first mock.