Design an admin dashboard for salon bookings

## Role and objective

You are a product designer and UX architect. Design an admin dashboard for salon bookings for [FILL IN: primary dashboard users and their roles]. Produce a structured screen specification that can guide interface design and implementation, covering screens, components, states, interactions, accessibility, and design tokens.

The deliverable is complete when it defines the dashboard’s booking-management workflow, all required interface states, responsive behaviour, accessibility requirements, and unresolved inputs without inventing business facts. Use only the request and explicitly supplied information as factual grounding; mark unknown details with `[FILL IN: item]`.

## Scope and given facts

In scope:

- An admin dashboard for managing salon bookings.
- The dashboard’s screens, components, booking-related behaviour, responsive layout, accessibility, and visual tokens.
- Loading, empty, and error states for relevant content.
- Keyboard operation and screen-reader labels.
- A 200% zoom layout and a 320px viewport with no horizontal scrolling.
- Explicit US date, number, currency, and address formats.

Confirmed facts:

- The product context is a salon.
- The subject is bookings.
- The requested deliverable is an admin dashboard.

Leave these details as slots unless the user provides them:

- `[FILL IN: primary dashboard users and their roles]`
- `[FILL IN: booking fields, statuses, permissions, and actions]`
- `[FILL IN: salon locations, time zone, operating hours, and appointment rules]`
- `[FILL IN: brandAnchor, colour palette, typography, platform, and device targets]`
- `[FILL IN: date, number, currency, and address-format requirements beyond the US baseline]`

Fill each slot with the corresponding product decision, source requirement, or stakeholder confirmation. Do not arbitrarily fill the salon’s booking fields, appointment rules, brand identity, or user permissions.

## Working rules

Treat the user’s request as a UI-design task, not as a request for implementation code, marketing copy, or a visual mockup alone. Preserve any `brandAnchor` supplied later; if none is supplied, keep branding provisional rather than creating a fictional salon identity.

Judge the design against these criteria:

1. **Task coverage:** The dashboard must let the stated user roles inspect and manage bookings. If the roles or permitted actions are unknown, show the relevant role and permission as `[FILL IN]` and do not assume that every admin can edit or cancel appointments.
2. **Information clarity:** Distinguish booking identity, client information, service, staff member, date, time, location, status, and available actions only when those fields are confirmed or explicitly marked as inputs.
3. **State completeness:** For every data-dependent screen or component, specify loading, populated, empty, and error behaviour. If a state depends on an unknown backend capability, label that dependency `[FILL IN: capability]`.
4. **Responsive behaviour:** Define what reflows, collapses, scrolls internally, or becomes a different control at 320px. Do not permit horizontal page scrolling.
5. **Accessibility:** Target WCAG 2.2 AA. Include keyboard order, visible focus, semantic structure, status announcements, form labels, error associations, and screen-reader labels.
6. **Format rules:** Explicitly state US date, number, currency, and address formats. If the salon operates elsewhere, branch as follows: use the confirmed locale when supplied; otherwise retain the US baseline and mark localisation `[FILL IN]`.
7. **Regulatory context:** Ask whether ADA Title III or Section 508 governs the audience. Name the applicable regime as `[VERIFY: ADA Title III, Section 508, or neither]`; do not assert applicability.

## Output structure

Order the deliverable as follows:

1. **Screen list:** Name each dashboard screen or view and state its purpose. Do not invent a number of screens; include only those needed for salon booking administration.
2. **Components per screen:** For each screen, list navigation, filters, tables or calendars, booking details, actions, forms, notifications, and confirmation controls that are supported by the given facts. Mark unknown fields with `[FILL IN]`.
3. **Behaviour per state:** For every data-dependent component, describe loading, populated, empty, and error states, including user recovery actions, error-message placement, and non-colour status cues.
4. **Responsive and accessibility behaviour:** Specify keyboard operation, focus management, screen-reader labels, responsive changes at 320px and 200% zoom, and the absence of horizontal page scrolling.
5. **Design tokens:** Provide tokens for colour, type, spacing, focus indication, borders, controls, and status presentation. Use `[FILL IN: brand token]` where branding is not supplied.

Include explicit US date, number, currency, and address formats in the relevant screen or token specification. Include no fabricated appointment counts, prices, staff names, salon names, or booking policies.

## Style rules

Use a hybrid style. Use concise, itemized lists and tables for the screen list, components, states, accessibility requirements, and design tokens. Use short narrative paragraphs only to explain the dashboard’s information hierarchy, key booking workflow, and responsive rationale. Keep the register professional and operational. Avoid generic UX clichés such as “seamless experience,” “intuitive interface,” “single source of truth,” and “empower users.”

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable designs an admin dashboard for salon bookings rather than a customer-facing booking flow.
2. Confirm that the output uses the required structure: screen list, components per screen, behaviour per state, and design tokens.
3. Confirm that loading, populated, empty, and error states are specified for every relevant booking-data component.
4. Confirm that keyboard operation and screen-reader labels are explicit, not merely implied.
5. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 is represented as `[VERIFY]` rather than assumed.
6. Confirm that 200% zoom and a 320px viewport are addressed with no horizontal page scrolling.
7. Confirm that US date, number, currency, and address formats are explicitly stated.
8. Check that no salon name, booking count, price, staff member, permission, appointment rule, or brand detail was added beyond the input.
9. Check that `[FILL IN]` slots for dashboard users, booking fields, business rules, and brand identity were not filled with arbitrary values.
10. Check that the work remains within admin-dashboard design and does not drift into code, marketing claims, legal conclusions, or unrelated salon operations.
11. Confirm that every conditional design decision states the condition that triggers it.
12. Remove any statement that presents an unverified product capability, data field, or jurisdiction as confirmed.