Server Item Firing

Designing a way for servers in a restaurant to have granular control over the pace of a meal for a table


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

Servers in a restaurant don’t have control over the pacing of the meal - they can either send or ‘hold’ all the ordered items for a table to the kitchen. But what if they need to control what items get sent when to the kitchen to be prepared? To get around this issue, restaurants have workarounds in place that are costly in both time and effort for the server, adding several extra clicks to place an order, leading to frustration and wasted time.


I designed a workflow to allow more granular control for the servers to select items and either send them to the kitchen to get them prepared or place them on hold.

The Team

1 product designer/researcher (me!) + 1 product manager + 1 engineering lead + 2-4 engineers




Current state
Customer interviews
Feature requests



Concept workflow sketches
Internal discussions



Sketch + Invision prototypes
Design review
Stakeholder review


Evaluate & Iterate

User testing

Current State

This is an example menu in a restaurant where a server - let's call them Bob - is putting in an order for a table. They add multiple items to the check, and even if they select a specific item, clicking ‘hold’ ignores the selection and places a hold on all the items (and exits the order screen). Bob is confused - they thought only the selected item would be placed on hold. No worries - they go back to the table - and hit send - the red items on hold should stay...held right? Nope, in for another surprise. The inconsistent patterns and flow through the point of sale makes Bob's job much harder.


Toast has a 'meal pacing' feature that allows restaurant management to divide their menu into custom courses (appetizers, entrees, dessert, dessert round two, dessert round three, super secret special off menu course - you get the gist!), and then sends the ordered items to the kitchen in batches, course-wise. One might think this addresses the need we're trying to solve for.
This *still* does not give granular control. It also increases the effort setting up the menu on Toast's backend for the management, as well as for the server as they need to modify items on the fly - a lot of extra clicks!
Take a restaurant without rigid courses like the one below. Bob wants to try to assign numbered courses (1,2...) to batch them together so that they can pace the meal. Peep the number of extra clicks to assign a course to an item on the fly!

“Coursing doesn't work. Say you have 20 things ordered - everytime you order something individually, you need to modify the item and select the course to fire. That’s 3-5 extra clicks for every item. For 20 items, that’s 100 extra clicks and if the server is waiting 4 tables that’s around 400 and if they had 3 turns that night, that’s 1200 extra clicks.”

-Uchi, Austin

Other workarounds - pen and paper

Servers either remember the order or write it down and ring it up in batches to fire. Completely takes the convenience of having a digital platform out.

“Servers remember additional items to enter in the point of sale later - or have to be reminded by the guest, which is not great.”

—Cafe Flora, SeaTac airport

It gets weird.

Below is an example of a restaurant that is forced to set up multiple fake items on their menu - just to add instructions on the food ticket that prints to the kitchen. Bob has to add a dummy item called 'Course 1', add items below it, and so on - finally they have to add a dummy item called 'FIRE COURSE 1' which functions as an instruction to the back kitchen.
Not only is this extremely complex for restaurants to set up, it messes up their stats and reporting ('why is the most ordered item of this month FIRE COURSE 1?'), and increases the time to place an order for the server (poor Bob!).

Discovery Research

I conducted interviews with 4 restaurant owners/managers to understand their operations and how they intended to use this feature and dig down to the root cause of why they needed their servers to have granular control over the pacing of a meal.

  • We anticipated restaurants with ‘small plates’ on their menu, like sushi/tapas being the primary use cases (since a lot of items get ordered, and they don't fit into rigid courses) but we uncovered additional use cases for this feature. This included high traffic restaurants, like that in an airport; as well as restaurants concerned about the overhead of retraining staff.
  • Restaurants expected an item on a ticket to stay held. What's the point of the 'hold' option if it doesn't, well, truly hold the item?
  • Sending all the items on a ticket at a time was still a commonly used workflow in the restaurant.
  • For restaurants which had traditional courses, they did not find the need to have more granular control over pacing. The meal pacing feature worked fine for them.

Concept Ideation

Different Workflows

Do users select the items that they want to hold first and send the remaining to the kitchen or vice versa?

Sorting of items

Do users expect items to rearrange based on their sent or held status?

Sending a fully held ticket

Do users still expect sending and holding an entire ticket to behave in the same way?

Adding new items

What happens when new items are ordered when there are already certain items on hold for a table?

Visual indications

Do the users require visual indications to denote the difference between sending an entire ticket to the kitchen vs sending only some items?

Behaviour on send/hold

When some items get sent to the kitchen, what happens to the remaining, do they get automatically held? Does the screen close out?

User Testing

I conducted task-based usability testing with 4 restaurant owners/managers to find if the flow of the prototype fit their mental model or if it caused friction with current workflows. The tasks were -

  • Given an order, they want the kitchen to prepare some items right away but not the others
  • Adding new items to a food order with already held items, and multiple scenarios based on different selection of items
  • Given a fully held order and trying to send the whole order to the kitchen
I measured task success and obtained user feedback.

Different Workflows

Selecting to hold


Selecting to send

  • Restaurants liked having complete control over when they send an item. This mattered less for hold as it was an action they could recover from if needed. But if they accidentally sent items to the kitchen, that messed up their operations.
  • Restaurants primarily preferred selecting the items they wanted to send first - but selecting the items they wanted held first was also a flow that was used.

Sorting of Items

Grouped by held/sent status


Same order as entered by the server

  • The items in a ticket were typically input with specific intentions in mind by the server and they did not want that changed by the system. (e.g. items might be entered as per seat numbers, and if the system reordered it to group sent and held items, it made the server's task harder)

Sending a held ticket

Disabling ‘send’ on a fully held ticket

  • With the send button being disabled in this scenario, customers understood that they’d have to select all the item(s) in the ticket in order to send it, in order for hold to remain a true hold.

Adding new items

Adding new items to a ticket with held and sent items

  • Restaurants liked that adding new items to an order did not send existing held items to the kitchen. Like mentioned earlier - hold needed to actually be a hold on the item!
  • They understood that selecting the held item would only send that item and not the newly added items.

Visual Indications

Grouped by held/sent status


Same order as entered by the server

  • I experimented with visual cues on item selection - by showing the number of item(s) selected on the send/hold buttons. This was to indicate to the server that they were sending only selected items. Showing numbers on item selection was a nice to have, but not viewed as necessary.

“For us, the selecting and firing is all about control - really putting the power in the server's hands to say ‘What do I want to fire? What do I want to hold?’ - giving them the ability to specifically select individual things or a small group of things and being able to choose when they get sent and when they get put on hold.”

-Uchi, Austin

Final Prototype

Success Metrics

This was one of the top requested features by restaurants as the current state was severely affecting restaurant operations. The following metrics were determined to measure the success of this feature -

  • Decrease in the time to complete placing an order on the point of sale
  • Unblocking sales deals for restaurants for whom this feature is essential


After the positive feedback from user testing and appropriate iterations, I communicated my designs to the engineering team in their Agile grooming and planning sessions to enable them to build & ship the feature.

Tags UX Design, UX Research