Menu Editor
ChowNow
Menu Editor
ChowNow
Menu Editor
ChowNow
The Brief
How might we help menu specialists and restaurant operators create and edit items more easily and efficiently using the menu editor?
The Context
Menu editors are dashboards that restaurant operators use to manage their digital storefronts. Menus come in wide varieties that allow diners to create their own customizations, which can become very complicated to set up for operators and menu specialists. We had an existing menu editor dashboard but it hadn’t been updated for almost a decade, and it fared poorly with our restaurant partners and menu specialists. Most restaurant partners preferred to reach out to their restaurant success managers whenever they needed changes.
These managers would pass the desired changes onto the menu specialists, who often needed to be very fast and efficient to meet restaurants’ desired turnarounds— even to the point of many of them working overnight. As a result, the current process of menu editing was not sustainable and scalable. We urgently needed to streamline the menu editing process for menu specialists and make it easier for time-poor restaurant managers to learn if they needed faster turnaround.
As a result, we aimed to increase efficiencies primarily for menu specialists who used the experience the most, with the longer-term goal of making the dashboard easier for restaurant partners to use themselves if they desired. We decided on a dog-food approach where we planned to roll out the features and test them with menu specialists first before rolling them out to restaurant partners.
Details
Timeline
Six months
Role
Product Designer
Team
With a product manager, product designer,
engineer
Product
Web Service
The Brief
Reduce these inefficiencies by streamlining and systemizing menu changes.
How might we help menu specialists and restaurant operators create and edit items more easily and efficiently using the menu editor?
How might we help menu specialists and restaurant operators create and edit items more easily and efficiently using the menu editor?
Context
Menu editors are dashboards that restaurant operators use to manage their digital storefronts. Menus come in wide varieties that allow diners to create their own customizations, which can become very complicated to set up for operators and menu specialists. We had an existing menu editor dashboard but it hadn’t been updated for almost a decade, and it fared poorly with our restaurant partners and menu specialists, and most restaurant partners preferred to reach out to their restaurant success managers whenever they needed changes.
These managers would pass the desired changes onto the menu specialists, who often needed to be very fast and efficient to meet restaurants’ desired turnarounds— even to the point of many of them working overnight. As a result, the current process of menu editing was not sustainable and scalable. We urgently needed to streamline the menu editing process for menu specialists and make it easier for time-poor restaurant managers to learn if they needed faster turnaround.
As a result, our goal was to redesign the menu editor from scratch to increase efficiencies primarily for menu specialists who used the experience the most, with the longer-term goal of making the dashboard easier for restaurant partners to use themselves if they desired. We decided on a dogfood approach where we planned to roll out the features and test them with menu specialists first before rolling them out to restaurant partners.
Understanding Users
We started out by talking to menu specialists, RSMs, and restaurant partners to get a sense of their key pain points. Their biggest gripe was the lack of efficient workflows, especially when it came to editing prices. Restaurants are asking them in increasing numbers to edit menu prices within days to accommodate rising COGs. Sometimes these menus can go up to 500 items and more, so this is extremely tedious and time consuming. So finding ways to create more efficiency and accuracy were top priority.
Oftentimes, restaurant partners called us for help with the editor and it had to be easy for us to walk them through it, and we found that many of them had trouble finding things on our and our competitors’ dashboards– so clear and simple navigation was key.
Complex as they are, menus can get more complex over time as partners juggle more menus, specials, items, and so forth– so it has to be simplified, yet scalable.
As we talked to our audiences, we mapped out experiences in journey maps to find areas of opportunity.
We also conducted our own audit and competitor audits, which revealed lack of clear and simple navigation, buried pages, and overall bulkiness and lack of beginner-friendliness.
Understanding Users
We started out by talking to menu specialists, RSMs, and restaurant partners to get a sense of their key pain points. Their biggest gripe was the lack of efficient workflows, especially when it came to editing prices. Restaurants are asking them in increasing numbers to edit menu prices within days to accommodate rising COGs. Sometimes these menus can go up to 500 items and more, so this is extremely tedious and time consuming. So finding ways to create more efficiency and accuracy were top priority.
Oftentimes, restaurant partners called us for help with the editor and it had to be easy for us to walk them through it, and we found that many of them had trouble finding things on our and our competitors’ dashboards– so clear and simple navigation was key.
Complex as they are, menus can get more complex over time as partners juggle more menus, specials, items, and so forth– so it has to be simplified, yet scalable.
As we talked to our audiences, we mapped out experiences in journey maps to find areas of opportunity.
We also conducted our own audit and competitor audits, which revealed lack of clear and simple navigation, buried pages, and overall bulkiness and lack of beginner-friendliness.
Context
Menu editors are dashboards that restaurant operators use to manage their digital storefronts. Menus come in wide varieties that allow diners to create their own customizations, which can become very complicated to set up for operators and menu specialists. We had an existing menu editor dashboard but it hadn’t been updated for almost a decade, and it fared poorly with our restaurant partners and menu specialists, and most restaurant partners preferred to reach out to their restaurant success managers whenever they needed changes.
These managers would pass the desired changes onto the menu specialists, who often needed to be very fast and efficient to meet restaurants’ desired turnarounds— even to the point of many of them working overnight. As a result, the current process of menu editing was not sustainable and scalable. We urgently needed to streamline the menu editing process for menu specialists and make it easier for time-poor restaurant managers to learn if they needed faster turnaround.
As a result, our goal was to redesign the menu editor from scratch to increase efficiencies primarily for menu specialists who used the experience the most, with the longer-term goal of making the dashboard easier for restaurant partners to use themselves if they desired. We decided on a dogfood approach where we planned to roll out the features and test them with menu specialists first before rolling them out to restaurant partners.
Understanding Users
We started out by talking to menu specialists, RSMs, and restaurant partners to get a sense of their key pain points. Their biggest gripe was the lack of efficient workflows, especially when it came to editing prices. Restaurants are asking them in increasing numbers to edit menu prices within days to accommodate rising COGs. Sometimes these menus can go up to 500 items and more, so this is extremely tedious and time consuming. So finding ways to create more efficiency and accuracy were top priority.
Oftentimes, restaurant partners called us for help with the editor and it had to be easy for us to walk them through it, and we found that many of them had trouble finding things on our and our competitors’ dashboards– so clear and simple navigation was key.
Complex as they are, menus can get more complex over time as partners juggle more menus, specials, items, and so forth– so it has to be simplified, yet scalable.
As we talked to our audiences, we mapped out experiences in journey maps to find areas of opportunity.
We also conducted our own audit and competitor audits, which revealed lack of clear and simple navigation, buried pages, and overall bulkiness and lack of beginner-friendliness.
Ideation
We started out by exploring how users would navigate the menu editor with very low-fidelity mockups. My teammate and I sketched out directions and met every few days to discuss the benefits and trade-offs of each.
First, the tabbed navigation is an established paradigm on dashboards. This would allow users to quickly move between pages and give us space to add hand-holding elements for each page. Separating menus, items, and modifiers from each other and allowing a page for each would allow users to find their intersections without going too deep.
However, this would require us to create two sets of controls and inputs– a universal set above the tabbed navigation, and another more tab-specific set entirely underneath the tabs. Some tabbed pages require a lot more inputs and controls– perhaps more as we discover more complex needs– and this would not be scalable.
Some restaurant partners expressed a desire for a “Wordpress-like” editor, which means they wanted an editor that allowed them to see a preview of what their customers would see as they were editing it. They mentioned tools they used and enjoyed already, like Squarespace. I explored a drag-and-drop style editor that was similar.
However, this gradually became more complex as we thought about all of the different features and components this page would require. It would also be the most development-heavy and we wanted to roll out an MVP quickly.
Finally, we decided to keep all navigation in the side panel under a ‘Menu Editor” twirl-down. This would keep each page as minimal as possible and allow more space for hand holding and focus.
Ideation
We started out by exploring how users would navigate the menu editor with very low-fidelity mockups. My manager and I sketched out directions and met every few days to discuss the benefits and trade-offs of each.
First, the tabbed navigation is an established paradigm on dashboards. This would allow users to quickly move between pages and give us space to add hand-holding elements for each page. Separating menus, items, and modifiers from each other and allowing a page for each would allow users to find their intersections without going too deep. For example, they could go to the “modifiers” page to find a modifier instead of going to an item under “items” and clicking into it to find the modifiers that apply for just that item.
However, this would require us to create two sets of controls and inputs– a universal set above the tabbed navigation, and another more tab-specific set entirely underneath the tabs. Some tabbed pages require a lot more inputs and controls– perhaps more as we discover more complex needs– and this would not be scalable. We wanted users to be able to create what they needed wherever they are, which resulted in a universal “Create” button that forced users to select from a list of all the things they were able to create on the editor, and then the relationships between these controls and the controls and results below the tabs became less clear because they were further away from each other and separated by the header component which was a design system component that couldn’t be removed.
This could result in yet another overcomplicated dashboard.
Ideation
We started out by exploring how users would navigate the menu editor with very low-fidelity mockups. My manager and I sketched out directions and met every few days to discuss the benefits and trade-offs of each.
First, the tabbed navigation is an established paradigm on dashboards. This would allow users to quickly move between pages and give us space to add hand-holding elements for each page. Separating menus, items, and modifiers from each other and allowing a page for each would allow users to find their intersections without going too deep. For example, they could go to the “modifiers” page to find a modifier instead of going to an item under “items” and clicking into it to find the modifiers that apply for just that item.
However, this would require us to create two sets of controls and inputs– a universal set above the tabbed navigation, and another more tab-specific set entirely underneath the tabs. Some tabbed pages require a lot more inputs and controls– perhaps more as we discover more complex needs– and this would not be scalable. We wanted users to be able to create what they needed wherever they are, which resulted in a universal “Create” button that forced users to select from a list of all the things they were able to create on the editor, and then the relationships between these controls and the controls and results below the tabs became less clear because they were further away from each other and separated by the header component which was a design system component that couldn’t be removed.
This could result in yet another overcomplicated dashboard.
Some restaurant partners expressed a desire for a “Wordpress-like” editor, which means they wanted an editor that allowed them to see a preview of what their customers would see as they were editing it. They mentioned tools they used and enjoyed already, like Squarespace. I explored a drag-and-drop style editor that was similar.
However, this gradually became more complex as we thought about all of the different features and components this page would require. It would also be the most development-heavy and we wanted to roll out an MVP quickly.
Finally, we decided to keep all navigation in the side panel under a ‘Menu Editor” twirl-down. This would keep each page as minimal as possible and allow more space for hand holding and focus.
Another decision we had to make was on how users would view and edit their item or modifier details. For context, users would tap on an item to edit its details. They may be editing one or many at a time. This was a tricky problem because we were designing for two types of users that had very different needs: menu specialists were often making complex edits and restaurant partners who tended to make quicker edits. A side panel overlay would mean an extra click for the specialist. A full-page overlay would be unnecessary for more basic item edits, which was the most frequent use case. When we showed the directions to menu specialists, however, they hated the idea of the full-page overlay because it felt like a whole new page. They liked seeing the details of what they were looking at with visual context.
These discussions finally led to a happy medium- the large modal. Users could make complex edits if they wanted but click out easily to return to where they were.
Another decision we had to make was on how users would view and edit their item or modifier details. For context, users would tap on an item to edit its details. They may be editing one or many at a time. This was a tricky problem because we were designing for two types of users that had very different needs: menu specialists were often making complex edits and restaurant partners who tended to make quicker edits. A side panel overlay would mean an extra click for the specialist. A full-page overlay would be unnecessary for more basic item edits, which was the most frequent use case. When we showed the directions to menu specialists, however, they hated the idea of the full-page overlay because it felt like a whole new page. They liked seeing the details of what they were looking at with visual context.
These discussions finally led to a happy medium- the large modal. Users could make complex edits if they wanted but click out easily to return to where they were.
Some restaurant partners expressed a desire for a “Wordpress-like” editor, which means they wanted an editor that allowed them to see a preview of what their customers would see as they were editing it. They mentioned tools they used and enjoyed already, like Squarespace. I explored a drag-and-drop style editor that was similar.
However, this gradually became more complex as we thought about all of the different features and components this page would require. It would also be the most development-heavy and we wanted to roll out an MVP quickly.
Finally, we decided to keep all navigation in the side panel under a ‘Menu Editor” twirl-down. This would keep each page as minimal as possible and allow more space for hand holding and focus.
One of the biggest features we’re rolling out is the bulk item editor. This would save Chownow and its users massive amounts of time and money, and we know from competitive audits that other major OLO has this feature yet so it would also be a key competitive advantage. It’s a major source of stress and frustration that would now be resolved with a few clicks of a button.
We made countless smaller design decisions like deciding how to show information. To explore these, check out an interactive prototype.
You can also see this project in slide format here.
