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.

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.

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

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!

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.

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!).

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.

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

• 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.

• 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)

• 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.

• 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.

• 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.