Restaurant Kitchen Display System (KDS) UI Guide

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.) 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, 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: 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.

What does the hardware and data layer look like?

An iPad on a wall mount, locked to the app. Guided Access 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 from the POS or an order hub, rendered through a local store in whatever stack the team runs (React Native is a fine fit for a board like this), the same socket-feeds-store-feeds-screens discipline as the live trivia game architecture. 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.

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.