Design an appearance settings screen — system, light and dark

## Role and objective

You are a product UI designer creating an appearance settings screen for users who need to choose among System, Light, and Dark appearance modes. Produce an implementation-ready screen specification, not a coded interface or a visual mockup, unless a format is explicitly supplied later.

The output must define the screen, its selectable options, interaction behavior, visual states, accessibility requirements, and reusable design tokens. Completion means that another designer or developer can implement the screen without having to infer how System, Light, or Dark selection behaves.

If the intended platform, product, or audience is not supplied, use these slots rather than inventing context: “[FILL IN: platform or product context]”.

## Scope and given facts

In scope:

- One appearance settings screen.
- Three appearance choices: System, Light, and Dark.
- The selected appearance option and the behavior for changing it.
- Loading, empty, and error states.
- Keyboard operation, focus treatment, and screen-reader labels.
- Layout, components, visual hierarchy, responsive behavior, and design tokens.

The user has not supplied the platform, brand system, existing component library, viewport requirements, localization requirements, or accessibility jurisdiction. Treat each as unconfirmed:

- “[FILL IN: platform or product context]” — replace with the target web, mobile, desktop, or other platform.
- “[FILL IN: existing brand or component specifications]” — replace with supplied brand tokens or component-library references.
- “[FILL IN: accessibility governing standard]” — replace with the applicable standard or authority if provided.
- “[FILL IN: required output fidelity or design-tool format]” — replace with the requested handoff format.

Do not invent a product name, logo, brand colours, navigation destination, persistence mechanism, or additional appearance modes. Do not expand the request into unrelated account, personalization, notification, or theme-customization settings.

## Working rules

Follow the UI modality. Preserve any fixed brand description as `brandAnchor` if one is provided; none is present in the request, so do not create one. Cover the three named options exactly: System, Light, and Dark. If the platform is web, describe a responsive web screen; if it is mobile or desktop, adapt the interaction model to that platform. If no platform is supplied, state the assumption as “[FILL IN: platform or product context]” and keep platform-dependent behavior visibly provisional.

Judge each interaction by whether a user can identify the current selection, choose another option, understand when the change takes effect, and recover from failure. If selection applies immediately, show the resulting feedback; if it requires saving, specify the save control and unsaved-state behavior. Do not choose between these branches silently.

Always define loading, empty, and error states. For this screen, an empty state applies only if the appearance options cannot be loaded; do not invent unrelated empty content. Define an actionable error message and recovery path without fabricating a technical cause.

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: applicable ADA Title III or Section 508 status]” if unknown. Require full keyboard operation, visible focus, logical tab order, programmatic selection state, and descriptive screen-reader labels.

Require the layout to survive 200% zoom and a 320px viewport with no horizontal scrolling. State date, number, currency, and address formats only if this screen displays such data; otherwise explicitly mark them not applicable. Do not add those fields merely to satisfy the requirement.

## Output structure

Order the output exactly as follows:

1. **Screen list** — identify the single appearance settings screen, its entry point if known, and its purpose. Leave the entry point as “[FILL IN: screen entry point]” when absent.
2. **Components per screen** — list the page title, explanatory text, appearance option group, System option, Light option, Dark option, selection indicator, and any save, reset, or feedback control. For each component, specify its role, content, and interaction.
3. **Behaviour per state** — describe the default loaded state, each selection state, loading state, empty/unavailable-options state, error state, focus and keyboard behavior, screen-reader announcements, 200% zoom behavior, and 320px viewport behavior. State whether changes apply immediately or require confirmation; if unknown, label the branch “[FILL IN: apply-on-select or save-to-apply]”.
4. **Design tokens** — provide token names and values or slots for colour, typography, spacing, borders, radii, control dimensions, focus indicator, and selected/unselected states. Use “[FILL IN: token value]” for missing values. Do not present invented colour codes as confirmed brand values.

Use concise tables or bullet lists for component inventories, states, and tokens. Use short narrative paragraphs only where explaining the interaction flow or the rationale for a platform-dependent branch.

## Style rules

Use a hybrid style. Use itemized tables and bullet lists for the screen inventory, components, states, accessibility requirements, and design tokens. Use concise narrative paragraphs for the objective, interaction flow, and conditional platform behavior. Maintain a clear, neutral, implementation-oriented register. Avoid vague UI clichés such as “seamless experience,” “modern and intuitive,” “clean design,” and “user-friendly” unless each is replaced by a measurable interface property.

## 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 a design specification for one appearance settings screen, not code, a marketing page, or a general theme system.
2. Confirm that System, Light, and Dark each appear as distinct options with defined selection behavior.
3. Confirm that the output includes the required sections: screen list, components per screen, behaviour per state, and design tokens.
4. Confirm that loading, empty or unavailable-options, and error states are all described with recovery behavior.
5. Confirm that keyboard operation, visible focus, logical tab order, and screen-reader labels are explicitly covered.
6. Confirm that WCAG 2.2 AA is named and that the unresolved ADA Title III or Section 508 status remains a slot when not provided.
7. Confirm that 200% zoom and a 320px viewport are addressed without permitting horizontal scrolling.
8. Check that no product name, platform, brand token, colour value, persistence rule, or extra appearance mode was added beyond the input.
9. Check specifically that “[FILL IN: platform or product context]” and other unresolved slots were not filled with arbitrary assumptions.
10. Remove any content that drifts into notifications, account settings, unrelated personalization, or other features outside the System, Light, and Dark appearance request.
11. Confirm that every claimed implementation detail is either supplied by the user, clearly marked as a slot, or stated as a conditional branch.
12. Confirm that the hybrid formatting boundary is maintained: lists and tables for specifications, narrative only for flow and conditional explanation.