Menus are the heart of Toast, they feed into the Point of Sale (POS), Handhelds, Kiosks, Kitchen Display Systems (KDS), Guest Online Ordering and third part delivery apps.
The Project
In 8 short years Toast has increased its feature set 10-fold. With all these capabilities, R&D has organized itself into teams that align with customer product offerings—with the exception of the ‘Menu Management’ domain, which only focuses on upstream menu creation and editing.
Menus are core to the product (e.g. if you don’t have the need for a menu, you don’t need Toast), but so operational that it is overlooked for innovation, and seen as the ‘underdog domain.’
This has left the team in maintenance mode for three years; tasked with making sure our bloated legacy ToastWeb system doesn’t collapse. In the off chance the team was able to add functionality, it was never in lockstep with other teams. This resulted in a mix and match of feature support and frustrated customers.
I was hired to help change that.
The Menu Management team set out to do three things:
Pull apart the bloated legacy tool that is ToastWeb to build smarter micro-services, enabling the team to innovate quickly.
Create a new menu experience that enables busy restauranteurs to create and management menus on their own. The added challenge here is that the industry has created an expectation that companies like Toast will build the menu for restaurants, even if it’s at cost.
Decrease costly support tickets. Today, menu tasks are the top contributor of support tickets.
the team
The Menu Management Team works in an agile framework, planning sprints every 2 weeks. We're a sizable cross-functional team consisting of two product owners, a tech lead, an architectural lead, two product/UX designers, three front-end developers, six back-end developers.
I was the lead product designer on the team, mentoring a junior member while partnering closely with the product owner and tech lead to develop a holistic vision and strategy. We were also responsible for copy, UI, and research.
Showing 1/4th of a menu configuration page (cropped due to length). Imagine filling out one of these for every menu, group, item, and modifier group.
Gaining Internal Alignment
Toast, like many other organizations, is not immune from corporate hierarchy; there are a lot of very vocal—very opinionated—members of the leadership team that want to be involved in menus, especially given their reach. Historically the designers who have been on this team failed to bring leadership along for the ride, bringing work to a crawl.
I set out to repair the relationship with leadership and show them what menus could be, in two weeks time while onboarding remotely during a global pandemic. Because of these situational hurdles I tried new tools, like Figma, to work asynchronously.
Early stakeholder map I created to get my bearings. Time was scarce, so I needed to work as smart as possible, planning ahead for any preventable roadblocks.
A web of complex relationships between product, design, and engineering, made more ‘webby’ with a shift to remote work.
Figuring out what cadence I need to report out to ensure leadership is part of the work.
I realized quickly that this body of work was less about uncovering customer paint points and more about getting leadership buy-in to unblock the engineering team.
That said we still had customer problems to solve and they had been well documented over the past three years. I was given a robust deck as a starting point that outlined the current problems facing customers. Scanning past documentation and rewatching customer interviews I identified several patterns and brought them to the surface. While product was ready to reimagine all the different menu settings I learned early on that people actually understand these today, what they don’t understand is where they are in their menu because everything is build and visualized like a database. This information helped product reprioritize the roadmap, speeding up the value and impact of our work.
In addition to this we identified two huge behavioral hurdles. The first being that white glove service is an industry standard and expectation. People don’t want to build their own menus, they have too much else to do! Second, there is a lot of mistrust in our system and people are afraid to change things. They don’t have trust in what the system will do so they reach out to customer service/
Knowing this I focused on:
How a restaurant owner (low tech) would onboard to the menu experience, knowing they are juggling many other jobs
Where we could be smarter, leveraging what we already know about the restaurant—restaurant type, size, location—to serve up smart defaults and recommendations, speeding up the menu build process
Visualizations for key configs that more closely match known mental modals, improving the navigation and IA along the way
Previews where possible, so people know what the impacts of their changes actually are, rebuilding trust
We started with the basics, a wizard that helped orient restauranteurs to Toast’s menu structure, all while building their first menu—on their own no less!
Full preview of what your menu will look like to guests online, to servers in store, and cooks in the kitchen. This also makes way for a recognizable scheduling tool, as opposed to the radio button UI that exists today.
Getting Smarter
Toast should be able to offer smart modifier groups. Today restaurants must create everything from scratch which is time consuming and error prone.
Modifier groups are easily the most complex part of the menu build experience. Modifiers enable guests to change (e.g. modify) their order. It’s not a term well known to those outside of the restaurant industry, and that included are product leadership team who petitioned heavily to have this language changed.
It took a several audio clips, and a decent amount of advocating to get them to see that this is the only way they are referenced by restaurant staff, and that it is consistent with competitors.
Once we got over the naming hurdle, it was time to take a page that was proved too flexible for people—lacking any priming or context of how it could be used. In addition to priming queues that ground people in what they are trying to achieve, we wanted to go one step further; what if people did not have to create anything?
Toast has mountains of data that could easily be mined to create smart modifier groups. For situations where restaurants wanted something truly custom, we serve up a wizard that captures intent. However, more often than not we know enough about your restaurant and menu items to be able to give pre-build modifier groups. They can easily be added to your menu experience, or updated to be more specific.
Learnings
This project is a work in progress. So far we have released 2 out of 5 milestones that make up our MVP. The initial body of work focused on setting the foundation to build the house on. It included improved wayfinding, and the localization and visualization of menu parts in a way that creates clearer relationships between them. To date we have decreased costly menu support tickets by 90%, and have seen 70% of restaurants adopt building the menu themselves.
More projects:
