Design an appearance settings screen — system, light and dark

## Role and objective

<instructions>
You are a senior UI/UX designer and accessibility-focused product designer. Design an appearance settings screen for a product whose confirmed choices are System, Light, and Dark. Produce an implementation-ready screen specification for the people responsible for product design and development.

The output form is a structured UI specification covering the screen list, components, state behaviour, and design tokens. Completion is demonstrated when each of the three appearance choices can be understood, selected, keyboard-operated, announced by a screen reader, and rendered in loading, empty, and error conditions without inventing unsupported product facts.

Before the conclusion, provide concise reasoning steps that show how you resolved the screen structure, selection behaviour, accessibility requirements, and responsive constraints.
</instructions>

## Scope and given facts

<context>
In scope:
- One appearance settings screen.
- Three appearance modes: System, Light, and Dark.
- The screen's selection and presentation behaviour.
- Accessibility, responsive layout, states, and design tokens required for implementation.

Out of scope unless explicitly supplied:
- Other settings screens.
- A particular operating system, application framework, brand identity, visual theme, user account model, persistence technology, or analytics plan.
- Product-specific claims about how “System” resolves beyond the fact that it is an available option.

Treat “system, light and dark” as the complete confirmed option set. Do not add automatic scheduling, custom themes, high contrast, or additional modes unless the user supplies them.

Unconfirmed values must remain slots:
- [FILL IN: target platform or framework] — supply the platform or design system used for implementation.
- [FILL IN: accessibility governing standard] — supply whether WCAG 2.2 AA alone, ADA Title III, or Section 508 governs.
- [FILL IN: brandAnchor] — supply the exact fixed brand description, if one exists.

Do not fill the target platform, accessibility authority, or brandAnchor arbitrarily.
</context>

## Working rules

<instructions>
1. Preserve the exact confirmed option labels: System, Light, and Dark. If the product requires explanatory text, write neutral descriptions whose facts are supplied or clearly marked [FILL IN: description].
2. Use a single-choice control when only one mode may be active. Choose radio buttons when all options are visible and mutually exclusive; choose a select control only if space or platform convention requires it, and state that condition. Do not present mutually exclusive modes as independent checkboxes.
3. Keep the selected state visibly distinct without relying on colour alone. Specify the selected indicator, focus indicator, accessible name, role, and current-value announcement.
4. Cover all required states: loading, empty, and error. If an empty state is logically impossible for a fixed three-option control, state that it is not applicable and define the fallback rather than inventing empty content. Define the error message, retry or recovery action, and whether the previous selection remains visible.
5. Specify keyboard operation, focus order, visible focus, screen-reader labels, and grouping semantics. The three choices must be reachable and selectable without a pointer.
6. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs the audience, and leave that determination as [VERIFY] unless supplied.
7. Require the layout to survive 200% zoom and a 320px viewport with no horizontal scrolling.
8. State date, number, currency, and address formats explicitly only if such fields appear; otherwise state that they are not applicable to this screen.
9. Keep the implementation target as [FILL IN: target platform or framework]. Do not infer native controls, persistence, or system APIs from the word “System.”
</instructions>

## Output structure

<output_format>
Use this order:

1. **Reasoning steps**
   - Explain the decision to use a mutually exclusive selection control.
   - Explain how System, Light, and Dark are represented without adding unsupported modes.
   - Explain the accessibility and responsive decisions.
   - Identify every unresolved slot and why it remains unresolved.

2. **Screen list**
   - List the appearance settings screen and any explicitly necessary supporting state view.
   - State the purpose of each; do not create additional screens unless an error or platform requirement makes one necessary.

3. **Components per screen**
   - Include page title, explanatory content, the mode selector, each option label, selected/unselected treatment, focus treatment, status messaging, and any action required for recovery.
   - Mark content as confirmed, provisional, or [FILL IN] where appropriate.

4. **Behaviour per state**
   - Describe loading, populated, empty-not-applicable, error, selection change, keyboard interaction, screen-reader interaction, 200% zoom, and 320px viewport behaviour.
   - Include the condition, visible result, accessible announcement, and recovery path for each relevant state.

5. **Design tokens**
   - Provide tokens for colour roles, typography, spacing, borders, radii, focus indicators, and control dimensions.
   - Use [FILL IN: token value] for values not supplied. Do not invent a brand palette.
   - State whether tokens differ between light and dark rendering, while keeping the option labels unchanged.

End with a short **Conclusion** that states whether the specification is ready for implementation and lists any blocking slots. Render state behaviour and token values as tables where this improves scanability; keep the reasoning and conclusion narrative.
</output_format>

## Style rules

Write in a hybrid style. Use concise narrative paragraphs for reasoning, design rationale, and the conclusion. Use itemized lists and compact tables for screen components, state behaviour, accessibility requirements, and design tokens. Keep the register professional and implementation-focused. Avoid vague UI clichés such as “seamless experience,” “intuitive design,” “modern look,” and “user-friendly.” Describe observable 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

<instructions>
Before delivery, run these checks and show the result:

1. Confirm that the specification contains exactly the three confirmed modes: System, Light, and Dark, with no unrequested appearance modes.
2. Confirm that the deliverable is an appearance settings screen specification rather than a complete application design or unrelated settings flow.
3. Confirm that the selected control is treated as mutually exclusive and that its interaction model is stated.
4. Confirm that loading, empty-not-applicable, and error behaviour each have an explicit treatment.
5. Confirm that keyboard operation, focus visibility, grouping semantics, and screen-reader labels are specified.
6. Confirm that WCAG 2.2 AA, the ADA Title III or Section 508 question, 200% zoom, and the 320px no-horizontal-scroll requirement are present.
7. Confirm that target platform or framework, governing accessibility authority, and brandAnchor remain slots unless supplied.
8. Check that no facts were added beyond the input, including unsupported behaviour for System.
9. Check that no slot—especially the target platform, accessibility authority, or brandAnchor—was filled with an arbitrary value.
10. Check that the work has not drifted into scheduling, custom themes, analytics, or other out-of-scope product decisions.
11. Confirm that design tokens do not contain an invented brand palette and that unspecified values use slots.
12. Confirm that the reasoning steps appear before the conclusion and that the hybrid narrative/itemized boundary is followed.
</instructions>