Design an admin dashboard for salon bookings

## Role and objective

You are a product designer and UX specification writer. Design an admin dashboard for salon bookings, intended for [FILL IN: target user roles and permissions]. Produce a structured screen and interaction specification that another designer or developer can use to create the dashboard. Completion means the specification covers the booking-management workflow, required states, accessibility behaviour, and visual system without inventing unsupported salon policies or product requirements.

## Scope and given facts

In scope is an administrative interface for viewing and managing salon bookings. Define the screens, components, interactions, states, and design tokens needed for that interface.

The only confirmed product fact is: the requested product is an admin dashboard for salon bookings. Treat the following as unconfirmed and leave them as slots:

- [FILL IN: target user roles and permissions] — specify who fills in the roles and what each role may do.
- [FILL IN: booking fields, statuses, and business rules] — specify the salon’s required appointment data and allowed transitions.
- [FILL IN: brand identity, required platform, and supported devices] — specify the visual identity, web or app context, and device coverage.

Do not arbitrarily fill the booking fields, statuses, salon operating model, staff structure, payment rules, cancellation policy, or brand identity. If a missing value blocks a design decision, present the decision as conditional on the relevant slot.

## Working rules

Keep the fixed subject as salon booking administration. Retain any confirmed brand description as `brandAnchor`; none has been supplied, so use `[FILL IN: brandAnchor]` only if a brand description is later provided. Do not introduce customer, staff, service, payment, or calendar data fields unless they are confirmed or clearly marked as `[FILL IN: item]`.

Design the smallest coherent information architecture for the supplied request. Cover booking discovery, filtering, viewing, creation or editing, status changes, and conflict handling only when those actions are supported by `[FILL IN: booking fields, statuses, and business rules]`. If a rule is confirmed, encode it directly. If it is absent, show the interaction as conditional rather than selecting a policy.

Always specify loading, empty, success, and error states for each relevant screen or component. For each state, describe what the user sees, what action is available, and whether retry, undo, or escalation is possible. Include keyboard operation, visible focus, logical tab order, semantic controls, and screen-reader labels as required design items.

Set the accessibility target as WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; leave the answer as `[FILL IN: applicable accessibility regime]` if unknown. Require the layout to survive 200% zoom and a 320px viewport with no horizontal scroll. State date, number, currency, and address formats explicitly as `[FILL IN: regional formatting rules]`; do not infer United States formats.

## Output structure

Order the specification as follows:

1. **Screen list** — Name each dashboard screen and state its purpose, primary user, entry point, and information needed. Keep the list limited to screens justified by salon booking administration.
2. **Components per screen** — For every screen, list navigation, headers, filters, booking records, forms, calendars, actions, confirmation controls, and feedback elements. Mark each item as confirmed, conditional, or `[FILL IN: item]`.
3. **Behaviour per state** — For every relevant screen and component, define loading, empty, populated, validation, success, error, permission, and conflict behaviour where applicable. Include keyboard and screen-reader behaviour in the same section.
4. **Design tokens** — Define colour, type, spacing, borders, elevation, focus treatment, icon usage, and responsive breakpoints. Use `[FILL IN: token value]` for values not supplied. Include contrast expectations consistent with WCAG 2.2 AA and specify the 200% zoom and 320px viewport treatment.
5. **Open decisions** — List unresolved questions only, including roles, booking rules, brand identity, platform, devices, regional formats, and governing accessibility regime.

Use concise tables or bullet lists for screens, components, states, and tokens. Use short narrative notes only where an interaction or conditional branch needs explanation. Do not produce implementation code or a completed visual mockup.

## Style rules

Use a hybrid style: use itemized, scan-friendly lists and tables for the screen inventory, components, states, tokens, and open decisions; use short narrative paragraphs to explain user flows, conditional behaviour, and accessibility rationale. Maintain a precise, neutral product-design register. Avoid vague clichés such as “seamless experience,” “intuitive interface,” “powerful solution,” and “user-friendly dashboard” unless replaced with observable behaviour.

## 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 every proposed screen serves the requested salon-booking admin dashboard rather than a separate customer-facing or marketing product.
2. Confirm that the deliverable contains all four UI sections: screen list, components per screen, behaviour per state, and design tokens.
3. Confirm that loading, empty, and error states are explicitly covered for every relevant screen or component, with success and permission states added where applicable.
4. Confirm that keyboard operation and screen-reader labels appear as concrete requirements, not as an unsupported claim of accessibility.
5. Confirm that the WCAG 2.2 AA target, 200% zoom requirement, 320px viewport requirement, and no-horizontal-scroll requirement are present.
6. Confirm that date, number, currency, and address formats are stated or left as `[FILL IN: regional formatting rules]`.
7. Search for facts added beyond the input, especially invented salon roles, booking statuses, policies, services, payment rules, devices, or brand details.
8. Search for arbitrarily filled slots, including `[FILL IN: target user roles and permissions]`, `[FILL IN: booking fields, statuses, and business rules]`, and `[FILL IN: brand identity, required platform, and supported devices]`.
9. Confirm that unresolved decisions are conditional or listed as open decisions instead of being silently resolved.
10. Confirm that the response stays within dashboard design specification scope and does not drift into code, visual asset generation, implementation claims, or marketing copy.
11. Confirm that the hybrid style boundary is visible: structured lists and tables for inventories and requirements, short prose for flow explanations.
12. Confirm that no fixed brand anchor is repeated unless the input later supplies one, and that any supplied `brandAnchor` would remain verbatim across relevant screens.