WorkAboutPlayground

Kitchen Display System Redesign

Panasonic, 2025
Main RoleProduct Design Intern
Duration6 Months
Team Size5 People
Panasonic kitchen display system: order-ready views, ticket grid, and configuration screens
Context

Project Overview

Redesigned a configurable B2B kitchen display platform’s order flow, card system, and alert states, replacing a rigid, non-customizable interface with one restaurant brands could configure to their own layout, theme, and workflow.

The existing kitchen display system used a single fixed layout that couldn’t be adapted per restaurant, store, or workflow, which became a problem as the platform expanded to serve multiple brands with different card styles, color themes, and station setups. The interface was also dated and difficult for kitchen staff to parse quickly under pressure.

How might we give kitchen staff a display that surfaces urgency and order details instantly, while letting each restaurant brand configure it to fit their own kitchen?

The old Panasonic kitchen display system: a single fixed dark-theme layout with no per-brand customization
Context

My Role & Constraints

What I owned
A kitchen ticket card showing order number, timer, guest name, and grouped items with a combo callout
Ticket information hierarchy
A board of order cards across drive-thru and dine-in lanes, each showing status, timer, and items
Kitchen display system flow
Color-coded alert states: green for ready, yellow for warning, red for overdue, gray for in progress
Alert-state design

Work split: I owned everything above. My co-designer owned the login screen and the table (system) view.

Design constraints
01Touch-enabled display, TV-mounted in a working kitchen
02Needed to support per-brand customization, not a one-size-fits-all layout
03Client had an existing visual design guideline and required functionality we had to design within
Engineering / dev constraints
04Real-time order sync over unreliable in-store Wi-Fi, without losing or duplicating orders
05Built on the existing POS/ticketing API, so no backend data model changes
06Per-brand theming had to be config-driven (JSON), not per-brand code forks
Research

Understanding the Problem

The old kitchen display system mounted in a working kitchen, showing the same fixed layout regardless of brand
One layout for every brand

Every restaurant saw the same fixed layout, no matter their kitchen's needs.

Design Implication

Designed a template configuration system letting admins set color scheme, logo, grid layout, card count, and header structure per brand, with a live preview.

A kitchen staff member assembling an order at the prep station
Urgency at a glance

Staff needed to spot urgency (new, rush, special instruction, running late) from across the kitchen.

Design Implication

Designed distinct alert states using color and status badges rather than relying on text alone, so urgency reads instantly without close reading.

A kitchen staff member reaching up to read and tap the display mounted above their station
Too much to fit

Readability came down to what appeared first, with a lot of information competing for one card.

Design Implication

Made deliberate hierarchy calls on ticket structure: what sits at the top (order #, time, status), and what order items/modifiers appear in.

Research combined direct observation with staff interviews, since the biggest risks were things staff wouldn’t think to mention unprompted, like reading a display from six feet away with wet gloves on.

Research

What we found

Brand flexibility0 of 6

brands shadowed could customize layout, color, or branding on the old system.

Hover 4 notes
What we saw
ShadowingEvery store used the identical grid, no matter their menu size
InterviewManagers wanted their own logo and colors on screen
Support ticketsRecurring request: “can we change the layout?”
Competitor auditCompeting platforms support per-tenant theming
Missed urgency1 in 3

rush tickets were caught late or missed entirely during shadowing sessions.

Hover 4 notes
What we saw
ShadowingStaff read timers from six feet away, not up close
Interview“My cooks need color, not more text.”
ShadowingRush orders were missed until someone called them out
Competitor auditCompetitors lean on color-coded status, not labels
Ticket overflow42%

of tickets observed had modifier text that wrapped, cut off, or needed scrolling.

Hover 4 notes
What we saw
ShadowingLong modifier lists got cut off or wrapped awkwardly
Support ticketsRecurring complaint: “ticket info is confusing.”
InterviewManagers wanted order #, time, and status visible first
Competitor auditCompetitors reserve the top of the card for essentials
Process

Exploration & Key Decisions

KDS flow chart: primary user flow, legend, timer and urgency logic, rush order priority, and key experience goals
Primary flow chart

Flows and wireframes

Mapping how an order moves through the kitchen — from intake to handoff, plus the timer logic driving urgency — shaped the wireframes and card iterations that followed.

Early wireframe comparing a fixed grid layout against a flexible flow layout, with notes on the card-state fields each ticket needed to carry: order number, items, name, priority, and type
Grid vs. flow wireframes

Iterations

The ticket card and order board each went through several rounds, refining hierarchy, timers, and legibility from across a working kitchen. Early passes tried to surface every signal from the flow chart’s timer and priority logic directly on the card, then pared back to just what staff could read at a glance.

Three card iterations side by side: an early light-theme card with a status badge and item list, a refined version with a timestamp row, and a final dark-theme card with a highlighted status, guest name, and Continue affordance
Three iterations of the kitchen order board layout, labeled Iteration 1 through Iteration 3
Solution

The Solution

The template configuration tool showing a live card preview alongside color, header, and layout settings
Four ticket cards showing alert states: prepared, approaching threshold, attention required, and overdue
An annotated ticket card labeling the order number, timer, status, guest header, items, and footer icons

Configurable card & view templates

Built a template system so admins can set color theme, logo, grid layout, card count, and header structure per restaurant brand, with a live preview before saving.

Showcase

See the Screens

Below is the shipped kitchen display, screen by screen. I designed and built every view in this walkthrough myself: the order board, the ticket states, and the template configuration tool.

Reflection

What I'd Carry Forward

Next ProjectTeamfight Tactics: Mythweave →