What this prompt does
This prompt generates a screen-by-screen food delivery UI spec covering all seven stages of the order journey: home discovery, restaurant listing, menu browsing, dish customization, cart, checkout, and live order tracking. It also outputs working framework code for the restaurant menu component with sticky category navigation and cart integration — so you leave with a spec and a runnable starting point.
The template enforces the opinionated design rules that separate well-converting food apps from clunky ones: warm appetite-stimulating color palettes, dominant food photography, bold typography for dish names, and minimal friction between hunger and order confirmation.
What makes it structurally sound is the embedded anti-pattern list. It explicitly bans the four most damaging failure modes in food delivery UX: slow browsing from improperly lazy-loaded images, delivery fees hidden until checkout, over-engineered filter systems, and removing cart items without a confirmation step. These are not generic UX advice — they are the specific conversion killers in this vertical, baked out of the spec by default.
The [framework] variable ties the visual spec to working code. Fill it with your actual stack and you get a scaffolded sticky-category-nav menu component rather than wireframe descriptions you still have to translate.
When to use it
- Building an MVP food delivery frontend and needing a coherent screen-to-screen flow before touching Figma or code.
- Auditing an existing delivery app against industry patterns to identify where users are dropping off.
- Presenting a pitch or client demo where you need realistic, detailed UI copy and component structure fast.
- Writing a design brief for a contractor and needing concrete layout and interaction requirements, not vague "make it look like Uber Eats."
- Exploring how platform type changes the UI — aggregator, single-brand chain, and ghost kitchen each produce meaningfully different home screen hierarchies from the same template.
Example output
Home screen:
- Location bar (top, sticky): "Delivering to: 42 King Street v"
- Search: "Search for restaurants or dishes..."
- Cuisine scroll: Pizza . Sushi . Burgers . Healthy . Mexican
- Featured card (Nando's): [hero photo] 4.7 stars . 18-28 min . 0 delivery fee . 1.2 km
Restaurant menu (sticky nav):
Starters | Mains | Sides | Drinks | Desserts
[Starters section active, scrolled into view]
Dish card — Peri-Peri Chicken Burger:
Photo (16:9) . "Flame-grilled, peri-peri glazed, brioche bun" . 11.50
[Add to Cart] -> fly-to animation, cart badge increments +1
Pro tips
- Set
[delivery_promise]to something specific ("under 30 min or free") rather than generic — the prompt uses it to calibrate how ETA is displayed on the tracking screen and in the checkout summary. Vague values produce vague output. - For
[platform_type], distinguish between aggregator (multi-restaurant), single-brand (one restaurant chain), and ghost kitchen (no physical storefront) — each changes the home screen hierarchy significantly. - If you want the tracking screen to include driver contact options, add "in-app chat and call masking" to
[features]explicitly. The template generates the tracking map by default but omits contact UI unless specified. - Pair this prompt with your actual payment SDK documentation as a second context block when generating the checkout screen — the tip selection component needs real rounding logic, not placeholder values.
- Run the color recommendations through your component library's token system before coding. The warm palette (reds, oranges) frequently conflicts with an existing brand palette — resolve that mapping once at the spec stage rather than per-component.
