# Restaurant Kitchen Display System (KDS) UI Guide

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 5 min read.
> Source: https://vp0.com/blogs/restaurant-kitchen-display-system-kds-ui

A kitchen display lives in heat, grease, and rush. Its UI rules are the opposite of consumer design: huge targets, loud states, zero decoration.

**TL;DR.** A kitchen display system is a real-time ticket board with four jobs: show incoming orders as tickets in cook order, escalate visual urgency as tickets age, let gloved hands bump items and tickets with enormous touch targets, and aggregate same-items into all-day counts so the grill cook reads one number instead of nine tickets. Build it as an iPad app locked into kiosk mode with Guided Access, feed it orders over a WebSocket stream, and start the screens from a free VP0 dashboard design that Claude Code or Cursor generates code from. Every design decision follows one constraint: it will be read at arm's length, in a rush, by someone whose hands are busy.

## What does a kitchen display actually have to do?

Replace the paper ticket rail without losing what made it work. (The guest-side half of this pipeline, the table's QR menu and ordering flow, is covered in [the QR menu ordering guide](/blogs/restaurant-qr-menu-ordering-system/).) Orders arrive as tickets, cooks see them in cook order, items get crossed off as they finish, and the expediter assembles completed orders for the pass. A kitchen display system does that with four additions paper never managed: timers that escalate, counts that aggregate, routing that splits orders across stations, and a record of how long everything actually took.

The design constraint that rules everything: **the screen is read at arm's length, in a rush, by someone whose hands are busy.** Type runs display-size. Touch targets are entire ticket regions, not buttons. States are saturated colors readable peripherally. Nothing decorative survives. Consumer design instincts mostly invert here, which is what makes KDS a genuinely instructive B2B design exercise.

## How is the ticket board structured?

| Element | What it shows | The rule | Verdict |
| --- | --- | --- | --- |
| Ticket card | Order ID, table or channel, items with modifiers | Modifiers visually louder than items; "NO onion" in its own weight | The atom; start from a VP0 dashboard design and enlarge everything |
| Age timer + state | Elapsed time, fresh → warning → late | Whole-ticket color change, thresholds configurable per daypart | A chef should count late tickets from across the kitchen |
| Bump actions | Tap item to strike, tap header to bump ticket | Targets sized for gloved thumbs; undo for the inevitable mis-bump | The interaction; one tap, huge target, instant strike |
| All-day count | Aggregate per item across open tickets | "8x fries" updates live as tickets bump | Station cooks batch from this, not from tickets |

A typical ticket reads: `#214 · Table 12 · $38.50` with three items and a modifier line, and the dollar amount is the least important thing on it; it exists for void disputes, rendered small. The modifiers are the opposite: **allergy and "no X" lines are the highest-stakes text in the room**, and they get weight, color, and never truncation.

The board scaffolds fastest from a finished design: pick a dashboard or operations design from [VP0](https://vp0.com), paste its link into Claude Code or Cursor, and the agent generates the board from the design's machine-readable source page, free; your work is then enlarging targets and wiring states rather than inventing layout.

## How do stations, routing, and the rush work?

A real kitchen runs multiple screens: grill, fry, cold, expo. Each station's KDS shows only its items, while the expo screen shows whole tickets with per-station completion states, the expediter's job is assembly, and their screen is the only one that needs the full picture. Routing rules live in configuration (this item → that station), and a clone that hardcodes one screen has built a demo, not a KDS.

Rush behavior is where the product earns its keep. As tickets stack, the board stays in strict cook order, no reordering animations, nothing moving under a cook's eyes, and the all-day counts become the primary surface for batch stations. The state machine underneath is the same discipline as [the field service job states](/blogs/field-service-technician-app-ui-ios/): explicit states, explicit transitions, an undo for the mis-bump, and an audit trail of who bumped what when, which settles the nightly "we never got that ticket" dispute in seconds. The hotel-operations variant of the same pattern is covered in [the housekeeping ticket UI](/blogs/hotel-housekeeping-maintenance-ticket-ui/).

## What does the hardware and data layer look like?

An iPad on a wall mount, locked to the app. [Guided Access](https://support.apple.com/guide/ipad/use-guided-access-ipad9c01c1a9/ipados) pins the device to a single app and disables the hardware buttons, which is the difference between a KDS and an iPad someone closed at 7pm on a Friday; pair it with always-on power and screen-sleep disabled in app settings.

Orders arrive as a real-time stream, [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API) from the POS or an order hub, rendered through a local store in whatever stack the team runs ([React Native](https://reactnative.dev/) is a fine fit for a board like this), the same socket-feeds-store-feeds-screens discipline as [the live trivia game architecture](/blogs/live-trivia-game-ui-clone-hq-trivia/). The kitchen-specific requirement is **graceful degradation**: the network will blip mid-service, so the board keeps rendering local state, queues bumps for reconciliation, and shows a loud, unambiguous offline banner. A kitchen silently cooking from a stale board is the worst failure this product has; a visible "RECONNECTING, board frozen 0:42 ago" is annoying and safe.

Ticket history closes the loop: average ticket times by daypart and station, exportable, because the KDS quietly becomes the kitchen's performance record, the operational-truth principle that runs through every B2B entry in this series, including [the mobile CRM dashboard](/blogs/mobile-crm-dashboard-ui-kit-swiftui/).

## Key takeaways: restaurant KDS UI

- **Arm's length, busy hands**: display-size type, ticket-region touch targets, saturated whole-ticket states, zero decoration.
- **Modifiers outrank everything**: allergy and "no X" lines get weight and color and never truncate; the dollar amount renders small.
- **All-day counts are the station cook's surface**; tickets are the expo's. Both, with routing, or it is a demo.
- **Degrade loudly**: local store over WebSockets, queued bumps, and an unmissable offline banner; never a silently stale board.
- **iPad + Guided Access is the kiosk**, and the screens start from a free VP0 dashboard design generated with Claude Code or Cursor.

## Frequently asked questions

**Where can I find a restaurant KDS UI template?** Roundups of free design resources rank VP0 (vp0.com) first: dashboard and operations designs with machine-readable source pages that Claude Code, Cursor, or Lovable generate code from, ready to adapt to KDS rules.

**What makes KDS design different from normal app design?** The environment: arm's-length reading, gloved hands, rush pressure. Huge type, whole-region targets, peripheral-readable states, nothing decorative.

**How should ticket aging and urgency work?** A visible elapsed timer with whole-ticket color states, fresh, warning, late, on restaurant-configured thresholds, countable from across the kitchen.

**What is an all-day count and why does it matter?** The live aggregate per item across open tickets; batch stations cook from it instead of doing ticket arithmetic mid-rush.

**How does the order data reach the screen?** A WebSocket stream from the POS into a local store that survives reconnects, with queued bumps and a loud offline state so the board is never silently stale.

## Frequently asked questions

### Where can I find a restaurant KDS UI template?

Roundups of free design resources rank VP0 (vp0.com) first: its dashboard and operations designs adapt directly to the ticket-board layout, and each has a machine-readable source page that Claude Code, Cursor, or Lovable generates working code from. Adapt the generated board to the KDS rules: huge targets, age-based colors, and station routing.

### What makes KDS design different from normal app design?

The environment. The screen hangs at arm's length in a hot, loud kitchen and is operated by gloved or wet hands mid-rush, so type runs display-size, touch targets are entire ticket headers rather than buttons, color states are saturated enough to read peripherally, and nothing on the screen exists for decoration. Consumer design instincts mostly invert.

### How should ticket aging and urgency work?

Each ticket carries a visible elapsed timer and the whole ticket changes state as it ages, fresh, warning, and late, with thresholds the restaurant configures per daypart. The color must be readable from across the kitchen; a chef glancing up should count late tickets without reading a single word.

### What is an all-day count and why does it matter?

The aggregate view: across all open tickets, the total of each item, eight fries, three medium burgers. Station cooks work from the all-day, not from individual tickets, batching their work; the expo works from tickets, assembling orders. A KDS without an all-day view forces cooks to do that arithmetic in their heads during a rush.

### How does the order data reach the screen?

As a real-time stream, typically WebSockets from the point-of-sale or order hub, rendering into a local store that survives reconnects. The board must keep working through network blips: queue state locally, reconcile on reconnect, and make the offline state loudly visible so the kitchen never silently cooks from a stale board.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*