What this prompt does
This prompt has the AI act as a senior product designer and frontend engineer building a patient appointment booking flow, and it demands real component structure and states rather than vague UX notes. It defines five steps: choose a reason for visit, pick a provider with a specialty filter, choose a slot in a calendar, run an insurance check, and confirm with an estimated cost and a telehealth option. The [provider_count] placeholder sizes the directory, [slot_length] sets calendar granularity, and [insurance_source] names how coverage is verified.
The structure works because healthcare booking adds real stakes, so the prompt forces failure states into every step. It requires loading, empty, error, and no-availability states throughout, since the no-availability and empty states are where users give up. The reason-for-visit step filters what comes next, the insurance check returns a clear covered/not-covered result, and the [stack] variable keeps the components and state list mapped to your framework. By making the reason for visit drive who and what appears downstream, the flow narrows choices instead of dumping the full provider directory on the patient, which keeps a 40-provider list from feeling overwhelming at the first decision point.
When to use it
- Designing a patient booking flow for a clinic or healthcare app
- Filtering across a directory sized by
[provider_count]and specialties - You need a slot calendar at a specific
[slot_length]granularity - Adding an insurance eligibility check via
[insurance_source] - Surfacing estimated cost and a telehealth option at confirmation
- Designing no-availability and error states for every booking step
Example output
You get the step flow, the components, and the state list, fenced and copy-ready. Each step is laid out in order: reason for visit, provider with specialty filter, slot calendar at your chosen granularity, insurance check with a covered/not-covered result, and confirmation showing estimated cost and a telehealth toggle per slot. Every step enumerates its loading, empty, error, and no-availability states with accessible labels.
Pro tips
- Set
[provider_count]realistically; it shapes whether the provider step needs heavy filtering or a simple list - Match
[slot_length]to your scheduling system so the calendar reflects true availability - Name your real
[insurance_source]so the covered/not-covered result maps to your eligibility flow - Don't skip the state work: ask the model to design the no-availability and empty states first, since that is where users abandon
- Keep
[stack]accurate so the components and state list are buildable - If the reason-for-visit filtering feels shallow, ask it to show how step one narrows the providers and slots downstream
- Have it spell out the covered vs not-covered messaging from
[insurance_source]clearly, since an ambiguous coverage result is a common source of post-booking disputes
