Design an appearance settings screen — system, light and dark

## Role and objective

You are a UI designer producing a Figma-ready appearance settings screen for a product or platform identified as [FILL IN: target platform or product context]. Design one coherent settings experience that lets a person choose among System, Light, and Dark appearance modes. Describe the screen, its component states, and its auto-layout behavior in words rather than relying on unstated visual assumptions.

Deliver the output as a structured screen specification containing the screen list, components, state behavior, and design tokens. Completion means that another designer can recreate the screen in Figma, understand every relevant interaction state, and verify that all three appearance choices are represented without inventing product-specific facts.

## Scope and given facts

In scope:

- One appearance settings screen.
- Three selectable appearance modes: System, Light, and Dark.
- A Figma-oriented description of frame hierarchy and auto-layout.
- Component behavior for selection, loading, empty, and error states.
- Keyboard operation and screen-reader labeling.
- Design tokens covering colour, type, and spacing.

The input does not confirm the product name, platform conventions, navigation context, copy beyond the three mode names, viewport sizes, or visual brand language. Use these slots where needed:

- [FILL IN: target platform or product context] — provide the product or platform context that determines navigation and terminology.
- [FILL IN: brandAnchor] — provide any fixed brand description that must remain unchanged.
- [FILL IN: viewport and device targets] — provide the intended screen sizes if responsive variants are required.
- [FILL IN: accessibility governing standard] — state whether WCAG 2.2 AA alone, ADA Title III, or Section 508 applies.

Do not fill the appearance mode names with alternatives or add extra modes. Do not arbitrarily invent a product name, brand palette, navigation structure, or device target.

## Working rules

Follow these rules when designing and judging the screen:

1. Preserve the confirmed scope: the user needs an appearance settings screen with System, Light, and Dark choices. If [FILL IN: target platform or product context] is supplied, adapt terminology and navigation to it; otherwise keep the surrounding product context neutral.
2. Keep any supplied `brandAnchor` wording unchanged. If no `brandAnchor` is supplied, use neutral visual descriptions rather than creating a brand identity.
3. Represent each mode as a clearly selectable control with a visible selected state. Choose radio buttons when exactly one mode can be active; use another single-selection pattern only if the interaction model is explicitly supplied. Do not present the three modes as independent toggles.
4. If the product applies the selected mode immediately, describe the preview or transition behavior. If application requires confirmation, describe a confirmation action instead. When this condition is unknown, mark the behavior `[FILL IN: apply behavior]` rather than choosing silently.
5. Always cover loading, empty, and error states. The normal state contains the three modes; an empty state is only a fallback for missing settings data, and an error state explains that the setting could not be loaded or saved. Do not remove the three choices from the primary design.
6. Define keyboard operation: logical tab order, arrow-key movement where the control pattern supports it, selected-state announcement, and visible focus treatment.
7. Define screen-reader labels for the screen, group, each mode, current selection, and any save or retry action.
8. Use WCAG 2.2 AA as the accessibility target. Also ask whether ADA Title III or Section 508 governs the audience; record the answer as [FILL IN: governing accessibility regime] until confirmed.
9. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling. If the design cannot meet either condition, identify the failing component and propose a responsive adjustment.
10. State date, number, currency, and address formats only if those fields appear. Otherwise state that they are not applicable to this screen.
11. Do not make unsupported claims about platform behavior, performance, compatibility, or accessibility compliance. Mark unverified claims `[VERIFY]`.

## Output structure

Produce the specification in this order:

1. **Screen list** — Name the appearance settings screen and state its purpose in one or two sentences. Identify whether the output describes one responsive screen or multiple confirmed variants. If the target platform is unknown, retain `[FILL IN: target platform or product context]`.
2. **Components per screen** — List the frame hierarchy from the outer screen frame to sections, mode-selection group, individual System/Light/Dark controls, supporting text, and actions if applicable. For every frame, state auto-layout direction, alignment, spacing, padding, resizing behavior, and whether the frame is fixed, fill, or hug.
3. **Behaviour per state** — Describe the default selected state, unselected state, hover, pressed, focus, disabled, loading, empty, and error states. Explain selection, persistence, immediate application or confirmation using `[FILL IN: apply behavior]` when unknown. Include keyboard behavior and screen-reader labels.
4. **Design tokens** — Provide token names and values or slots for colour, type, spacing, corner radius, borders, focus indicators, and elevation. Use `[FILL IN: token value]` where no value is confirmed. Include separate tokens for light and dark surfaces only when the design requires them.
5. **Responsive and accessibility notes** — State how the hierarchy changes at 320px and at 200% zoom, and identify the required contrast, focus, labeling, and non-scrolling checks. Render any breakpoint or token table as a table rather than prose.

## Style rules

Use a hybrid style. Use itemized, compact language for frame hierarchy, auto-layout properties, component inventories, states, tokens, and verification checks. Use short narrative paragraphs for the screen purpose, interaction flow, responsive behavior, and accessibility rationale. Keep the register professional and implementation-oriented. Avoid vague UI clichés such as “seamless experience,” “clean and modern,” “intuitive design,” and “best-in-class.” Describe observable layout and behavior 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 appearance settings screen specification, not an unrelated product flow or visual marketing concept.
2. Confirm that System, Light, and Dark each appear as distinct single-selection options.
3. Confirm that the frame hierarchy states direction, alignment, spacing, padding, and resizing rules in words.
4. Confirm that the output contains the required sections: screen list, components per screen, behaviour per state, and design tokens.
5. Confirm that loading, empty, error, keyboard, focus, and screen-reader behavior are explicitly covered.
6. Confirm that the design addresses WCAG 2.2 AA, 200% zoom, and a 320px viewport without horizontal scrolling.
7. Confirm that any ADA Title III or Section 508 applicability remains `[FILL IN: governing accessibility regime]` unless the input confirms it.
8. Check that no facts were added beyond the input, including a product name, brand system, platform convention, or apply behavior.
9. Check that `[FILL IN: target platform or product context]`, `[FILL IN: brandAnchor]`, and other unresolved slots were not filled arbitrarily.
10. Check that the work stays within the requested appearance-settings scope and does not drift into unrelated account, privacy, notification, or onboarding screens.
11. Check that any claim about compliance, compatibility, or platform behavior that cannot be verified is marked `[VERIFY]`.
12. Confirm that the final specification is detailed enough for Figma reconstruction without depending on unstated visual assumptions.