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
Current state
Customer interviews
Feature requests
Concept workflow sketches
Internal discussions
Sketch + Invision prototypes
Design review
Stakeholder review
User testing
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!
-Uchi, Austin
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.
—Cafe Flora, SeaTac airport
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.
Do users select the items that they want to hold first and send the remaining to the kitchen or vice versa?
Do users expect items to rearrange based on their sent or held status?
Do users still expect sending and holding an entire ticket to behave in the same way?
What happens when new items are ordered when there are already certain items on hold for a table?
Do the users require visual indications to denote the difference between sending an entire ticket to the kitchen vs sending only some items?
When some items get sent to the kitchen, what happens to the remaining, do they get automatically held? Does the screen close out?
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 -
-Uchi, Austin
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 -
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.