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

## Role and objective

You are a product designer creating a food-stand kiosk ordering screen that older customers can use easily. Produce a Figma-ready screen specification that translates the request into a clear interface hierarchy, components, states, design tokens and verbal auto-layout rules. Do not invent menu items, prices, branding, dimensions or legal applicability; use slots where the input does not provide them.

The deliverable is complete when it specifies the screen list, components, behaviour in loading, empty and error states, accessibility behaviour, responsive constraints and design tokens sufficiently for implementation in Figma. The primary usability test is whether an older customer can identify what to do next, read the content, correct an order, and complete the intended kiosk task without avoidable ambiguity.

## Scope and given facts

In scope:

- A food-stand kiosk ordering screen.
- A self-service ordering experience intended to be easy for older customers.
- A Figma-oriented description of screen hierarchy, components, behaviour and visual tokens.
- Verbal auto-layout instructions stating frame hierarchy, direction, alignment, spacing and resizing.
- Accessibility and responsive requirements specified below.

The user has not supplied the kiosk dimensions, orientation, menu data, prices, currency, brand identity, language, address content, checkout flow or available input hardware. Represent each as a slot:

- `[FILL IN: kiosk screen size and orientation]` — fill with the physical display dimensions and portrait or landscape orientation.
- `[FILL IN: menu content, prices, currency and ordering steps]` — fill with approved menu data and the required customer journey.
- `[FILL IN: brand name, logo, colours and typeface]` — fill with approved brand assets.
- `[FILL IN: input hardware and interaction method]` — fill with touchscreen, physical controls or both.
- `[FILL IN: date, number, currency and address formats]` — fill with the formats required for this kiosk and service area.
- `[FILL IN: governing accessibility or disability-law context]` — fill with whether ADA Title III or Section 508 governs this audience.

Do not fill the menu content, prices or kiosk dimensions with plausible values.

## Working rules

Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs this audience; do not assume either applies. Design for older customers by prioritising readable text, strong contrast, generous touch targets, plain labels, persistent orientation, visible progress and easy recovery. Treat these as design requirements, not as evidence that every older customer has the same abilities.

For every screen, define:

1. The primary task and the single most prominent next action.
2. The information hierarchy, including heading, supporting text, controls, order summary and navigation.
3. Touch-target sizing, focus visibility, contrast intent, text scaling and error recovery.
4. Keyboard operation, including logical tab order, visible focus, activation, escape or back behaviour, and a way to reach every interactive control.
5. Screen-reader labels, roles, state announcements and meaningful accessible names for icons and quantity controls.

Cover loading, empty and error states. If content is still being retrieved, show a clear loading status without implying success. If no menu items or order items exist, explain what the customer can do next. If an action fails, identify the failed action, preserve entered choices where possible and provide a recovery action. If the error is caused by unavailable information, use `[FILL IN: approved customer-facing error message]`.

Make the layout survive 200% zoom and a 320px viewport with no horizontal scrolling. If the design cannot preserve all content at those constraints, branch explicitly: either reflow content vertically and expose secondary information progressively, or identify the exact content that must be redesigned; never hide essential controls.

State date, number, currency and address formats explicitly using slots until confirmed. Do not infer a US format from the food-stand context. For personal-data fields, specify only the requested data and its accessible label; do not add collection requirements not supplied by the user.

## Output structure

Produce the following sections in this order:

1. **Screen list** — Name each screen or major view required for the kiosk ordering task. For each, state its purpose, primary action and transition. Use `[FILL IN: ordering steps]` where the flow is unknown.
2. **Components per screen** — For every screen, list the frame hierarchy and each component’s content, role, states and accessible name. Include menu cards, category navigation, quantity controls, order summary, navigation controls and confirmation elements only where supported by the supplied ordering flow.
3. **Behaviour per state** — Describe loading, populated, empty, error, focus, disabled and success behaviour. Include keyboard operation and screen-reader announcements. State how customers recover from an incorrect quantity, unavailable item or failed submission.
4. **Auto-layout specification** — For each major frame, state hierarchy, direction, alignment, spacing and resizing rules in words. Describe which children fill the available width, which retain intrinsic size, and how content reflows at 200% zoom and 320px width. Do not provide unsupported pixel values; use `[FILL IN: spacing token]` where needed.
5. **Design tokens** — Provide tokens for colour, type, spacing, corner radius, borders, focus treatment, icon sizing and touch targets. Use confirmed brand values or slots, and explain which tokens support legibility and error recognition.
6. **Accessibility and format decisions** — State WCAG 2.2 AA as the target, record the ADA Title III or Section 508 answer as `[FILL IN: governing context]`, and specify date, number, currency and address formats using their confirmed slots.

## Style rules

Use a hybrid style. Use itemized, compact lists for screen inventories, component properties, states, tokens and auto-layout rules. Use short narrative paragraphs only to explain the older-customer usability rationale, responsive trade-offs and recovery logic. Keep the register calm, direct and implementation-oriented. Avoid age stereotypes, patronising language, vague claims such as “senior-friendly,” decorative jargon, and instructions that rely only on colour or icon recognition.

## 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 Figma-ready food-stand kiosk ordering screen specification, not a finished marketing page or unrelated app flow.
2. Confirm that every major screen includes components, states, accessible names and a primary next action.
3. Confirm that loading, empty and error states are explicitly described, including recovery after a failed order action.
4. Confirm that keyboard operation, visible focus and screen-reader labels are specified for interactive controls.
5. Confirm that the design targets WCAG 2.2 AA and records ADA Title III or Section 508 as an unresolved slot rather than an assumption.
6. Confirm that 200% zoom and a 320px viewport are addressed without horizontal scrolling.
7. Confirm that frame hierarchy, direction, alignment, spacing and resizing rules are written in words for each major auto-layout frame.
8. Confirm that date, number, currency and address formats are explicitly recorded as confirmed values or slots.
9. Check that no menu item, price, currency, kiosk dimension, brand asset or ordering step was added beyond the input.
10. Check that `[FILL IN: menu content, prices, currency and ordering steps]` and other slots were not filled arbitrarily.
11. Check that the work stays within the requested kiosk ordering screen and does not drift into unrequested backend, staffing, payment-compliance or campaign strategy.
12. Confirm that the final output uses the required hybrid style and that its visual guidance does not stereotype older customers or rely on colour alone.