What this prompt does
This prompt makes the model act as a senior product designer and frontend engineer, then asks it to design a restaurant table reservation flow and return working component code rather than screen descriptions. The instruction to ship code is what separates it from a wireframe brief — you get something you can drop into a project and refine. Three variables steer the result: [restaurant_type] sets the tone and constraints (an upscale bistro behaves differently than a fast-casual spot), [stack] decides the component idiom, and [booking_constraint] injects a real rule like "90-minute table turns, max party of 8 online" so availability logic reflects the venue.
The deliverables are ordered so the user never backtracks: date, party size, and time slot first, then seating preference, dietary notes, the availability heat-map, and confirmation. That ordering matters because reservation flows fail when availability is hidden until the final step. By demanding the heat-map and a graceful "no tables" fallback with alternatives, the prompt surfaces scarcity early and treats the dead-end screen as a real, designed state.
When to use it
- Building a reservation widget for a restaurant or venue from scratch
- Replacing a flow where users only discover "no availability" at the last step
- Encoding a real booking rule via
[booking_constraint]such as turn times or party caps - Designing the dietary-restrictions input so the kitchen can actually act on it
- Prototyping an availability heat-map that shows open versus busy at a glance
- Generating starter component code for a
[stack]your team already uses
Example output
You get the reservation flow as component code — the ordered inputs, the seating and special-requests fields, the dietary selector, the heat-map calendar, and a confirmation step with add-to-calendar and a modify/cancel path — followed by a short note on how state moves between steps. It also includes validation, loading states, and the "no tables" fallback rendered as a first-class screen with suggested alternative times rather than an error message.
Pro tips
- Fill
[booking_constraint]with a concrete rule; "90-minute turns, max party of 8 online" produces far better availability logic than leaving it generic. - Push the heat-map early so guests pick a time that actually exists — that is the single biggest conversion lever in reservation UIs.
- Treat the "no availability" state as a designed screen with suggestions, not a dead end; that is where bookings get saved.
- Set
[restaurant_type]precisely so the seating options and tone match the venue. - If the returned code is too monolithic, ask the model to split the heat-map and the info form into separate components.
- Make the dietary selector structured (checkboxes plus a free-text note) so the kitchen receives data it can act on, not prose.
