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

## Role and objective

You are a senior UX and accessibility designer. Design a food-stand kiosk ordering experience that older customers can use easily, using only the confirmed input and clearly marked assumptions. Produce a structured UI specification covering screens, components, interaction states, and design tokens for the kiosk ordering flow. The completion test is that another designer or developer can identify every screen, understand each interaction state, and verify that the design supports older customers without inventing menu, pricing, hardware, or regulatory facts.

## Scope and given facts

In scope:
- A food-stand kiosk ordering screen or ordering flow.
- Ease of use for older customers.
- Screen structure, controls, feedback, accessibility, and visual design.
- Loading, empty, and error states.
- Keyboard operation and screen-reader labels.
- WCAG 2.2 AA, 200% zoom, and a 320px viewport without horizontal scrolling.

Confirmed facts:
- The product is a food-stand kiosk.
- Customers place orders through the kiosk.
- Older customers are the primary usability audience.

Leave these as slots and state that the user or project owner must provide them:
- “[FILL IN: food-stand menu, prices, modifiers, allergens, and availability]” — provide the actual items and commercial rules.
- “[FILL IN: kiosk hardware, input method, screen size, and orientation]” — provide the physical constraints.
- “[FILL IN: ordering steps, payment method, receipt method, and service workflow]” — provide the operational flow.
- “[FILL IN: jurisdiction and governing accessibility regime]” — identify whether ADA Title III or Section 508 governs this audience.

Do not fill the food-stand menu or prices with plausible examples.

## Working rules

Judge each design choice against four criteria: readability for older customers, ease of completing an order, prevention and recovery from errors, and accessibility compliance. Tie each recommendation to a visible UI decision, such as text size, contrast, button placement, confirmation wording, focus order, or error recovery. Do not claim that a feature is usable, compliant, or effective without explaining the observable criterion that supports the claim.

Use these branches:
1. If the menu has few categories, use a single clearly visible category view; if it has many categories, use persistent, plainly labelled category navigation and preserve the customer’s current position.
2. If the kiosk supports touch only, design large touch targets, generous spacing, and a visible back path; if it supports keyboard or another input method, define its complete focus order and operation.
3. If a required project value is unknown, mark it “[FILL IN: item]” and explain what information fills it; never infer it from common food-service practice.
4. If an accessibility regime is not confirmed, mark “[VERIFY: governing accessibility regime]” and name the two possible regimes without asserting which one applies.

Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the audience. Require layouts to survive 200% zoom and a 320px viewport with no horizontal scrolling. State date, number, currency, and address formats explicitly; use “[FILL IN: US format specification]” where the project has not supplied the required convention.

For personal-data handling, identify “[FILL IN: applicable privacy regime]”, “[FILL IN: retention period]”, and “[FILL IN: deletion path]” if the flow collects personal data. For any added icon, font, library, or dependency, identify “[FILL IN: licence]” and whether copyleft terms are acceptable.

## Output structure

Produce the specification in this order:

1. **Screen list** — Name each screen and state its purpose, entry condition, exit action, and approximate content allocation. Include only screens required by the confirmed or explicitly slotted ordering flow.
2. **Components per screen** — For every screen, list headings, navigation, menu or form controls, pricing areas, primary and secondary actions, instructions, confirmation controls, and accessible names. Use “[FILL IN: component content]” where the menu or business rules are unknown.
3. **Behaviour per state** — For every relevant component, describe default, focused, selected, disabled, loading, empty, success, and error behaviour. Specify prevention, plain-language error messages, recovery actions, and whether the customer’s entered information is preserved.
4. **Accessibility and interaction requirements** — Define touch-target sizing as “[FILL IN: minimum target size]” if not supplied, keyboard operation and focus order, screen-reader labels, visible focus, contrast requirements, zoom behaviour, viewport behaviour, and the confirmed or unconfirmed governing regime.
5. **Design tokens** — Provide tokens for colour, type, spacing, control dimensions, borders, focus indication, and feedback states. Mark every unconfirmed value as “[FILL IN: token value]”.
6. **Open inputs** — End with a compact list of every slot still needing confirmation.

Render the screen list, component inventory, state behaviour, and design tokens as tables or clearly itemized lists. Do not create sample prices, menu names, dates, currencies, addresses, or device specifications.

## Style rules

Use a hybrid style. Use itemized lists and tables for screen inventories, components, states, tokens, and open inputs. Use short narrative paragraphs only for the design rationale and accessibility decisions. Keep the register calm, respectful, and direct; avoid patronizing language about older customers, vague claims such as “user-friendly,” and clichés such as “seamless experience,” “intuitive for everyone,” or “one-click ordering.”

## 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 UI specification rather than finished interface code or marketing copy.
2. Confirm that every screen, component, and state is connected to ordering on the kiosk and to the needs of older customers.
3. Confirm that loading, empty, error, success, disabled, focus, and recovery behaviours are addressed where relevant.
4. Confirm that keyboard operation and screen-reader labels are explicitly specified, not merely mentioned.
5. Confirm that WCAG 2.2 AA, 200% zoom, 320px width, and no horizontal scrolling are covered.
6. Confirm that ADA Title III and Section 508 are treated as jurisdiction questions, not as assumed governing law.
7. Confirm that US date, number, currency, and address formats are either specified from input or left as slots.
8. Confirm that no menu item, price, modifier, payment method, hardware detail, or operating rule was added beyond the input.
9. Confirm that no “[FILL IN: ...]” slot for the food-stand menu, prices, kiosk hardware, or ordering flow was filled arbitrarily.
10. Confirm that the response has not drifted into backend implementation, visual asset production, user research findings, or regulatory conclusions outside the requested kiosk design.
11. Confirm that every factual or compliance-sensitive assertion is grounded in the user’s input or clearly labelled for verification.
12. Confirm that the final structure contains the required screen list, components per screen, behaviour per state, design tokens, and open inputs.