What this prompt does
This prompt casts the model as a senior product designer who specifies a full appointment booking widget tightly enough to hand straight to a developer. It forces named steps, their inputs, and their error states, so the output is a buildable flow spec rather than vague screen talk. The structure works because it ties every decision to three context variables: [business_type] sets the domain language (a salon books staff differently than a clinic), [stack] decides whether you get React patterns or framework-agnostic notes, and [constraints] keeps the design inside real limits like "must embed on a Squarespace site, mobile-first."
The deliverables run in booking order — service selection, staff, date/time, customer info, deposit, confirmation — which is what stops the model from drifting into a generic CRUD form. Because each step demands its own validation and empty/error state, the answer covers the parts most teams skip: the timezone-aware slot picker, the deposit total with a refund policy, and the embeddability notes for iframe versus script embeds.
When to use it
- Scoping a booking widget for a service business before any code is written
- Embedding a scheduler into a no-code host like Squarespace or Wix where
[constraints]matter - Auditing an existing booking flow for missing error and empty states
- Aligning a designer and developer on step order and required fields
- Planning timezone and availability logic before it becomes a production bug
- Adapting the same flow across different
[business_type]clients
Example output
You get a step-by-step flow specification: each step named, with its inputs listed, the inline validation rules, and the explicit empty/error state for that step. It reads like a build ticket — service-selection fields, the staff "any available" option, the timezone-detecting slot grid, the deposit breakdown, and a confirmation screen with add-to-calendar, reschedule, and resend-confirmation actions — plus a short embeddability section on theming tokens and slow-network loading states.
Pro tips
- Make
[constraints]specific — "mobile-first, embeds on Squarespace, no third-party cookies" yields far sharper output than a blank or generic value. - Get the timezone handling right first; an automatic-detection bug books the wrong slot and erodes trust faster than any other defect.
- Set
[business_type]precisely so the model uses the right vocabulary for services, staff, and durations. - If
[stack]is React, ask in a follow-up for component names and prop shapes to turn the spec into scaffolding. - Treat the deposit step as optional in the prompt, but always demand the refund/cancellation copy so the total is never ambiguous.
- Iterate one step at a time when a flow gets long — ask the model to expand only the date/time picker rather than regenerating everything.
