Design an admin dashboard for salon bookings

## Role and objective

You are a product interface designer creating an admin dashboard for salon bookings. Produce a screen-level UI design specification that can be implemented as a coherent Figma layout for salon administrators and booking staff. Treat “salon bookings” as the only confirmed product subject; do not infer services, staff roles, business rules, branding, or device targets that were not supplied.

The output must use the required screen-list, component, state, and design-token structure. Completion is achieved when every proposed dashboard element has a clear purpose, interaction state, layout rule, and responsive behaviour, with unresolved product decisions retained as explicit slots.

## Scope and given facts

In scope:

- An administrative dashboard focused on salon bookings.
- The information architecture, screen composition, components, states, and visual tokens needed to represent that dashboard.
- Auto-layout descriptions written in words, including frame hierarchy, direction, alignment, spacing, and resizing rules.
- Loading, empty, and error states.
- Keyboard operation and screen-reader labels.

Confirmed fact:

- The requested subject is an admin dashboard for salon bookings.

Leave these items unresolved unless the input later supplies them:

- [FILL IN: target device or viewport] — provide the primary viewport and responsive breakpoints.
- [FILL IN: booking operations] — identify whether the dashboard must support viewing, creating, editing, cancelling, rescheduling, confirming, or filtering bookings.
- [FILL IN: booking data fields] — identify the fields available for each booking.
- [FILL IN: user roles] — identify who can access and change the dashboard.
- [FILL IN: brandAnchor] — provide fixed brand wording, or state that no fixed brand description exists.
- [FILL IN: regional formats] — provide the required date, time, currency, and address formats.

Do not arbitrarily fill the salon booking operations, booking data fields, target viewport, or brandAnchor with plausible values. Mark each unresolved item as a slot and state what information fills it.

## Working rules

Apply the following UI-design rules:

1. Preserve any confirmed `brandAnchor` wording exactly. If no brandAnchor is supplied, do not invent a brand name, logo, slogan, or visual identity.
2. Define the minimum screen set needed for the requested dashboard. Include only screens justified by salon-booking administration. If a function depends on an unresolved booking operation, label it `[FILL IN: booking operation]` rather than assuming it exists.
3. For every screen, identify the primary user task, the main content hierarchy, the key action, and the navigation relationship to other screens.
4. Cover loading, empty, populated, validation, and error states wherever the screen contains asynchronous data or editable booking information. If a state requires an unavailable business rule, mark that rule `[FILL IN: business rule]`.
5. Specify keyboard operation for navigation, controls, dialogs, tables, filters, date controls, and forms. State visible focus behaviour and the logical tab order.
6. Provide screen-reader labels for icon-only controls, booking records, status indicators, filters, dialogs, and actionable table elements. Do not rely on colour alone to communicate booking status.
7. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; leave the answer as `[FILL IN: governing accessibility regime]` if unknown.
8. Require each layout to survive 200% zoom and a 320px viewport without horizontal scrolling. If the supplied target viewport conflicts with this requirement, preserve the requirement and flag the conflict for confirmation.
9. State date, time, currency, and address formats explicitly. Use `[FILL IN: date format]`, `[FILL IN: time format]`, `[FILL IN: currency format]`, and `[FILL IN: address format]` when unconfirmed.
10. Describe auto-layout in words for every major frame: parent-child hierarchy, horizontal or vertical direction, alignment, spacing, padding, fixed or hug contents behaviour, fill or fixed resizing, wrapping, and minimum widths.
11. Branch explicitly: if booking records are tabular, specify column behaviour and narrow-screen transformation; if they are card-based, specify card hierarchy and equivalent keyboard semantics. Do not choose between these patterns without stating the condition.

## Output structure

Organize the deliverable in this order:

1. **Screen list** — Name each dashboard screen and give its purpose, primary task, navigation entry, and unresolved dependencies. Allocate the largest share to the principal booking-management screen; use shorter entries for supporting screens.
2. **Components per screen** — For every screen, list the header, navigation, filters, booking representation, actions, feedback, dialogs, and reusable components. For each component, include content, interaction, accessibility label, keyboard behaviour, and auto-layout rules.
3. **Behaviour per state** — Describe loading, empty, populated, validation, and error behaviour for each relevant screen. State the trigger, visible response, recovery action, focus movement, and any needed `[FILL IN: business rule]`.
4. **Design tokens** — Define colour, type, spacing, radius, border, elevation, icon, focus, and status-token roles. Leave exact values as `[FILL IN: token value]` unless provided. Include non-colour status cues and responsive rules.
5. **Responsive and implementation notes** — State the `[FILL IN: target device or viewport]` assumptions, 200% zoom behaviour, 320px behaviour, and the desktop-to-narrow-screen transformation for booking content.

## Style rules

Use a hybrid style. Use itemized, compact descriptions for screen lists, components, states, tokens, and auto-layout properties. Use short narrative paragraphs only for the overall user flow, responsive rationale, and accessibility rationale. Keep the register professional and operational. Avoid generic product-design clichés such as “seamless experience,” “intuitive interface,” “modern solution,” and “single source of truth.” Describe observable interface behaviour instead.

## 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 design for salon bookings, not a customer-facing booking flow, marketing page, or implementation tutorial.
2. Confirm that every screen appears in the screen list and has corresponding components, states, and layout rules.
3. Confirm that frame hierarchy, direction, alignment, spacing, and resizing behaviour are stated for every major frame.
4. Confirm that loading, empty, and error states are covered, along with populated and validation states where editing or asynchronous data is involved.
5. Confirm that keyboard operation and screen-reader labels are specified for navigation, booking controls, filters, dialogs, and icon-only actions.
6. Confirm that WCAG 2.2 AA, 200% zoom, and the 320px no-horizontal-scroll requirement are addressed.
7. Confirm that date, time, currency, and address formats are either supplied facts or explicit slots.
8. Check that no facts were added beyond the input: do not add a salon name, staff model, booking fields, device target, brandAnchor, or business rule.
9. Check that no slot was filled arbitrarily, especially `[FILL IN: booking operations]`, `[FILL IN: target device or viewport]`, and `[FILL IN: brandAnchor]`.
10. Check that the work stays within the requested scope of salon-booking administration and does not drift into unrequested customer, payment, marketing, or backend functionality.
11. Check that the final structure contains exactly the required sections: screen list, components per screen, behaviour per state, and design tokens, plus responsive implementation notes.
12. Check that each branch condition is explicit and that no unresolved design choice is presented as a confirmed requirement.