Cart
Each item shows what was taken out of it, and combo, drink and quantity can be edited in place. Removing an item can be undone.
Back
Independent Concept
BK Delivery Concept
A self-initiated redesign of fast-food delivery, focused on what it takes to place an order and nothing else.
This is a self-initiated study. It was not commissioned by or affiliated with Burger King, and it has not been validated with users.
The case in five words
- Problem Delivery apps put coupons, offers and pop-ups between the customer and the order.
- Decision No offers tab, coupons or unsolicited pop-ups. Attention stays on choosing food.
- Decision Take an ingredient out, keep it in the tray, and put it back before applying.
- Decision Customers check delivery to their address before giving a phone number.
- Trade-off A 3D burger costs weight and battery. A strict budget and an SVG fallback keep it usable on simpler devices.
Ordering food shouldn't feel like a sales funnel.
Delivery apps often surround the order with coupons, offers and pop-ups. My hypothesis: a flow with only what's needed to order, that runs on any phone, is a calmer and more honest experience. This is a personal point of view, not a research finding.
Directed end to end. Built with AI.
The decisions in this case are mine. Design and code were produced through a fully AI-driven workflow. Whenever the AI fell short of what I intended, I made targeted adjustments in Figma to get the result I wanted.
Less to decide. More control over what matters.
01
Leave out coupons and offers
There is no offers tab, no coupon field, no prize wheel and no unsolicited pop-up. The menu shows the product, its ingredients and its price, and the customer decides when to add it to the cart. Removing these prompts is deliberate: the flow should help people order what they came for, not push them to consume more.
02
See inside the burger, then decide
Customers open the burger to see each ingredient as a separate layer. Taking one out moves it to a tray beside the burger, where it stays until they put it back or apply the change. Nothing is final until they apply it, so changing your mind costs one tap. The model shows which ingredients are in the recipe, not exact portions.
03
Keep the 3D light enough for any phone
The 3D burger is there to explain the recipe, not to show off. Every burger is modeled by code, with no downloaded ingredient images, and the 3D part has a fixed weight and speed budget. Without WebGL, the same burger is drawn in SVG and every interaction still works. Motion is reduced when the system asks for it.
In lab tests with a 4× slower CPU, the 3D code weighed 159.5 KB gzipped and the first frame appeared in about 1.2 s. It has not been tested on physical phones.
WebGL
SVG fallback
04
Check the address before asking who you are
Customers want to know whether delivery reaches them before creating an account. The delivery address can be chosen from the menu without confirming a phone number, and the app only speaks up when it doesn't deliver to that area. The phone number comes later, at checkout.
A complete flow, simulated where it has to be.
The prototype covers the whole journey: menu, customization, cart, checkout, order confirmation and order tracking, on desktop and mobile. Maps, sign-in and payments are simulated, with fixed data, so the flow can be explored without real services.
Checkout
Checkout follows three steps: identification, address and payment, with Pix or credit card. The order summary stays visible beside each step.
Order tracking
After confirmation, the customer follows the order through each status, with the delivery window and the route from the store to the address on a map. Statuses advance on simulated timing.
Mobile
On phones, the page becomes a single column, and the main action stays fixed at the bottom of the screen.
See it for yourself.
The prototype is live. Nothing in it was tested with users, so treat it as a proposal to explore, not a proven result.
Open the prototype ↗