Design an admin dashboard for salon bookings

## Role and objective

<instructions>
You are a product designer and UX architect. Design an admin dashboard for salon bookings for [FILL IN: intended users]. Produce a concise but implementable screen and interaction specification, not finished software or visual mockups. First provide your reasoning steps, showing how each requested dashboard element follows from the confirmed facts and identified user tasks; then provide the final design specification.

The completion test is that a designer or developer can identify the screens, components, states, keyboard behaviour, screen-reader labels, and design tokens without having to infer missing requirements. Do not present assumptions as facts. If the dashboard’s purpose, platform, or booking workflow is not confirmed, preserve it as a slot and identify the decision needed.
</instructions>

## Scope and given facts

<context>
Confirmed input: the requested product is an admin dashboard, and its subject is salon bookings.

In scope:
- the dashboard’s screen list;
- booking-management components and interactions;
- loading, empty, and error states;
- keyboard operation and screen-reader labels;
- responsive and accessible presentation;
- design tokens for colour, typography, and spacing.

Out of scope unless explicitly supplied: implementation code, database design, backend architecture, payment processing rules, staff payroll, marketing copy, customer-facing booking flows, and visual brand decisions not contained in the input.

Use these slots for unconfirmed requirements:
- [FILL IN: target device and platform] — fill with the intended device class and operating environment.
- [FILL IN: primary salon workflows] — fill with the booking tasks and administrative actions the dashboard must support.
- [FILL IN: brandAnchor] — fill with the existing brand description, or state that no fixed brand description was provided.
- [FILL IN: booking data fields] — fill with the fields actually available for each salon booking.
- [FILL IN: user roles] — fill with the administrator and staff permissions.

Do not fill the salon’s primary workflows, booking data fields, user roles, or brandAnchor with plausible examples. Use only user-provided facts or clearly marked requirements to confirm.
</context>

## Working rules

<instructions>
Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the intended audience; leave the applicable answer as [FILL IN: governing accessibility regime] until confirmed. Require the layout to remain usable at 200% zoom and at a 320px viewport without horizontal scrolling. State date, number, currency, and address formats explicitly; use [FILL IN: format] where the salon’s formats are unknown.

Judge every proposed component against a concrete salon-booking task: finding a booking, viewing its status, creating or editing it, cancelling or rescheduling it, and identifying the responsible staff member, but retain these as required task checks rather than claiming they are confirmed business requirements. If [FILL IN: primary salon workflows] excludes a task, remove that task from the final flow. If the dashboard is web-based, specify responsive web behaviour; if another platform is confirmed, adapt the interaction model to that platform.

Include loading, empty, and error states for every data-dependent area. Define recovery behaviour, including what the user can retry, undo, or correct. Specify keyboard order, visible focus, shortcut behaviour if any, and accessible names for controls, status messages, tables, filters, and dialogs. Do not invent booking counts, appointment statuses, staff names, prices, dates, or customer details.

Keep confirmed facts separate from recommendations. If a design choice depends on an unconfirmed role, permission, data field, or workflow, label it [FILL IN] rather than selecting one silently. Preserve any supplied brandAnchor exactly; if none is supplied, do not create one.
</instructions>

## Output structure

<output_format>
Return the work in this order:

1. **Reasoning steps** — a brief numbered explanation linking the confirmed subject, “salon bookings,” to each proposed dashboard area. Identify unresolved decisions and their effect on the design. Do not expose hidden chain-of-thought; provide concise design rationale only.
2. **Screen list** — name each screen and state its purpose. Include only screens justified by the confirmed or explicitly required workflows.
3. **Components per screen** — list navigation, booking views, search and filters, forms, tables or calendars, status indicators, dialogs, and action controls. For each, state its data, action, and accessibility label requirement.
4. **Behaviour per state** — for each screen or data-dependent component, define normal, loading, empty, error, validation, success, and permission-denied behaviour when applicable. Include keyboard operation, screen-reader announcements, focus handling, and recovery actions.
5. **Responsive and accessibility requirements** — explain the 200% zoom and 320px viewport behaviour, no-horizontal-scroll constraint, WCAG 2.2 AA target, and the unresolved ADA Title III or Section 508 question.
6. **Design tokens** — provide tables for colour, typography, spacing, borders, focus indicators, and status treatments. Use [FILL IN: token value] for unconfirmed brand or system values.
7. **Open decisions** — list the missing inputs that must be confirmed before implementation.

Use tables where comparison or token definitions benefit from columns. Do not populate unknown salon data with placeholder-looking factual values.
</output_format>

## Style rules

Use a hybrid style. Write the reasoning, scope decisions, and state descriptions in short narrative paragraphs; write screens, components, requirements, tokens, and verification items as compact numbered lists or tables. Use a clear product-design register. Avoid generic dashboard clichés such as “seamless experience,” “single source of truth,” “powerful insights,” and “intuitive interface” unless you define the observable behaviour they refer to. Prefer concrete labels, actions, states, and acceptance conditions.

## 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 is an admin dashboard specification for salon bookings, not code, a customer-facing booking page, or a marketing document.
2. Confirm that the reasoning steps appear before the final design specification and remain concise design rationale rather than hidden chain-of-thought.
3. Check that every screen and component supports a confirmed fact or an explicitly marked salon-booking workflow requirement.
4. Check that loading, empty, and error states are covered for every data-dependent screen or component.
5. Check that keyboard operation and screen-reader labels are specified for navigation, booking controls, forms, filters, tables, dialogs, and status messages.
6. Check that WCAG 2.2 AA, the 200% zoom requirement, and the 320px no-horizontal-scroll requirement are present.
7. Check that the question of whether ADA Title III or Section 508 governs the audience remains identified and unfilled.
8. Check that date, number, currency, and address formats are explicit or left as named slots.
9. Check that no booking counts, customer details, staff names, statuses, prices, dates, platform, workflows, roles, or brandAnchor were added beyond the input.
10. Check specifically that [FILL IN: target device and platform], [FILL IN: primary salon workflows], [FILL IN: booking data fields], [FILL IN: user roles], and [FILL IN: brandAnchor] were not filled arbitrarily.
11. Check that the output does not drift into implementation code, backend architecture, payroll, marketing, or customer-facing booking design.
12. Check that the final sections follow the required order and use the tags <instructions>, <context>, and <output_format>.
13. Check that the writing uses the declared hybrid style and avoids undefined dashboard clichés.
14. Check that tables contain structures and requirements, not invented salon values.