Kitchen Order Reprioritization

Designing a way for restaurant kitchens to have flexibility with sorting and rushing their orders


Toast, Inc. is a cloud-based restaurant software company based in Boston, Massachusetts. The company provides a restaurant management and point of sale system built on the Android operating system. I designed easy to use and intuitive experiences for the point of sale and the kitchen display screen, used by servers and kitchen staff respectively; helping them complete complex day to day tasks in the restaurant in a smooth and simple way. I also worked on the web experience for the Toast backend to enable owners/manager to configure their restaurant on Toast.


The Problem

It's a busy day for a restaurant, the kitchen is slammed with orders during lunch rush when suddenly...

Actual footage of me in the wild

There's a table with a hungry child and flustered parents who need their food ASAP. Or maybe a customer has an emergency and needs their food right away. The kitchen needs to rush the order and move to the front of the line. Take another similar scenario - what if the kitchen needs to sort their orders by course or by table number to improve their efficiency?

In short - how can kitchens reprioritize their tickets as needed to handle rush cases and maximize efficiency?


I researched restaurant needs behind sorting and prioritizing their kitchen orders, which contributed to realigning the product roadmap to match user needs, and designed a way to give them flexibility over their tickets.


Using research insights, I uncovered the user's real needs - which led to a pivot in the product roadmap, saving the team's resources in building a feature that was not what the user desired

Using my engineering background, I understood technical limitations and worked closely with the engineering team to product designs within those constraints

The Team

1 product designer/researcher (me!) + 1 product manager + 1 engineering lead

Toast Kitchen Display Screen

Order Ticket
Tickets are ordered by oldest to newest

Each box is a 'ticket', representing an order that has been rung in from the point of sale - by oldest to newest. The colour and information on the header of the ticket can be configured - typically restaurants configure the colour to change depending on how long a ticket has been waiting - green at first, then orange and red as the wait progresses.

Actions available for an order

Based on different configurations for the kitchen system, there are different workflows to mark an order as ‘done’/fulfilled once the kitchen staff has finished preparing it and it is ready for the customer. Spoiler alert: This info is relevant later on!

Selecting an order and choosing to mark it as done on the top right
Selecting an order and having a dialog popup for further actions, including marking it done

Feature Asks

The two feature requests customers put in were related, so I combined the research for them to save the team's time and resources.

'Rush' Order ►

Marking an order on the kitchen display screen as a ‘rush’ or urgent order

Order sorting ►

Arranging orders according to table number, courses, dine-in/takeout and other factors

Exploring the problem

Feature Requests

Going through 90 feature requests in Salesforce which detailed the problem, desired workflow, and current workarounds in place

Competitive Analysis

Explored the user manuals, and demos of 9 KDS systems to find rush/sort features offered by 5 of them

Discovery Research

Interviews conducted with 6 restaurant owners/managers to learn what they are looking for when they talk about sorting kitchen tickets, and also about expected behavior when a kitchen ticket is marked as a "rush" order, and if there is any overlap with requests between the two features.

  • Customers essentially want flexibility in moving tickets.
  • Restaurants overall try to prioritize orders for their guests who are physically in the restaurant over others.
  • Restaurants try to avoid rush orders, but they come up sometimes - either if there’s an error in an order or a guest turns up early to pick up their food.

“The impact a rush order would have on our kitchen - it would take up their attention, they are going to have to switch gears, drop what they are working on and try to complete the fly order thrown at them. It throws a wrench in their gears and hurts productivity”

—Bird’s, Durango CO

Rushing tickets was a rare occurence, but it did occur. Sorting tickets is not really what restaurants wanted - overall they wanted to use their digital kitchen display screen with the same flexibility as that of a physical paper ticket rail.

“It would be nice to have the dragging, moving, organization, prioritize or manipulation of the tickets in real time. Maneuvering tickets would give us flexibility.”

—Eggroll Cafe, Lowell MA

Concept Ideation

Drag & Drop

I built a flow for how dragging and dropping tickets might work on the Android tablet application.

I played around signifiers and feedback to clearly indicate the drag and drop interaction. The additional challenge was designing for a touch tablet surface and not desktop. I looked at apps like Google Keep, and non visual signifiers like haptic feedback.

Tilting a ticket on long press - similar to Trello
Ticket enlarged on long press
Border around a ticket to indicate it is being dragged - like Google Keep

The engineering team worked on building a quick proof of concept to check the feasibility, and I along with the team evaluated the technical feasibility of the feature.

Pros ►

Action is visible and immediate
Mimics real life interaction

It is not accessible
Technically challenging
Imperfect & imprecise
Re-rendering the screen each time was a huge computational load
Given the large number of tickets, there would be a long horizontal scroll on the screen


Given the problems with this, I rephrased the problem.

How might we design an alternative that functionally fulfills the user need while being technically feasible?

Design Alternatives

Instead of drag and drop, I designed dialogs and actions to move tickets in a more controlled way. This supported the most common use cases customers had - for example: rushing a ticket to the front of the screen and other specific use cases.

Dialog allowing the user to directly move the ticket either to the front, or back of the queue, or by a set number of spaces
A joystick-esque approach where a ticket could be selected and could be moved one space front or back, or sent straight to the front or back of the queue [think layers in Sketch/Photoshop!]

Visual Indication of Ticket Change

If a ticket moved, it had to indicate the change to other users looking at the KDS at the same time. Based on user research, I came up with these alternatives.

The colour of the whole ticket - not header - changes
Message on the ticket header indicating it has been rushed
Ticket flashes upon move until acknowledged by the user

Concept Wireframes

Presented the wireframe flow to engineering lead & product management as a feasible direction we could go in. They loved it!

Unfortunately due to the restaurant industry being severely hit by COVID-19 and the resultant change in priorities in the product roadmap, I had to pause the project here. I documented all the insights and designs to be picked by later by the team.

Tags UX Design, UX Research