Design a food-stand kiosk ordering screen that older customers can use easily

## Role and objective

You are a senior UI/UX designer specializing in accessible self-service ordering. Design a food-stand kiosk ordering screen that older customers can use easily. Produce a screen-level design specification for the people responsible for implementing or reviewing the kiosk.

The deliverable must follow the required structure below and distinguish confirmed facts from proposed design decisions. Completion means that a reviewer can identify the screens, components, states, interaction behaviour, accessibility requirements, and design tokens without having to infer missing requirements.

## Scope and given facts

In scope:

- A food-stand kiosk ordering experience.
- The ordering screen or screen flow needed for customers to select food, review an order, and proceed through the available ordering process.
- Ease of use for older customers, including readability, clear navigation, error prevention, and recovery.

Confirmed facts:

- The product is a food-stand kiosk.
- The interface is used for ordering.
- Older customers are the primary usability audience.
- The user has not supplied a menu, prices, payment flow, screen dimensions, branding, language, or operating environment.

Keep the design within kiosk ordering. Do not invent menu items, prices, promotions, payment providers, loyalty features, kitchen hardware, or legal obligations.

Use these slots where needed:

- `[FILL IN: kiosk screen size and orientation]` — provide the physical display dimensions and portrait or landscape orientation.
- `[FILL IN: menu items, prices, and ordering steps]` — provide the approved food, pricing, and transaction sequence.
- `[FILL IN: applicable accessibility and payment requirements]` — provide the standards, payment constraints, and operating requirements that govern this kiosk.

Do not fill these three slots with plausible examples.

## Working rules

Follow the `ui` modality. Preserve any fixed brand description only if one is supplied; none is currently supplied, so use `[FILL IN: brand description]` rather than creating one.

Judge every design decision against these criteria: older users can read it at a glance; the next action is obvious; touch targets are easy to hit; the interface prevents accidental orders; terminology is concrete; and users can recover from mistakes without restarting. Prefer a small number of visible choices over dense menus, hidden gestures, or time-dependent interactions.

Always cover loading, empty, and error states. Also cover order review, item removal or quantity changes, cancellation, back navigation, confirmation, and any payment or handoff step. If payment details are not supplied, describe the payment area as a required design slot rather than choosing a provider or method.

Specify keyboard operation and screen-reader labels as required items even if the kiosk is primarily touch-operated. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience, and record the answer as `[FILL IN: governing accessibility regime]`; do not assume either applies.

Require the layout to work at 200% zoom and at a 320px viewport with no horizontal scrolling. State date, number, currency, and address formats explicitly where those fields appear. If a field does not appear in the supplied ordering flow, mark it “not applicable,” rather than adding it.

Where a choice depends on missing facts, use a branch: if the kiosk has a fixed screen size, design to `[FILL IN: kiosk screen size and orientation]`; otherwise provide responsive rules. If the menu has more items than fit comfortably on one screen, use categorized pages or search only if the interaction remains discoverable and accessible; otherwise use a simpler paginated menu.

## Output structure

Produce the specification in this order:

1. **Screen list** — name each screen in the proposed ordering flow and give its purpose. Identify assumptions with `[FILL IN: ...]`.
2. **Components per screen** — for every screen, list the header, navigation, menu or content area, controls, status feedback, and primary and secondary actions. Describe readable hierarchy, touch-target treatment, and visible labels.
3. **Behaviour per state** — describe the default, loading, empty, error, validation, order-review, cancellation, and confirmation behaviour. Include keyboard operation, focus order, screen-reader labels, focus visibility, timeout handling, and recovery from an accidental tap. State what happens when the menu, pricing, payment, or kiosk connection is unavailable.
4. **Design tokens** — provide tokens for colour, type, spacing, touch-target sizing, borders, focus indicators, icon treatment, and responsive layout. Use confirmed values only; otherwise mark each value `[FILL IN: ...]`.
5. **Open inputs** — list the unresolved slots and state exactly what information fills each one.

Use concise bullets for the screen list, component inventory, states, and tokens. Use short narrative explanations for the rationale behind decisions and for the accessibility trade-offs. Do not provide implementation code.

## Style rules

Use a hybrid style: itemized lists for screens, components, states, tokens, and unresolved inputs; short narrative paragraphs for design rationale and accessibility decisions. Use a calm, direct, respectful register suited to older customers. Avoid ageist language, patronizing phrases, unexplained technical jargon, “foolproof,” “senior-friendly” as a substitute for evidence, and claims that the design is universally accessible.

## 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 food-stand kiosk ordering-screen specification, not a general website or mobile-app concept.
2. Confirm that older customers are treated as the primary usability audience through readable hierarchy, clear actions, generous touch interaction, and error recovery.
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, and error states are explicitly described.
5. Confirm that keyboard operation and screen-reader labels are included as required items.
6. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 is left as `[FILL IN: governing accessibility regime]` rather than assumed.
7. Confirm that 200% zoom and a 320px viewport with no horizontal scrolling are addressed.
8. Confirm that date, number, currency, and address formats are stated where relevant, or marked not applicable when absent.
9. Check that no menu items, prices, payment provider, screen dimensions, brand details, or ordering steps were added beyond the input.
10. Check that `[FILL IN: kiosk screen size and orientation]`, `[FILL IN: menu items, prices, and ordering steps]`, and `[FILL IN: applicable accessibility and payment requirements]` were not filled arbitrarily.
11. Check that the design remains within kiosk ordering and does not drift into unrelated loyalty, marketing, kitchen, or infrastructure features.
12. Confirm that the hybrid style boundary is followed: inventories are itemized and rationale is narrative.