POS Order Experience

ROLE

Product Designer

DURATION

6 Months

SCOPE

System Design · Multi-Device · Core Execution Experience

AI Agent · Review Management ·Manager App Redesign

TL;DR

See It Live

See It Live

This project is not about making ordering faster.

It is about protecting a core execution experience from system complexity as the POS ecosystem grows.

The Order Screen was designed to remain predictable, portable, and resilient under real operational pressure—without transferring complexity to frontline staff.

Context

The POS ordering is an execution chain, not a screen:

The Order Screen It’s an Execution Chain, Not a Screen

The Order Screen It’s an Execution Chain, Not a Screen

  • The Device Matrix

Ordering must remain stable across multiple execution surfaces.

  • The Fulfillment Chain

Each action on the Order Screen carries downstream operational consequences.

  • The Responsibility Boundary

The Order Screen is where ownership and intent transfer across roles.

This is where the order screen must remain dependable.

This is where the order screen must remain dependable.

This is where the order screen must remain dependable.

Challenge.

Outside of training or demos, the ordering experience rarely feels problematic.

The friction emerges under peak conditions—busy shifts that recur two to three days every week.

In these moments, the system is not being evaluated for learnability or feature completeness.

It is stressed as an execution core—operating across devices, roles, and shifting responsibility boundaries, while the surrounding POS ecosystem continues to grow.

What surfaces as “hard to use” is not a single usability flaw,
but the accumulation of small, invisible costs that compound under pressure.

The challenge was not to improve usability in isolation, but to protect a stable ordering core that remains dependable as the system evolves.

Outside of training or demos, the ordering experience rarely feels problematic.

The friction emerges under peak conditions—busy shifts that recur two to three days every week.

In these moments, the system is not being evaluated for learnability or feature completeness.

It is stressed as an execution core—operating across devices, roles, and shifting responsibility boundaries, while the surrounding POS ecosystem continues to grow.

What surfaces as “hard to use” is not a single usability flaw,
but the accumulation of small, invisible costs that compound under pressure.

The challenge was not to improve usability in isolation, but to protect a stable ordering core that remains dependable as the system evolves.

Outside of training or demos, the ordering experience rarely feels problematic.

The friction emerges under peak conditions—busy shifts that recur two to three days every week.

In these moments, the system is not being evaluated for learnability or feature completeness.

It is stressed as an execution core—operating across devices, roles, and shifting responsibility boundaries, while the surrounding POS ecosystem continues to grow.

What surfaces as “hard to use” is not a single usability flaw,
but the accumulation of small, invisible costs that compound under pressure.

The challenge was not to improve usability in isolation, but to protect a stable ordering core that remains dependable as the system evolves.

Insights.

These insights define what the execution core cannot depend on, expose, or demand as complexity grows.

No Exploration

Under pressure, staff rely on recognition and habit. Execution must be immediately recognizable.

No Exploration

Under pressure, staff rely on recognition and habit. Execution must be immediately recognizable.

No Exploration

Under pressure, staff rely on recognition and habit. Execution must be immediately recognizable.

Intent Gating

Ordering, fulfillment, and payment share one surface but not the same intent. Structure should be revealed selectively.

Intent Gating

Ordering, fulfillment, and payment share one surface but not the same intent. Structure should be revealed selectively.

Intent Gating

Ordering, fulfillment, and payment share one surface but not the same intent. Structure should be revealed selectively.

Spatial Stability

Repetition amplifies physical inconsistency.
High-frequency actions must remain spatially stable.

Spatial Stability

Repetition amplifies physical inconsistency.
High-frequency actions must remain spatially stable.

Spatial Stability

Repetition amplifies physical inconsistency.
High-frequency actions must remain spatially stable.

Solutions.

Decision 1: Separating Task Models for QSR and FSR

Ordering operates under different execution constraints.

We separated entry-level task models while reusing a shared menu structure.

  • Quick Service (QSR): Optimized for fast completion under peak load

  • Full Service (FSR): Optimized for coordination through iteration and shared state

The logic:

A shared menu preserves muscle memory, while the system adapts the workflow to different service models.

Different task models. One shared execution core.

Decision 2: Contextual Structural Stealth

A system-level order has many layers (Transactions, Checks, Seats, Courses). However, not all data deserves user attention at all times.

  • Principle: Reveal structure only when it affects the next action.

  • The Solution: Financial structures (checks/transactions) are deferred until the payment phase. The Order Screen remains focused on the execution unit—the items. This keeps cognitive load low when the kitchen is screaming for tickets.

A system-level order has many layers (Transactions, Checks, Seats, Courses). However, not all data deserves user attention at all times.

  • Principle: Reveal structure only when it affects the next action.

  • The Solution: Financial structures (checks/transactions) are deferred until the payment phase.

    The Order Screen remains focused on the execution unit—the items. This keeps cognitive load low when the kitchen is screaming for tickets.

Decision 3: Preserving Muscle Memory Across Devices

Handhelds and terminals engage different muscles—but they share the same human brain.

We prioritized spatial consistency to preserve muscle memory across arm-driven and finger-driven interaction.

Core actions remain positionally stable across devices, allowing users to switch mid-shift without cognitive or physical reorientation.

trade-offs.

  • Performance Over Discovery

We optimized for high-frequency actions. Low-frequency actions may require a learning curve.

  • Predictability Over Flexibility

We constrained certain combinations to prevent high-cost errors (e.g., accidental check closures).

  • Expert Efficiency Over First-time Ease

The system favors the staff member who places 500 orders a day over the minimal UI screen.

reflection.

Complexity will always grow—but human capacity does not. This project reinforced my belief that designing operational systems is about deciding what the system should carry so the human doesn't have to.

The Order Screen remains viable not because it is feature-rich, but because it respects the physical and cognitive limits of the people behind the counter.

echo.

"Ordering just flows.
We don’t have to think about it during service."

"Ordering just flows.
We don’t have to think about it during service."

Front-of-House Staff

more to explore.

Show More

Show More

Show More

WJW