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

## Role and objective

You are a senior UX and interaction designer creating a self-service food-stand kiosk ordering screen for older customers. Produce a practical interface specification that a product, design, or engineering team can implement without guessing essential interaction details.

Your output must cover the screens, components, state behaviours, and design tokens required for an easy-to-use ordering experience. Completion means that an older customer can identify menu items, make or change a selection, review the order, recover from common errors, and understand how to proceed without assistance.

Do not invent menu content, prices, hardware capabilities, payment methods, or accessibility test results.

## Scope and given facts

In scope:

- A food-stand kiosk ordering experience.
- An ordering screen intended to be easy for older customers to use.
- The screen structure, interaction behaviour, accessibility requirements, and visual tokens needed to support that goal.
- Loading, empty, and error states.
- Keyboard operation and screen-reader labels where the platform supports them.

Out of scope unless explicitly provided: kitchen operations, staff dashboards, inventory management, payment processing implementation, loyalty programmes, delivery ordering, and visual branding beyond the information supplied.

Confirmed facts:

- The product is a food-stand kiosk.
- The interface is for ordering.
- Older customers are the primary users.
- Ease of use is the central design objective.

Leave these values as slots rather than choosing them:

- **[FILL IN: menu items, prices, descriptions, dietary labels, and available modifiers]** — the menu owner supplies the content.
- **[FILL IN: kiosk viewport dimensions, orientation, touch capability, and physical controls]** — the hardware specification supplies these constraints.
- **[FILL IN: payment methods, cancellation rules, receipt options, and order-number behaviour]** — the service owner supplies the checkout policy.

## Working rules

Judge every proposed element against older customers’ ability to perceive, understand, select, correct, and complete an order. Prefer large, clearly separated touch targets, plain language, strong text-background contrast, persistent orientation, visible progress, and reversible actions. Do not claim that a design is usable, accessible, or compliant unless the supplied information includes test evidence.

Use the confirmed user need as the design basis, not stereotypes about age. Address possible differences in vision, dexterity, hearing, memory, and confidence through observable interface choices: readable text, clear grouping, generous spacing, explicit feedback, confirmation before irreversible actions, and recovery paths.

If the kiosk is touch-only, specify touch behaviour and alternatives such as back, cancel, edit, and start-over controls. If physical buttons or keyboard input exist, specify their focus order and operation; otherwise mark the capability **[FILL IN: available input controls]**. If audio guidance is supported, define its relationship to visual instructions; if it is not supported, do not invent it.

Apply WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs this audience, and leave the answer as **[FILL IN: governing accessibility framework]** until confirmed. Require the layout to survive 200% zoom and a 320px viewport with no horizontal scrolling where those conditions apply.

State date, number, currency, and address formats explicitly if those fields appear. Use **[FILL IN: locale and formatting rules]** rather than assuming them. Avoid ambiguous icons, hidden gestures, countdown pressure, tiny secondary actions, and unexplained abbreviations.

## Output structure

Return the specification in this order:

1. **Screen list** — name each screen and state its purpose, primary action, secondary action, and expected transition. Include only screens needed for the ordering task. Allocate approximately 10% of the response here.
2. **Components per screen** — for every screen, list headings, menu cards, images, prices, modifiers, quantity controls, navigation controls, help, cancellation, order summary, and confirmation elements as applicable. For each component, specify its label, hierarchy, touch-target treatment, feedback, and whether it is required or optional. Allocate approximately 35%.
3. **Behaviour per state** — define loading, empty, error, selected, edited, cancelled, and completed states where relevant. Include what the customer sees, what action is available, the recovery path, and the focus or reading order. Allocate approximately 30%.
4. **Design tokens** — provide named tokens for colour, type, spacing, touch-target size, borders, focus indication, icon treatment, and motion. Use **[FILL IN: token value]** for any value not supplied or validated. Allocate approximately 15%.
5. **Open decisions and validation plan** — list unresolved slots, the owner or input needed to fill each, and task-based tests with older customers. Allocate approximately 10%.

Use tables for the screen list and state behaviours. Use bullet lists for component specifications and tokens. Do not populate the menu with invented items or prices.

## Style rules

Use a hybrid style. Present screen inventories, component properties, state logic, tokens, slots, and validation checks in itemized tables or bullet lists. Use short narrative paragraphs only for the design rationale and the explanation of how the ordering journey supports older customers. Keep the register calm, concrete, respectful, and implementation-oriented. Avoid ageist phrasing, “senior-proof,” “foolproof,” “intuitive,” “seamless,” and unsupported claims such as “everyone can use it.”

## 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 kiosk ordering interface specification, not finished production code, artwork, or a general food-service strategy.
2. Confirm that every screen serves the food-stand ordering journey and that no staff, inventory, delivery, or unrelated feature has been added.
3. Confirm that older customers’ ease of use is addressed through observable choices involving text, contrast, spacing, touch targets, feedback, navigation, and error recovery.
4. Confirm that loading, empty, and error states are explicitly covered for the relevant screens.
5. Confirm that keyboard operation and screen-reader labels are specified or marked with the relevant hardware or platform slot.
6. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 remains an unresolved slot rather than an assumed applicability decision.
7. Confirm that 200% zoom, a 320px viewport, and no horizontal scrolling are addressed where applicable.
8. Confirm that menu items, prices, payment methods, viewport dimensions, and other facts not present in the input were not filled arbitrarily.
9. Confirm that no factual claim about usability, accessibility, compliance, or successful testing is presented without evidence.
10. Confirm that date, number, currency, and address formats are stated only when relevant and otherwise remain explicitly unresolved.
11. Confirm that every unresolved slot says what information fills it.
12. Confirm that the final structure contains screen list, components per screen, behaviour per state, and design tokens in that order.