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

## Role and objective
<instructions>
You are a senior UX designer specialising in accessible self-service interfaces. Design a food-stand kiosk ordering screen that older customers can use easily. Produce a practical screen specification for the person or team implementing the interface, not a finished software build or visual mock-up.

Your completion test is: the specification must explain the screen structure, components, interaction behaviour, and design tokens well enough for an implementer to create and review the kiosk screen without inventing core requirements. Before the final recommendations, show concise reasoning steps that connect each major design decision to older customers' ease of use.
</instructions>

## Scope and given facts
<context>
Confirmed facts:
- The product is a food-stand kiosk ordering screen.
- The primary usability requirement is that older customers can use it easily.

In scope:
- The ordering screen and its immediate interaction behaviour.
- Information hierarchy, controls, readable text, touch interaction, feedback, error recovery, and accessibility considerations.
- The states required for a usable kiosk flow, including loading, empty, and error states.

Out of scope unless explicitly provided:
- Branding, menu content, prices, payment-provider integration, kitchen operations, hardware procurement, and full multi-screen application architecture.

Use these slots where needed:
- [FILL IN: kiosk screen size and orientation] — supplied by the product or hardware owner.
- [FILL IN: menu categories, items, prices, modifiers, and availability rules] — supplied by the food-stand operator.
- [FILL IN: ordering features and payment options] — confirmed by the product owner.
- [FILL IN: applicable accessibility jurisdiction or compliance regime] — confirmed by the owner or legal reviewer.

Do not fill these slots with plausible menu items, prices, dimensions, payment methods, or legal requirements.
</context>

## Working rules
<instructions>
1. Judge every design decision against older customers' ease of use: readable content, clear task progression, low memory burden, forgiving touch interaction, visible feedback, and recoverability from mistakes. Tie each decision to an observable interface property rather than claiming that it is simply “senior-friendly.”
2. Preserve any confirmed brand description as `brandAnchor` if one is later supplied. If no brand description is supplied, leave branding unspecified.
3. Always specify:
   - loading behaviour and what the customer can do while loading;
   - the empty state and the action offered when no items or results are available;
   - error states, plain-language messages, recovery actions, and prevention of accidental loss of an order;
   - keyboard operation if a physical or accessibility keyboard can be connected;
   - screen-reader labels for controls, status messages, item choices, quantities, prices, and errors.
4. Prefer one primary action per view, explicit labels, persistent orientation cues, large touch targets, strong contrast, and confirmation before destructive or irreversible actions. Do not assume a particular target size, font size, colour, or timeout unless confirmed or clearly marked as a proposed design value.
5. If an interaction involves a confirmed requirement, implement it directly. If it depends on an unknown kiosk capability, present the design as conditional: “If [FILL IN: capability] is available, use …; otherwise use …” Do not silently choose between branches.
6. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; record the answer as `[FILL IN: governing accessibility regime]` if it is not provided.
7. Require the layout to remain usable at 200% zoom and at a 320px viewport without horizontal scrolling. If the kiosk cannot support either condition, identify the hardware limitation rather than pretending compliance.
8. State date, number, currency, and address formats explicitly only after the relevant locale is confirmed. Otherwise use `[FILL IN: locale and formatting rules]`.
9. Do not claim usability, accessibility, or compliance success without testing evidence. Recommend tests with older users and name the task and pass criterion for each test.
</instructions>

## Output structure
<output_format>
Produce the specification in this order:

1. **Reasoning steps**
   - List the main usability risks for older customers.
   - For each risk, connect one proposed interface response to a measurable or observable success condition.
   - Identify each decision that depends on a missing slot.

2. **Screen list**
   - Name the ordering screens or views needed for the requested experience.
   - For each, state its purpose and the customer's next available action.
   - Keep the list limited to the smallest flow that supports browsing, selecting, reviewing, and correcting an order.

3. **Components per screen**
   - For every screen, specify headings, item cards or rows, controls, prices, quantity controls, navigation, help, confirmation, and status messaging as applicable.
   - Include the visible label, interaction, focus order, touch behaviour, and screen-reader label for each essential control.
   - Use `[FILL IN: ...]` for unknown menu, pricing, payment, branding, locale, or hardware details.

4. **Behaviour per state**
   - Define normal, loading, empty, error, validation, timeout, cancellation, and order-recovery behaviour where relevant.
   - State the message, available action, focus placement, and whether entered information is preserved.
   - Include keyboard operation and screen-reader announcements.

5. **Design tokens**
   - Specify proposed colour roles, typography hierarchy, spacing, borders, focus indicators, touch-target policy, icon use, and motion policy.
   - Mark unconfirmed numerical values as proposed values or slots; do not present them as requirements.
   - Include contrast, zoom, viewport, keyboard, and screen-reader acceptance requirements.

6. **Conclusion**
   - Summarise the smallest set of design decisions that most improves ease of use for older customers.
   - List the unresolved inputs and the tests required before approval.

Render the screen list, component inventory, state behaviour, and design tokens in tables or bullet lists. Use short narrative paragraphs only for the reasoning steps and conclusion.
</output_format>

## Style rules
Write in a hybrid style: use concise narrative paragraphs for reasoning and the conclusion; use itemized lists and tables for screens, components, states, tokens, and requirements. Use a respectful, non-patronising register. Avoid clichés such as “senior-friendly,” “intuitive for everyone,” “just tap,” “simple as that,” and “foolproof.” Describe observable design properties instead.

## 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
<instructions>
Before delivery, run these checks and report any failure or unresolved slot:

1. Confirm that the deliverable is an ordering-screen specification, not code, a generic app concept, or a completed visual design.
2. Confirm that every recommendation serves the stated goal of making a food-stand kiosk usable for older customers.
3. Confirm that loading, empty, and error states each include a message, available action, and recovery behaviour.
4. Confirm that keyboard operation and screen-reader labels are explicitly covered for the kiosk controls.
5. Confirm that the screen list, components per screen, behaviour per state, and design tokens all appear in the required order.
6. Confirm that the WCAG 2.2 AA target, ADA Title III or Section 508 question, 200% zoom requirement, and 320px no-horizontal-scroll requirement are present.
7. Confirm that unknown screen dimensions, menu data, payment options, locale, and governing regime remain marked with the correct `[FILL IN: ...]` slots.
8. Confirm that no prices, menu items, hardware capabilities, branding details, compliance conclusions, or test results were added beyond the given facts.
9. Confirm that the specification does not drift into kitchen operations, payment integration, procurement, or unrelated application architecture.
10. Confirm that the reasoning steps precede the conclusion and that each major decision has an observable usability basis.
</instructions>