Empowering restaurants to manage their own menus on the Grubhub platform.
Results
10,000+ Restaurants
Adopted the tool within three months of launch, proving strong product-market fit.
50%+ Fewer Support Calls
Self-service menu updates cut unavailable-item requests by more than half.
5 Days Faster Onboarding
Reduced new-restaurant setup time from 15 to 10 days after contract signing.
Flagship Product
Named the leading tool in Grubhub’s restaurant suite for its impact and adoption.
Context
As Grubhub’s restaurant network grew, the company faced a serious operational bottleneck. Every menu update had to be entered manually by internal teams, and thousands of change requests came in each day. This slowed down onboarding for new restaurants and placed heavy pressure on data operations. Grubhub needed a scalable way for restaurants to manage their own menus while keeping data accurate across the platform so the business could move faster, lower operational costs and support growth at national scale.
Core Challenges
1. Complex and inconsistent data structures
Menus varied across thousands of restaurants with different naming conventions, modifiers, pricing tiers and availability rules. We needed a flexible system that could support all of these variations without overwhelming users, which required rethinking how menu data was organized and presented.
2. Legacy systems that limited speed and scalability
Internal tools were rigid and built for manual entry, not fast iteration. Our design had to work within these older systems while also creating a clear path toward automation and future integrations.
3. Two user groups with competing needs
Restaurant managers needed quick, intuitive actions during busy service hours. Internal data teams focused on accuracy, validation and accessibility. The interface needed to support both without splitting into separate experiences.
4. Simple on the surface with depth underneath
Menus could include long lists of modifiers, sizes and schedules, yet the tool still had to feel as easy as editing a document. Each interaction needed to hide technical complexity behind clear language and predictable behavior.
Who We Served
Restaurant Managers
Independent teams running daily operations who needed a fast and reliable way to manage menu availability, pricing and new items. Many worked from the back office or on a mobile device between orders, so the experience had to be quick and forgiving.
Internal Data and Support Teams
Specialists responsible for reviewing and publishing updates across thousands of listings. They needed tools that protected accuracy and compliance standards while reducing the amount of manual data entry required.
Grubhub Operations and Leadership
Stakeholders focused on efficiency and growth who needed a system that could onboard restaurants faster, lower operational costs and build trust with partners through transparency and autonomy.
Design Strategy
Our goal was to design a system that balanced speed, autonomy and accuracy at scale. Restaurants needed to manage their own data without worrying about breaking anything, and internal teams needed confidence that every edit would stay structured and compliant. The strategy centered on building a modular foundation that could support thousands of unique menus while still feeling simple and intuitive for anyone to use.
Empower restaurants through autonomy
We created a self-service platform that gave restaurants full control of their menu data and removed the bottleneck of manual data entry.
Simplify complexity through modular design
We built a menu system around reusable entities such as sizes, modifiers and schedules so restaurants could create and update items quickly while keeping structure and consistency intact.
Design for speed and transparency
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Build for scale, not only launch
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Definition of Success
Success for the Menu Editor was not about releasing a new feature. It was about changing how Grubhub operated. The company needed to move away from manual, service-heavy workflows and toward self-service systems that empowered restaurants without lowering data quality or trust. Every design choice was tied to measurable goals that balanced efficiency with experience.
Our success criteria focused on three areas: lowering support dependency, speeding up onboarding and protecting data accuracy at scale. Each goal was shared across design, engineering and operations.
1. Reduce dependency on manual support
Before this project, most menu updates required intervention from Grubhub’s data entry and support teams. This created long backlogs, slowed onboarding and frustrated restaurants.
Success meant giving restaurant managers the confidence to make their own updates quickly, safely and without creating errors. From a design point of view, this required:
- Structured input patterns that replaced open text fields so data stayed clean and consistent
- Inline validation and clear feedback that explained errors in real time
- Visual previews that showed exactly what diners would see before changes were published
A successful outcome was an experience where restaurants no longer needed help for basic actions and where each interaction built confidence rather than confusion.
2. Accelerate restaurant onboarding
Onboarding speed had a direct impact on how fast new restaurants could begin earning revenue. Each menu had to be entered, structured and approved before it could go live, and the process often took weeks because of manual steps and communication gaps.
Success meant removing friction at every point in that journey. The design needed to shorten the distance between intent and activation by:
- Creating guided setup flows that covered only what was essential
- Using clear progress indicators and contextual help to keep users oriented and reduce cognitive load
- Aligning design choices with operational workflows so restaurant inputs flowed cleanly into internal review systems
The real measure of success was a smoother onboarding process where restaurants could launch quickly with less back-and-forth and more confidence in their data.
3. Maintain data accuracy at scale
Grubhub’s menu data supported everything from search results to order fulfillment. A single mistake, such as an incorrect price or broken modifier, could cause issues across the system. The challenge was giving restaurants autonomy while preventing errors that could affect diners or operations.
This was both a design and engineering goal, but design played a major role in prevention:
- Controlled components and predefined categories that kept data consistent
- Preview and confirmation steps that helped users verify changes before publishing
- Contextual warnings and safe defaults that prevented actions that could break dependencies like removing a shared modifier or schedule
Design success meant scale without added risk. Restaurants could manage their data independently without increasing errors or instability in the system.
How We Worked
Our core team included two designers, twelve engineers, one product manager, one UX writer and one UX researcher. We moved quickly and iteratively with a shared goal of delivering a product that felt powerful and intuitive.
As Lead Designer, I owned the product vision, user experience and information architecture from concept to delivery. I partnered with our UX researcher to turn field insights into design priorities and with our writer to create a clear and approachable tone across the interface, especially in error states and system messages that could affect restaurant confidence.
Collaboration was constant. We held design reviews with engineers early in the process to check feasibility, while weekly working sessions with operations, support and data teams kept the work grounded in real workflows. Mentorship was also part of our rhythm. I paired closely with another designer on complex flows and helped them deepen their systems thinking while keeping quality strong across the product.
We ran ongoing testing with both internal and external users and iterated quickly based on feedback from real restaurant managers in the field. This loop kept the work fast, practical and closely tied to user value.
Process
Our process moved quickly but stayed grounded in evidence at every step. With a tight 12-week timeline, we focused on clear goals and fast decision cycles. I shaped the work around repeatable learning loops where research, design and validation informed one another in real time. This kept the team aligned, reduced uncertainty and allowed us to refine the experience until it worked smoothly for both restaurant managers and internal teams.
Research
Design
Validation
Discovery
We began by mapping the full menu lifecycle from restaurant onboarding to menu updates to diner visibility so we could identify where delays and errors originated. Our UX researcher and I ran on-site interviews with restaurant managers across Chicago, observing real workflows in kitchens and service lines. We also interviewed internal data, support and operations teams to understand how tickets moved through the system and where breakdowns were most common.
Clear patterns emerged:
- Many menu edits were not complex. They were urgent availability changes triggered by real operational needs.
- Internal teams were spending hours each day processing low-impact tickets, which slowed down high-value updates for restaurants with more complex menus.
- Managers struggled to see how changes would appear to diners until after publication, which often created duplicate submissions and unnecessary support cycles.
These findings defined where the product could create the most value. Restaurants needed more control and more visibility into how their menus behaved, and internal teams needed a cleaner data flow that reduced manual work. The graphs that follow helped us quantify these themes and set priorities. From there, the focus shifted to building a scalable architecture and a clear interaction model that could support thousands of unique menu structures without adding complexity for users.
How do you currently update your menu on Grubhub?
Call
4
2
Fax
1
Other
0
1
2
3
4
5
What are some of the biggest challenges your currently face with updating your menu on Grubhub?
Takes too long to publish
5
Comm. Issues
3
Errors
3
Communication
3
0
1
2
3
4
5
How often do you currently update your menu on Grubhub?
43%
14%
43%
DAILY
WEEKLY
MONTHLY
RARELY
How often do you currently update your physical store menu?
29%
14%
43%
14%
DAILY
WEEKLY
MONTHLY
RARELY
What are currently some of the biggest reasons for updating your menu on Grubhub?
Run out of item(s)
5+
Update Prices
5+
New Offerings
4
2
Showcase item(s)
0
1
2
3
4
5
What are some features you would like to see in a self-service menu tool?
Turn items “on or off”
5+
Scheduling
4
Responsive
2
Instant Publish
2
0
1
2
3
4
5
Information Architecture
Information architecture became the anchor for the entire system. With two user groups and a wide range of menu structures, the work depended on building a model that could absorb complexity without exposing it to users. We broke down how menus were structured in the legacy tools and examined the core entities that shaped every workflow. From there, we rebuilt these pieces into a modular framework that could scale without adding confusion to the interface.
Below are the key IA models that guided our decisions and aligned design, engineering and data operations.
Item Creation Flow
This flow mapped the complete lifecycle of creating an item, from basic details to schedules, sizes and modifier groups. It highlighted friction in the old workflow and revealed where reusable components could replace repeated manual steps. These insights shaped the modular editor that allowed users to create complex items quickly while keeping data structured.
System Entity Map
This model defined the core entities that powered the Menu Editor and how they connected across the platform. It brought clarity to a fragmented legacy system and created a shared understanding of the relationships between items, modifiers, sizes, schedules and categories. This alignment allowed engineering to build a consistent backend that supported thousands of unique menus without custom logic.
Section and Subcategory Flow
This diagram showed how section management connected to the item editor and exposed gaps that created inconsistencies in the menu. By visualizing these paths, we identified patterns that could cause errors, such as undefined schedules or missing size groups, and redesigned them into predictable, repeatable flows.
Design & Prototyping
With insights and the information architecture in place, I moved into low-fidelity wireframes to explore the core interactions that shaped the product. The goal was to translate a complex system into an experience that felt simple and immediate. Each concept focused on reducing steps, improving clarity and giving restaurants confidence in their updates.
Key patterns included:
- A quick blackout flow that allowed managers to mark items unavailable in seconds without losing their place
- Reusable entities that let users create or attach modifiers and schedules globally so they did not have to rebuild the same structures across multiple items
- Inline editing that supported fast updates with real-time validation
- A preview-first approach that showed managers exactly how their changes would appear to diners before publishing
This phase helped us validate what mattered most for speed and accuracy and gave the engineering team a clear direction for how the interactions needed to behave.
Once the core interactions felt solid, we shifted into high-fidelity prototypes in Sketch and InVision. I worked closely with our UX writer to refine microcopy that reduced user anxiety and with engineering to make sure the layouts behaved well on smaller screens. This phase tightened the details, clarified intent and set the standard for the visual and interaction patterns that would guide development.
Testing & Iteration
We ran multiple rounds of testing with restaurant managers and internal support teams and combined surveys, interviews and live prototype sessions to understand how menus were being managed in real environments.
The results reflected what we saw in discovery. Restaurants were working under constant time pressure and their tools were not keeping up.
Key findings included:
- 67% of respondents said they updated their physical menus weekly or daily, but only fourteen percent could update their Grubhub menus that often
- Most restaurants relied on calls or emails to make changes and a few still used fax
- The top pain points were long publishing times and communication issues
- The most common reasons for updates were running out of items or price changes, both of which required fast action
- The most requested features were the ability to turn items on or off, schedule availability and publish updates instantly
These insights clarified the direction. Restaurant managers did not want a complex data system. They wanted control and the confidence that updates would go live when they needed them.
We shifted the design focus toward features that offered speed and reassurance:
- A one-click availability toggle for marking items out of stock in seconds
- Instant publishing that pushed updates without waiting for support teams
- Scheduling tools for recurring changes such as lunch and dinner transitions
This feedback loop shaped our priorities in real time. Each prototype session focused on whether the interactions felt immediate and reliable. Could someone make a change mid-service under pressure without second-guessing it?
Each cycle brought us closer to that goal. By combining quantitative data with live usability testing, we built confidence that the Menu Editor addressed a real operational problem rather than a surface-level workflow gap.
Delivery
As we moved into handoff, I worked closely with engineering to ensure the build matched the intent of the design. We focused on pixel accuracy, consistency with the design system and smooth integration with the existing restaurant platform. The final prototypes were fully interactive, and every major flow was tested across breakpoints to confirm responsive behavior.
I also partnered with our UX writer to finalize error messages and state changes. The goal was to use clear, supportive language that helped users understand what was happening and why. These details were critical for building trust and reducing anxiety in moments where accuracy mattered most.
The screens that follow represent the finalized experience and the patterns that guided development across the product.
Users land in the Menu Editor after signing into Grubhub for Restaurants and see their full menu laid out in a clear grid. Items sit inside sections that can be expanded or collapsed so it’s easy to scan and navigate. Each item card can be selected to view or edit details, and the left sidebar gives direct access to broader tasks like creating items, editing sections or adjusting schedules. This structure helps restaurants manage large menus with less searching and fewer clicks.
Selecting a menu item opens a small action menu with options to adjust availability, edit details, preview how the item appears on Grubhub or create a copy. Copying is especially helpful when restaurants want to reuse an existing item as a starting point and speed up menu creation. These options give users quick access to the changes they make most often so they can keep their menus accurate without extra steps.
When a user selects an item, they see a focused action menu with the tasks they rely on most. They can adjust availability, make quick edits, preview the customer view or create a copy when they want to reuse an item as a starting point. These actions are grouped together to reduce repetitive work and help restaurants update their menus quickly and confidently.
Selecting Create Item opens the item editor where users can build everything in one place. They can upload a photo, write a description, enter calories, choose a section, set a schedule and control availability for coupons, group orders or catering. They can also add sizes, modifiers and tags along with the correct tax percentage so the item is ready the moment it goes live. This unified workflow gives restaurants a clear path from idea to published item without jumping between multiple screens.
Users choose when an item is available by selecting from schedules they have already created or by marking the item as always available. They can also create a new schedule from this view if they need more precise hours. This gives restaurants tighter control over what customers can order and helps prevent mistakes like items showing up during times when the kitchen cannot prepare them.
To help users work faster, sizes, modifiers and schedules are fully reusable. Once they create them, they can attach or remove these groups from any item with only a few clicks or taps. This reduces repetitive setup and keeps menu management consistent across items.
When editing modifiers, users can add or remove options from a group or update prices and calorie information in one place. They can also hide a modifier temporarily if the kitchen runs out of stock. This gives restaurants flexible control over their menu without needing to delete items or rebuild groups from scratch.
Users can set modifier prices on their own or tie them to the size of the item. This flexibility supports menus where prices change with portion size and helps restaurants keep their pricing consistent without managing separate modifier groups for every variation.
Users can also choose whether an item is available for coupons, group orders or catering. This helps restaurants control how each item appears across different order types and prevents situations where items show up in channels the kitchen cannot support.
Users can view a full preview of the item before saving and publishing it. From here, they can choose to make the item available right away or schedule it to go live at a later date. This final step helps restaurants validate content, pricing and options so the item reaches customers exactly the way they intend.
Impact
The Menu Editor shifted Grubhub from a manual, service-heavy workflow to a self-service system that scaled across the restaurant network. Adoption was fast and widespread. More than ten thousand restaurants were using the tool within three months of launch, which confirmed strong product-market fit and validated the core design decisions.
Support demand dropped sharply. Self-service updates reduced unavailable-item requests by more than half, which freed internal teams to focus on higher-value work. This change alone created a measurable improvement in operational efficiency across data and support teams.
Onboarding became faster. Restaurants could now publish complete menus without waiting for internal intervention, which cut the average setup time by five days. This improvement helped restaurants start earning revenue sooner and lowered the cost to bring new partners onto the platform.
The tool became a flagship product within Grubhub’s restaurant suite. Its reliability, scale and adoption set a new bar for how the company approached partner-facing tools. More importantly, it demonstrated the value of investing in systems that give restaurants real control of their data while maintaining accuracy across the broader platform.
Reflection
This project reshaped how I think about designing for real operational pressure. Working directly with restaurant managers and internal teams made it clear that the best tools do not overwhelm users with power. They remove friction, create clarity and protect people during moments when time and accuracy matter most. The Menu Editor reinforced the value of systems thinking, not as an abstract exercise but as a practical way to align design, engineering and operations around a shared model.
The work also strengthened my belief that autonomy and safety can coexist in a single experience. Giving restaurants more control required careful guardrails, clear communication and patterns that felt familiar even when the underlying structure was complex. That balance guided every decision.
What stayed with me most was the impact of small details. A phrase that lowered anxiety, a preview that built trust, a flow that saved a few seconds each day. These moments accumulate and shape how people feel about a product. They also shape how an organization understands the role of design.
This project made that visible. It showed that thoughtful systems, grounded in real user needs, can change the way a company operates and open the door for better tools that follow.
Let’s talk!
If you’re looking for thoughtful, outcomes-driven product design, I’d love to hear what you’re working on.
Say hi!
Empowering restaurants to manage their own menus on the Grubhub platform.
Results
10,000+ Restaurants
Adopted the tool within three months of launch, proving strong product-market fit.
50%+ Fewer Support Calls
Self-service menu updates cut unavailable-item requests by more than half.
5 Days Faster Onboarding
Reduced new-restaurant setup time from 15 to 10 days after contract signing.
Flagship Product
Named the leading tool in Grubhub’s restaurant suite for its impact and adoption.
Context
As Grubhub’s restaurant network grew, the company faced a serious operational bottleneck. Every menu update had to be entered manually by internal teams, and thousands of change requests came in each day. This slowed down onboarding for new restaurants and placed heavy pressure on data operations. Grubhub needed a scalable way for restaurants to manage their own menus while keeping data accurate across the platform so the business could move faster, lower operational costs and support growth at national scale.
Core Challenges
1. Complex and inconsistent data structures
Menus varied across thousands of restaurants with different naming conventions, modifiers, pricing tiers and availability rules. We needed a flexible system that could support all of these variations without overwhelming users, which required rethinking how menu data was organized and presented.
2. Legacy systems that limited speed and scalability
Internal tools were rigid and built for manual entry, not fast iteration. Our design had to work within these older systems while also creating a clear path toward automation and future integrations.
3. Two user groups with competing needs
Restaurant managers needed quick, intuitive actions during busy service hours. Internal data teams focused on accuracy, validation and accessibility. The interface needed to support both without splitting into separate experiences.
4. Simple on the surface with depth underneath
Menus could include long lists of modifiers, sizes and schedules, yet the tool still had to feel as easy as editing a document. Each interaction needed to hide technical complexity behind clear language and predictable behavior.
Who We Served
Restaurant Managers
Independent teams running daily operations who needed a fast and reliable way to manage menu availability, pricing and new items. Many worked from the back office or on a mobile device between orders, so the experience had to be quick and forgiving.
Internal Data and Support Teams
Specialists responsible for reviewing and publishing updates across thousands of listings. They needed tools that protected accuracy and compliance standards while reducing the amount of manual data entry required.
Grubhub Operations and Leadership
Stakeholders focused on efficiency and growth who needed a system that could onboard restaurants faster, lower operational costs and build trust with partners through transparency and autonomy.
Design Strategy
Our goal was to design a system that balanced speed, autonomy and accuracy at scale. Restaurants needed to manage their own data without worrying about breaking anything, and internal teams needed confidence that every edit would stay structured and compliant. The strategy centered on building a modular foundation that could support thousands of unique menus while still feeling simple and intuitive for anyone to use.
Empower restaurants through autonomy
We created a self-service platform that gave restaurants full control of their menu data and removed the bottleneck of manual data entry.
Simplify complexity through modular design
We built a menu system around reusable entities such as sizes, modifiers and schedules so restaurants could create and update items quickly while keeping structure and consistency intact.
Design for speed and transparency
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Build for scale, not only launch
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Definition of Success
Success for the Menu Editor was not about releasing a new feature. It was about changing how Grubhub operated. The company needed to move away from manual, service-heavy workflows and toward self-service systems that empowered restaurants without lowering data quality or trust. Every design choice was tied to measurable goals that balanced efficiency with experience.
Our success criteria focused on three areas: lowering support dependency, speeding up onboarding and protecting data accuracy at scale. Each goal was shared across design, engineering and operations.
1. Reduce dependency on manual support
Before this project, most menu updates required intervention from Grubhub’s data entry and support teams. This created long backlogs, slowed onboarding and frustrated restaurants.
Success meant giving restaurant managers the confidence to make their own updates quickly, safely and without creating errors. From a design point of view, this required:
- Structured input patterns that replaced open text fields so data stayed clean and consistent
- Inline validation and clear feedback that explained errors in real time
- Visual previews that showed exactly what diners would see before changes were published
A successful outcome was an experience where restaurants no longer needed help for basic actions and where each interaction built confidence rather than confusion.
2. Accelerate restaurant onboarding
Onboarding speed had a direct impact on how fast new restaurants could begin earning revenue. Each menu had to be entered, structured and approved before it could go live, and the process often took weeks because of manual steps and communication gaps.
Success meant removing friction at every point in that journey. The design needed to shorten the distance between intent and activation by:
- Creating guided setup flows that covered only what was essential
- Using clear progress indicators and contextual help to keep users oriented and reduce cognitive load
- Aligning design choices with operational workflows so restaurant inputs flowed cleanly into internal review systems
The real measure of success was a smoother onboarding process where restaurants could launch quickly with less back-and-forth and more confidence in their data.
3. Maintain data accuracy at scale
Grubhub’s menu data supported everything from search results to order fulfillment. A single mistake, such as an incorrect price or broken modifier, could cause issues across the system. The challenge was giving restaurants autonomy while preventing errors that could affect diners or operations.
This was both a design and engineering goal, but design played a major role in prevention:
- Controlled components and predefined categories that kept data consistent
- Preview and confirmation steps that helped users verify changes before publishing
- Contextual warnings and safe defaults that prevented actions that could break dependencies like removing a shared modifier or schedule
Design success meant scale without added risk. Restaurants could manage their data independently without increasing errors or instability in the system.
How We Worked
Our core team included two designers, twelve engineers, one product manager, one UX writer and one UX researcher. We moved quickly and iteratively with a shared goal of delivering a product that felt powerful and intuitive.
As Lead Designer, I owned the product vision, user experience and information architecture from concept to delivery. I partnered with our UX researcher to turn field insights into design priorities and with our writer to create a clear and approachable tone across the interface, especially in error states and system messages that could affect restaurant confidence.
Collaboration was constant. We held design reviews with engineers early in the process to check feasibility, while weekly working sessions with operations, support and data teams kept the work grounded in real workflows. Mentorship was also part of our rhythm. I paired closely with another designer on complex flows and helped them deepen their systems thinking while keeping quality strong across the product.
We ran ongoing testing with both internal and external users and iterated quickly based on feedback from real restaurant managers in the field. This loop kept the work fast, practical and closely tied to user value.
Process
Our process moved quickly but stayed grounded in evidence at every step. With a tight 12-week timeline, we focused on clear goals and fast decision cycles. I shaped the work around repeatable learning loops where research, design and validation informed one another in real time. This kept the team aligned, reduced uncertainty and allowed us to refine the experience until it worked smoothly for both restaurant managers and internal teams.
Research
Design
Validation
Discovery
We began by mapping the full menu lifecycle from restaurant onboarding to menu updates to diner visibility so we could identify where delays and errors originated. Our UX researcher and I ran on-site interviews with restaurant managers across Chicago, observing real workflows in kitchens and service lines. We also interviewed internal data, support and operations teams to understand how tickets moved through the system and where breakdowns were most common.
Clear patterns emerged:
- Many menu edits were not complex. They were urgent availability changes triggered by real operational needs.
- Internal teams were spending hours each day processing low-impact tickets, which slowed down high-value updates for restaurants with more complex menus.
- Managers struggled to see how changes would appear to diners until after publication, which often created duplicate submissions and unnecessary support cycles.
These findings defined where the product could create the most value. Restaurants needed more control and more visibility into how their menus behaved, and internal teams needed a cleaner data flow that reduced manual work. The graphs that follow helped us quantify these themes and set priorities. From there, the focus shifted to building a scalable architecture and a clear interaction model that could support thousands of unique menu structures without adding complexity for users.
How do you currently update your menu on Grubhub?
Call
4
2
Fax
1
Other
0
1
2
3
4
5
What are some of the biggest challenges your currently face with updating your menu on Grubhub?
Takes too long to publish
5
Comm. Issues
3
Errors
3
Communication
3
0
1
2
3
4
5
How often do you currently update your menu on Grubhub?
43%
14%
43%
DAILY
WEEKLY
MONTHLY
RARELY
How often do you currently update your physical store menu?
29%
14%
43%
14%
DAILY
WEEKLY
MONTHLY
RARELY
What are currently some of the biggest reasons for updating your menu on Grubhub?
Run out of item(s)
5+
Update Prices
5+
New Offerings
4
2
Showcase item(s)
0
1
2
3
4
5
What are some features you would like to see in a self-service menu tool?
Turn items “on or off”
5+
Scheduling
4
Responsive
2
Instant Publish
2
0
1
2
3
4
5
Information Architecture
Information architecture became the anchor for the entire system. With two user groups and a wide range of menu structures, the work depended on building a model that could absorb complexity without exposing it to users. We broke down how menus were structured in the legacy tools and examined the core entities that shaped every workflow. From there, we rebuilt these pieces into a modular framework that could scale without adding confusion to the interface.
Below are the key IA models that guided our decisions and aligned design, engineering and data operations.
Item Creation Flow
This flow mapped the complete lifecycle of creating an item, from basic details to schedules, sizes and modifier groups. It highlighted friction in the old workflow and revealed where reusable components could replace repeated manual steps. These insights shaped the modular editor that allowed users to create complex items quickly while keeping data structured.
System Entity Map
This model defined the core entities that powered the Menu Editor and how they connected across the platform. It brought clarity to a fragmented legacy system and created a shared understanding of the relationships between items, modifiers, sizes, schedules and categories. This alignment allowed engineering to build a consistent backend that supported thousands of unique menus without custom logic.
Section and Subcategory Flow
This diagram showed how section management connected to the item editor and exposed gaps that created inconsistencies in the menu. By visualizing these paths, we identified patterns that could cause errors, such as undefined schedules or missing size groups, and redesigned them into predictable, repeatable flows.
Design & Prototyping
With insights and the information architecture in place, I moved into low-fidelity wireframes to explore the core interactions that shaped the product. The goal was to translate a complex system into an experience that felt simple and immediate. Each concept focused on reducing steps, improving clarity and giving restaurants confidence in their updates.
Key patterns included:
- A quick blackout flow that allowed managers to mark items unavailable in seconds without losing their place
- Reusable entities that let users create or attach modifiers and schedules globally so they did not have to rebuild the same structures across multiple items
- Inline editing that supported fast updates with real-time validation
- A preview-first approach that showed managers exactly how their changes would appear to diners before publishing
This phase helped us validate what mattered most for speed and accuracy and gave the engineering team a clear direction for how the interactions needed to behave.
Once the core interactions felt solid, we shifted into high-fidelity prototypes in Sketch and InVision. I worked closely with our UX writer to refine microcopy that reduced user anxiety and with engineering to make sure the layouts behaved well on smaller screens. This phase tightened the details, clarified intent and set the standard for the visual and interaction patterns that would guide development.
Testing & Iteration
We ran multiple rounds of testing with restaurant managers and internal support teams and combined surveys, interviews and live prototype sessions to understand how menus were being managed in real environments.
The results reflected what we saw in discovery. Restaurants were working under constant time pressure and their tools were not keeping up.
Key findings included:
- 67% of respondents said they updated their physical menus weekly or daily, but only fourteen percent could update their Grubhub menus that often
- Most restaurants relied on calls or emails to make changes and a few still used fax
- The top pain points were long publishing times and communication issues
- The most common reasons for updates were running out of items or price changes, both of which required fast action
- The most requested features were the ability to turn items on or off, schedule availability and publish updates instantly
These insights clarified the direction. Restaurant managers did not want a complex data system. They wanted control and the confidence that updates would go live when they needed them.
We shifted the design focus toward features that offered speed and reassurance:
- A one-click availability toggle for marking items out of stock in seconds
- Instant publishing that pushed updates without waiting for support teams
- Scheduling tools for recurring changes such as lunch and dinner transitions
This feedback loop shaped our priorities in real time. Each prototype session focused on whether the interactions felt immediate and reliable. Could someone make a change mid-service under pressure without second-guessing it?
Each cycle brought us closer to that goal. By combining quantitative data with live usability testing, we built confidence that the Menu Editor addressed a real operational problem rather than a surface-level workflow gap.
Delivery
As we moved into handoff, I worked closely with engineering to ensure the build matched the intent of the design. We focused on pixel accuracy, consistency with the design system and smooth integration with the existing restaurant platform. The final prototypes were fully interactive, and every major flow was tested across breakpoints to confirm responsive behavior.
I also partnered with our UX writer to finalize error messages and state changes. The goal was to use clear, supportive language that helped users understand what was happening and why. These details were critical for building trust and reducing anxiety in moments where accuracy mattered most.
The screens that follow represent the finalized experience and the patterns that guided development across the product.
Users land in the Menu Editor after signing into Grubhub for Restaurants and see their full menu laid out in a clear grid. Items sit inside sections that can be expanded or collapsed so it’s easy to scan and navigate. Each item card can be selected to view or edit details, and the left sidebar gives direct access to broader tasks like creating items, editing sections or adjusting schedules. This structure helps restaurants manage large menus with less searching and fewer clicks.
Selecting a menu item opens a small action menu with options to adjust availability, edit details, preview how the item appears on Grubhub or create a copy. Copying is especially helpful when restaurants want to reuse an existing item as a starting point and speed up menu creation. These options give users quick access to the changes they make most often so they can keep their menus accurate without extra steps.
When a user selects an item, they see a focused action menu with the tasks they rely on most. They can adjust availability, make quick edits, preview the customer view or create a copy when they want to reuse an item as a starting point. These actions are grouped together to reduce repetitive work and help restaurants update their menus quickly and confidently.
Selecting Create Item opens the item editor where users can build everything in one place. They can upload a photo, write a description, enter calories, choose a section, set a schedule and control availability for coupons, group orders or catering. They can also add sizes, modifiers and tags along with the correct tax percentage so the item is ready the moment it goes live. This unified workflow gives restaurants a clear path from idea to published item without jumping between multiple screens.
Users choose when an item is available by selecting from schedules they have already created or by marking the item as always available. They can also create a new schedule from this view if they need more precise hours. This gives restaurants tighter control over what customers can order and helps prevent mistakes like items showing up during times when the kitchen cannot prepare them.
To help users work faster, sizes, modifiers and schedules are fully reusable. Once they create them, they can attach or remove these groups from any item with only a few clicks or taps. This reduces repetitive setup and keeps menu management consistent across items.
When editing modifiers, users can add or remove options from a group or update prices and calorie information in one place. They can also hide a modifier temporarily if the kitchen runs out of stock. This gives restaurants flexible control over their menu without needing to delete items or rebuild groups from scratch.
Users can set modifier prices on their own or tie them to the size of the item. This flexibility supports menus where prices change with portion size and helps restaurants keep their pricing consistent without managing separate modifier groups for every variation.
Users can also choose whether an item is available for coupons, group orders or catering. This helps restaurants control how each item appears across different order types and prevents situations where items show up in channels the kitchen cannot support.
Users can view a full preview of the item before saving and publishing it. From here, they can choose to make the item available right away or schedule it to go live at a later date. This final step helps restaurants validate content, pricing and options so the item reaches customers exactly the way they intend.
Impact
The Menu Editor shifted Grubhub from a manual, service-heavy workflow to a self-service system that scaled across the restaurant network. Adoption was fast and widespread. More than ten thousand restaurants were using the tool within three months of launch, which confirmed strong product-market fit and validated the core design decisions.
Support demand dropped sharply. Self-service updates reduced unavailable-item requests by more than half, which freed internal teams to focus on higher-value work. This change alone created a measurable improvement in operational efficiency across data and support teams.
Onboarding became faster. Restaurants could now publish complete menus without waiting for internal intervention, which cut the average setup time by five days. This improvement helped restaurants start earning revenue sooner and lowered the cost to bring new partners onto the platform.
The tool became a flagship product within Grubhub’s restaurant suite. Its reliability, scale and adoption set a new bar for how the company approached partner-facing tools. More importantly, it demonstrated the value of investing in systems that give restaurants real control of their data while maintaining accuracy across the broader platform.
Reflection
This project reshaped how I think about designing for real operational pressure. Working directly with restaurant managers and internal teams made it clear that the best tools do not overwhelm users with power. They remove friction, create clarity and protect people during moments when time and accuracy matter most. The Menu Editor reinforced the value of systems thinking, not as an abstract exercise but as a practical way to align design, engineering and operations around a shared model.
The work also strengthened my belief that autonomy and safety can coexist in a single experience. Giving restaurants more control required careful guardrails, clear communication and patterns that felt familiar even when the underlying structure was complex. That balance guided every decision.
What stayed with me most was the impact of small details. A phrase that lowered anxiety, a preview that built trust, a flow that saved a few seconds each day. These moments accumulate and shape how people feel about a product. They also shape how an organization understands the role of design.
This project made that visible. It showed that thoughtful systems, grounded in real user needs, can change the way a company operates and open the door for better tools that follow.
Let’s talk!
If you’re looking for thoughtful, outcomes-driven product design, I’d love to hear what you’re working on.
Say hi!
Empowering restaurants to manage their own menus on the Grubhub platform.
Results
10,000+ Restaurants
Adopted the tool within three months of launch, proving strong product-market fit.
50%+ Fewer Support Calls
Self-service menu updates cut unavailable-item requests by more than half.
5 Days Faster Onboarding
Reduced new-restaurant setup time from 15 to 10 days after contract signing.
Flagship Product
Named the leading tool in Grubhub’s restaurant suite for its impact and adoption.
Context
As Grubhub’s restaurant network grew, the company faced a serious operational bottleneck. Every menu update had to be entered manually by internal teams, and thousands of change requests came in each day. This slowed down onboarding for new restaurants and placed heavy pressure on data operations. Grubhub needed a scalable way for restaurants to manage their own menus while keeping data accurate across the platform so the business could move faster, lower operational costs and support growth at national scale.
Core Challenges
1. Complex and inconsistent data structures
Menus varied across thousands of restaurants with different naming conventions, modifiers, pricing tiers and availability rules. We needed a flexible system that could support all of these variations without overwhelming users, which required rethinking how menu data was organized and presented.
2. Legacy systems that limited speed and scalability
Internal tools were rigid and built for manual entry, not fast iteration. Our design had to work within these older systems while also creating a clear path toward automation and future integrations.
3. Two user groups with competing needs
Restaurant managers needed quick, intuitive actions during busy service hours. Internal data teams focused on accuracy, validation and accessibility. The interface needed to support both without splitting into separate experiences.
4. Simple on the surface with depth underneath
Menus could include long lists of modifiers, sizes and schedules, yet the tool still had to feel as easy as editing a document. Each interaction needed to hide technical complexity behind clear language and predictable behavior.
Who We Served
Restaurant Managers
Independent teams running daily operations who needed a fast and reliable way to manage menu availability, pricing and new items. Many worked from the back office or on a mobile device between orders, so the experience had to be quick and forgiving.
Internal Data and Support Teams
Specialists responsible for reviewing and publishing updates across thousands of listings. They needed tools that protected accuracy and compliance standards while reducing the amount of manual data entry required.
Grubhub Operations and Leadership
Stakeholders focused on efficiency and growth who needed a system that could onboard restaurants faster, lower operational costs and build trust with partners through transparency and autonomy.
Design Strategy
Our goal was to design a system that balanced speed, autonomy and accuracy at scale. Restaurants needed to manage their own data without worrying about breaking anything, and internal teams needed confidence that every edit would stay structured and compliant. The strategy centered on building a modular foundation that could support thousands of unique menus while still feeling simple and intuitive for anyone to use.
Empower restaurants through autonomy
We created a self-service platform that gave restaurants full control of their menu data and removed the bottleneck of manual data entry.
Simplify complexity through modular design
We built a menu system around reusable entities such as sizes, modifiers and schedules so restaurants could create and update items quickly while keeping structure and consistency intact.
Design for speed and transparency
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Build for scale, not only launch
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Definition of Success
Success for the Menu Editor was not about releasing a new feature. It was about changing how Grubhub operated. The company needed to move away from manual, service-heavy workflows and toward self-service systems that empowered restaurants without lowering data quality or trust. Every design choice was tied to measurable goals that balanced efficiency with experience.
Our success criteria focused on three areas: lowering support dependency, speeding up onboarding and protecting data accuracy at scale. Each goal was shared across design, engineering and operations.
1. Reduce dependency on manual support
Before this project, most menu updates required intervention from Grubhub’s data entry and support teams. This created long backlogs, slowed onboarding and frustrated restaurants.
Success meant giving restaurant managers the confidence to make their own updates quickly, safely and without creating errors. From a design point of view, this required:
- Structured input patterns that replaced open text fields so data stayed clean and consistent
- Inline validation and clear feedback that explained errors in real time
- Visual previews that showed exactly what diners would see before changes were published
A successful outcome was an experience where restaurants no longer needed help for basic actions and where each interaction built confidence rather than confusion.
2. Accelerate restaurant onboarding
Onboarding speed had a direct impact on how fast new restaurants could begin earning revenue. Each menu had to be entered, structured and approved before it could go live, and the process often took weeks because of manual steps and communication gaps.
Success meant removing friction at every point in that journey. The design needed to shorten the distance between intent and activation by:
- Creating guided setup flows that covered only what was essential
- Using clear progress indicators and contextual help to keep users oriented and reduce cognitive load
- Aligning design choices with operational workflows so restaurant inputs flowed cleanly into internal review systems
The real measure of success was a smoother onboarding process where restaurants could launch quickly with less back-and-forth and more confidence in their data.
3. Maintain data accuracy at scale
Grubhub’s menu data supported everything from search results to order fulfillment. A single mistake, such as an incorrect price or broken modifier, could cause issues across the system. The challenge was giving restaurants autonomy while preventing errors that could affect diners or operations.
This was both a design and engineering goal, but design played a major role in prevention:
- Controlled components and predefined categories that kept data consistent
- Preview and confirmation steps that helped users verify changes before publishing
- Contextual warnings and safe defaults that prevented actions that could break dependencies like removing a shared modifier or schedule
Design success meant scale without added risk. Restaurants could manage their data independently without increasing errors or instability in the system.
How We Worked
Our core team included two designers, twelve engineers, one product manager, one UX writer and one UX researcher. We moved quickly and iteratively with a shared goal of delivering a product that felt powerful and intuitive.
As Lead Designer, I owned the product vision, user experience and information architecture from concept to delivery. I partnered with our UX researcher to turn field insights into design priorities and with our writer to create a clear and approachable tone across the interface, especially in error states and system messages that could affect restaurant confidence.
Collaboration was constant. We held design reviews with engineers early in the process to check feasibility, while weekly working sessions with operations, support and data teams kept the work grounded in real workflows. Mentorship was also part of our rhythm. I paired closely with another designer on complex flows and helped them deepen their systems thinking while keeping quality strong across the product.
We ran ongoing testing with both internal and external users and iterated quickly based on feedback from real restaurant managers in the field. This loop kept the work fast, practical and closely tied to user value.
Process
Our process moved quickly but stayed grounded in evidence at every step. With a tight 12-week timeline, we focused on clear goals and fast decision cycles. I shaped the work around repeatable learning loops where research, design and validation informed one another in real time. This kept the team aligned, reduced uncertainty and allowed us to refine the experience until it worked smoothly for both restaurant managers and internal teams.
Research
Design
Validation
Discovery
We began by mapping the full menu lifecycle from restaurant onboarding to menu updates to diner visibility so we could identify where delays and errors originated. Our UX researcher and I ran on-site interviews with restaurant managers across Chicago, observing real workflows in kitchens and service lines. We also interviewed internal data, support and operations teams to understand how tickets moved through the system and where breakdowns were most common.
Clear patterns emerged:
- Many menu edits were not complex. They were urgent availability changes triggered by real operational needs.
- Internal teams were spending hours each day processing low-impact tickets, which slowed down high-value updates for restaurants with more complex menus.
- Managers struggled to see how changes would appear to diners until after publication, which often created duplicate submissions and unnecessary support cycles.
These findings defined where the product could create the most value. Restaurants needed more control and more visibility into how their menus behaved, and internal teams needed a cleaner data flow that reduced manual work. The graphs that follow helped us quantify these themes and set priorities. From there, the focus shifted to building a scalable architecture and a clear interaction model that could support thousands of unique menu structures without adding complexity for users.
How do you currently update your menu on Grubhub?
Call
4
2
Fax
1
Other
0
1
2
3
4
5
What are some of the biggest challenges your currently face with updating your menu on Grubhub?
Takes too long to publish
5
Comm. Issues
3
Errors
3
Communication
3
0
1
2
3
4
5
How often do you currently update your menu on Grubhub?
43%
14%
43%
DAILY
WEEKLY
MONTHLY
RARELY
How often do you currently update your physical store menu?
29%
14%
43%
14%
DAILY
WEEKLY
MONTHLY
RARELY
What are currently some of the biggest reasons for updating your menu on Grubhub?
Run out of item(s)
5+
Update Prices
5+
New Offerings
4
2
Showcase item(s)
0
1
2
3
4
5
What are some features you would like to see in a self-service menu tool?
Turn items “on or off”
5+
Scheduling
4
Responsive
2
Instant Publish
2
0
1
2
3
4
5
Information Architecture
Information architecture became the anchor for the entire system. With two user groups and a wide range of menu structures, the work depended on building a model that could absorb complexity without exposing it to users. We broke down how menus were structured in the legacy tools and examined the core entities that shaped every workflow. From there, we rebuilt these pieces into a modular framework that could scale without adding confusion to the interface.
Below are the key IA models that guided our decisions and aligned design, engineering and data operations.
Item Creation Flow
This flow mapped the complete lifecycle of creating an item, from basic details to schedules, sizes and modifier groups. It highlighted friction in the old workflow and revealed where reusable components could replace repeated manual steps. These insights shaped the modular editor that allowed users to create complex items quickly while keeping data structured.
System Entity Map
This model defined the core entities that powered the Menu Editor and how they connected across the platform. It brought clarity to a fragmented legacy system and created a shared understanding of the relationships between items, modifiers, sizes, schedules and categories. This alignment allowed engineering to build a consistent backend that supported thousands of unique menus without custom logic.
Section and Subcategory Flow
This diagram showed how section management connected to the item editor and exposed gaps that created inconsistencies in the menu. By visualizing these paths, we identified patterns that could cause errors, such as undefined schedules or missing size groups, and redesigned them into predictable, repeatable flows.
Design & Prototyping
With insights and the information architecture in place, I moved into low-fidelity wireframes to explore the core interactions that shaped the product. The goal was to translate a complex system into an experience that felt simple and immediate. Each concept focused on reducing steps, improving clarity and giving restaurants confidence in their updates.
Key patterns included:
- A quick blackout flow that allowed managers to mark items unavailable in seconds without losing their place
- Reusable entities that let users create or attach modifiers and schedules globally so they did not have to rebuild the same structures across multiple items
- Inline editing that supported fast updates with real-time validation
- A preview-first approach that showed managers exactly how their changes would appear to diners before publishing
This phase helped us validate what mattered most for speed and accuracy and gave the engineering team a clear direction for how the interactions needed to behave.
Once the core interactions felt solid, we shifted into high-fidelity prototypes in Sketch and InVision. I worked closely with our UX writer to refine microcopy that reduced user anxiety and with engineering to make sure the layouts behaved well on smaller screens. This phase tightened the details, clarified intent and set the standard for the visual and interaction patterns that would guide development.
Testing & Iteration
We ran multiple rounds of testing with restaurant managers and internal support teams and combined surveys, interviews and live prototype sessions to understand how menus were being managed in real environments.
The results reflected what we saw in discovery. Restaurants were working under constant time pressure and their tools were not keeping up.
Key findings included:
- 67% of respondents said they updated their physical menus weekly or daily, but only fourteen percent could update their Grubhub menus that often
- Most restaurants relied on calls or emails to make changes and a few still used fax
- The top pain points were long publishing times and communication issues
- The most common reasons for updates were running out of items or price changes, both of which required fast action
- The most requested features were the ability to turn items on or off, schedule availability and publish updates instantly
These insights clarified the direction. Restaurant managers did not want a complex data system. They wanted control and the confidence that updates would go live when they needed them.
We shifted the design focus toward features that offered speed and reassurance:
- A one-click availability toggle for marking items out of stock in seconds
- Instant publishing that pushed updates without waiting for support teams
- Scheduling tools for recurring changes such as lunch and dinner transitions
This feedback loop shaped our priorities in real time. Each prototype session focused on whether the interactions felt immediate and reliable. Could someone make a change mid-service under pressure without second-guessing it?
Each cycle brought us closer to that goal. By combining quantitative data with live usability testing, we built confidence that the Menu Editor addressed a real operational problem rather than a surface-level workflow gap.
Delivery
As we moved into handoff, I worked closely with engineering to ensure the build matched the intent of the design. We focused on pixel accuracy, consistency with the design system and smooth integration with the existing restaurant platform. The final prototypes were fully interactive, and every major flow was tested across breakpoints to confirm responsive behavior.
I also partnered with our UX writer to finalize error messages and state changes. The goal was to use clear, supportive language that helped users understand what was happening and why. These details were critical for building trust and reducing anxiety in moments where accuracy mattered most.
The screens that follow represent the finalized experience and the patterns that guided development across the product.
Users land in the Menu Editor after signing into Grubhub for Restaurants and see their full menu laid out in a clear grid. Items sit inside sections that can be expanded or collapsed so it’s easy to scan and navigate. Each item card can be selected to view or edit details, and the left sidebar gives direct access to broader tasks like creating items, editing sections or adjusting schedules. This structure helps restaurants manage large menus with less searching and fewer clicks.
Selecting a menu item opens a small action menu with options to adjust availability, edit details, preview how the item appears on Grubhub or create a copy. Copying is especially helpful when restaurants want to reuse an existing item as a starting point and speed up menu creation. These options give users quick access to the changes they make most often so they can keep their menus accurate without extra steps.
When a user selects an item, they see a focused action menu with the tasks they rely on most. They can adjust availability, make quick edits, preview the customer view or create a copy when they want to reuse an item as a starting point. These actions are grouped together to reduce repetitive work and help restaurants update their menus quickly and confidently.
Selecting Create Item opens the item editor where users can build everything in one place. They can upload a photo, write a description, enter calories, choose a section, set a schedule and control availability for coupons, group orders or catering. They can also add sizes, modifiers and tags along with the correct tax percentage so the item is ready the moment it goes live. This unified workflow gives restaurants a clear path from idea to published item without jumping between multiple screens.
Users choose when an item is available by selecting from schedules they have already created or by marking the item as always available. They can also create a new schedule from this view if they need more precise hours. This gives restaurants tighter control over what customers can order and helps prevent mistakes like items showing up during times when the kitchen cannot prepare them.
To help users work faster, sizes, modifiers and schedules are fully reusable. Once they create them, they can attach or remove these groups from any item with only a few clicks or taps. This reduces repetitive setup and keeps menu management consistent across items.
When editing modifiers, users can add or remove options from a group or update prices and calorie information in one place. They can also hide a modifier temporarily if the kitchen runs out of stock. This gives restaurants flexible control over their menu without needing to delete items or rebuild groups from scratch.
Users can set modifier prices on their own or tie them to the size of the item. This flexibility supports menus where prices change with portion size and helps restaurants keep their pricing consistent without managing separate modifier groups for every variation.
Users can also choose whether an item is available for coupons, group orders or catering. This helps restaurants control how each item appears across different order types and prevents situations where items show up in channels the kitchen cannot support.
Users can view a full preview of the item before saving and publishing it. From here, they can choose to make the item available right away or schedule it to go live at a later date. This final step helps restaurants validate content, pricing and options so the item reaches customers exactly the way they intend.
Impact
The Menu Editor shifted Grubhub from a manual, service-heavy workflow to a self-service system that scaled across the restaurant network. Adoption was fast and widespread. More than ten thousand restaurants were using the tool within three months of launch, which confirmed strong product-market fit and validated the core design decisions.
Support demand dropped sharply. Self-service updates reduced unavailable-item requests by more than half, which freed internal teams to focus on higher-value work. This change alone created a measurable improvement in operational efficiency across data and support teams.
Onboarding became faster. Restaurants could now publish complete menus without waiting for internal intervention, which cut the average setup time by five days. This improvement helped restaurants start earning revenue sooner and lowered the cost to bring new partners onto the platform.
The tool became a flagship product within Grubhub’s restaurant suite. Its reliability, scale and adoption set a new bar for how the company approached partner-facing tools. More importantly, it demonstrated the value of investing in systems that give restaurants real control of their data while maintaining accuracy across the broader platform.
Reflection
This project reshaped how I think about designing for real operational pressure. Working directly with restaurant managers and internal teams made it clear that the best tools do not overwhelm users with power. They remove friction, create clarity and protect people during moments when time and accuracy matter most. The Menu Editor reinforced the value of systems thinking, not as an abstract exercise but as a practical way to align design, engineering and operations around a shared model.
The work also strengthened my belief that autonomy and safety can coexist in a single experience. Giving restaurants more control required careful guardrails, clear communication and patterns that felt familiar even when the underlying structure was complex. That balance guided every decision.
What stayed with me most was the impact of small details. A phrase that lowered anxiety, a preview that built trust, a flow that saved a few seconds each day. These moments accumulate and shape how people feel about a product. They also shape how an organization understands the role of design.
This project made that visible. It showed that thoughtful systems, grounded in real user needs, can change the way a company operates and open the door for better tools that follow.
Let’s talk!
If you’re looking for thoughtful, outcomes-driven product design, I’d love to hear what you’re working on.
Say hi!
Empowering restaurants to manage their own menus on the Grubhub platform.
Results
10,000+ Restaurants
Adopted the tool within three months of launch, proving strong product-market fit.
50%+ Fewer Support Calls
Self-service menu updates cut unavailable-item requests by more than half.
5 Days Faster Onboarding
Reduced new-restaurant setup time from 15 to 10 days after contract signing.
Flagship Product
Named the leading tool in Grubhub’s restaurant suite for its impact and adoption.
Context
As Grubhub’s restaurant network grew, the company faced a serious operational bottleneck. Every menu update had to be entered manually by internal teams, and thousands of change requests came in each day. This slowed down onboarding for new restaurants and placed heavy pressure on data operations. Grubhub needed a scalable way for restaurants to manage their own menus while keeping data accurate across the platform so the business could move faster, lower operational costs and support growth at national scale.
Core Challenges
1. Complex and inconsistent data structures
Menus varied across thousands of restaurants with different naming conventions, modifiers, pricing tiers and availability rules. We needed a flexible system that could support all of these variations without overwhelming users, which required rethinking how menu data was organized and presented.
2. Legacy systems that limited speed and scalability
Internal tools were rigid and built for manual entry, not fast iteration. Our design had to work within these older systems while also creating a clear path toward automation and future integrations.
3. Two user groups with competing needs
Restaurant managers needed quick, intuitive actions during busy service hours. Internal data teams focused on accuracy, validation and accessibility. The interface needed to support both without splitting into separate experiences.
4. Simple on the surface with depth underneath
Menus could include long lists of modifiers, sizes and schedules, yet the tool still had to feel as easy as editing a document. Each interaction needed to hide technical complexity behind clear language and predictable behavior.
Who We Served
Restaurant Managers
Independent teams running daily operations who needed a fast and reliable way to manage menu availability, pricing and new items. Many worked from the back office or on a mobile device between orders, so the experience had to be quick and forgiving.
Internal Data and Support Teams
Specialists responsible for reviewing and publishing updates across thousands of listings. They needed tools that protected accuracy and compliance standards while reducing the amount of manual data entry required.
Grubhub Operations and Leadership
Stakeholders focused on efficiency and growth who needed a system that could onboard restaurants faster, lower operational costs and build trust with partners through transparency and autonomy.
Design Strategy
Our goal was to design a system that balanced speed, autonomy and accuracy at scale. Restaurants needed to manage their own data without worrying about breaking anything, and internal teams needed confidence that every edit would stay structured and compliant. The strategy centered on building a modular foundation that could support thousands of unique menus while still feeling simple and intuitive for anyone to use.
Empower restaurants through autonomy
We created a self-service platform that gave restaurants full control of their menu data and removed the bottleneck of manual data entry.
Simplify complexity through modular design
We built a menu system around reusable entities such as sizes, modifiers and schedules so restaurants could create and update items quickly while keeping structure and consistency intact.
Design for speed and transparency
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Build for scale, not only launch
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Definition of Success
Success for the Menu Editor was not about releasing a new feature. It was about changing how Grubhub operated. The company needed to move away from manual, service-heavy workflows and toward self-service systems that empowered restaurants without lowering data quality or trust. Every design choice was tied to measurable goals that balanced efficiency with experience.
Our success criteria focused on three areas: lowering support dependency, speeding up onboarding and protecting data accuracy at scale. Each goal was shared across design, engineering and operations.
1. Reduce dependency on manual support
Before this project, most menu updates required intervention from Grubhub’s data entry and support teams. This created long backlogs, slowed onboarding and frustrated restaurants.
Success meant giving restaurant managers the confidence to make their own updates quickly, safely and without creating errors. From a design point of view, this required:
- Structured input patterns that replaced open text fields so data stayed clean and consistent
- Inline validation and clear feedback that explained errors in real time
- Visual previews that showed exactly what diners would see before changes were published
A successful outcome was an experience where restaurants no longer needed help for basic actions and where each interaction built confidence rather than confusion.
2. Accelerate restaurant onboarding
Onboarding speed had a direct impact on how fast new restaurants could begin earning revenue. Each menu had to be entered, structured and approved before it could go live, and the process often took weeks because of manual steps and communication gaps.
Success meant removing friction at every point in that journey. The design needed to shorten the distance between intent and activation by:
- Creating guided setup flows that covered only what was essential
- Using clear progress indicators and contextual help to keep users oriented and reduce cognitive load
- Aligning design choices with operational workflows so restaurant inputs flowed cleanly into internal review systems
The real measure of success was a smoother onboarding process where restaurants could launch quickly with less back-and-forth and more confidence in their data.
3. Maintain data accuracy at scale
Grubhub’s menu data supported everything from search results to order fulfillment. A single mistake, such as an incorrect price or broken modifier, could cause issues across the system. The challenge was giving restaurants autonomy while preventing errors that could affect diners or operations.
This was both a design and engineering goal, but design played a major role in prevention:
- Controlled components and predefined categories that kept data consistent
- Preview and confirmation steps that helped users verify changes before publishing
- Contextual warnings and safe defaults that prevented actions that could break dependencies like removing a shared modifier or schedule
Design success meant scale without added risk. Restaurants could manage their data independently without increasing errors or instability in the system.
How We Worked
Our core team included two designers, twelve engineers, one product manager, one UX writer and one UX researcher. We moved quickly and iteratively with a shared goal of delivering a product that felt powerful and intuitive.
As Lead Designer, I owned the product vision, user experience and information architecture from concept to delivery. I partnered with our UX researcher to turn field insights into design priorities and with our writer to create a clear and approachable tone across the interface, especially in error states and system messages that could affect restaurant confidence.
Collaboration was constant. We held design reviews with engineers early in the process to check feasibility, while weekly working sessions with operations, support and data teams kept the work grounded in real workflows. Mentorship was also part of our rhythm. I paired closely with another designer on complex flows and helped them deepen their systems thinking while keeping quality strong across the product.
We ran ongoing testing with both internal and external users and iterated quickly based on feedback from real restaurant managers in the field. This loop kept the work fast, practical and closely tied to user value.
Process
Our process moved quickly but stayed grounded in evidence at every step. With a tight 12-week timeline, we focused on clear goals and fast decision cycles. I shaped the work around repeatable learning loops where research, design and validation informed one another in real time. This kept the team aligned, reduced uncertainty and allowed us to refine the experience until it worked smoothly for both restaurant managers and internal teams.
Research
Design
Validation
Discovery
We began by mapping the full menu lifecycle from restaurant onboarding to menu updates to diner visibility so we could identify where delays and errors originated. Our UX researcher and I ran on-site interviews with restaurant managers across Chicago, observing real workflows in kitchens and service lines. We also interviewed internal data, support and operations teams to understand how tickets moved through the system and where breakdowns were most common.
Clear patterns emerged:
- Many menu edits were not complex. They were urgent availability changes triggered by real operational needs.
- Internal teams were spending hours each day processing low-impact tickets, which slowed down high-value updates for restaurants with more complex menus.
- Managers struggled to see how changes would appear to diners until after publication, which often created duplicate submissions and unnecessary support cycles.
These findings defined where the product could create the most value. Restaurants needed more control and more visibility into how their menus behaved, and internal teams needed a cleaner data flow that reduced manual work. The graphs that follow helped us quantify these themes and set priorities. From there, the focus shifted to building a scalable architecture and a clear interaction model that could support thousands of unique menu structures without adding complexity for users.
How do you currently update your menu on Grubhub?
Call
4
2
Fax
1
Other
0
1
2
3
4
5
What are some of the biggest challenges your currently face with updating your menu on Grubhub?
Takes too long to publish
5
Comm. Issues
3
Errors
3
Communication
3
0
1
2
3
4
5
How often do you currently update your menu on Grubhub?
43%
14%
43%
DAILY
WEEKLY
MONTHLY
RARELY
How often do you currently update your physical store menu?
29%
14%
43%
14%
DAILY
WEEKLY
MONTHLY
RARELY
What are currently some of the biggest reasons for updating your menu on Grubhub?
Run out of item(s)
5+
Update Prices
5+
New Offerings
4
2
Showcase item(s)
0
1
2
3
4
5
What are some features you would like to see in a self-service menu tool?
Turn items “on or off”
5+
Scheduling
4
Responsive
2
Instant Publish
2
0
1
2
3
4
5
Information Architecture
Information architecture became the anchor for the entire system. With two user groups and a wide range of menu structures, the work depended on building a model that could absorb complexity without exposing it to users. We broke down how menus were structured in the legacy tools and examined the core entities that shaped every workflow. From there, we rebuilt these pieces into a modular framework that could scale without adding confusion to the interface.
Below are the key IA models that guided our decisions and aligned design, engineering and data operations.
Item Creation Flow
This flow mapped the complete lifecycle of creating an item, from basic details to schedules, sizes and modifier groups. It highlighted friction in the old workflow and revealed where reusable components could replace repeated manual steps. These insights shaped the modular editor that allowed users to create complex items quickly while keeping data structured.
System Entity Map
This model defined the core entities that powered the Menu Editor and how they connected across the platform. It brought clarity to a fragmented legacy system and created a shared understanding of the relationships between items, modifiers, sizes, schedules and categories. This alignment allowed engineering to build a consistent backend that supported thousands of unique menus without custom logic.
Section and Subcategory Flow
This diagram showed how section management connected to the item editor and exposed gaps that created inconsistencies in the menu. By visualizing these paths, we identified patterns that could cause errors, such as undefined schedules or missing size groups, and redesigned them into predictable, repeatable flows.
Design & Prototyping
With insights and the information architecture in place, I moved into low-fidelity wireframes to explore the core interactions that shaped the product. The goal was to translate a complex system into an experience that felt simple and immediate. Each concept focused on reducing steps, improving clarity and giving restaurants confidence in their updates.
Key patterns included:
- A quick blackout flow that allowed managers to mark items unavailable in seconds without losing their place
- Reusable entities that let users create or attach modifiers and schedules globally so they did not have to rebuild the same structures across multiple items
- Inline editing that supported fast updates with real-time validation
- A preview-first approach that showed managers exactly how their changes would appear to diners before publishing
This phase helped us validate what mattered most for speed and accuracy and gave the engineering team a clear direction for how the interactions needed to behave.
Once the core interactions felt solid, we shifted into high-fidelity prototypes in Sketch and InVision. I worked closely with our UX writer to refine microcopy that reduced user anxiety and with engineering to make sure the layouts behaved well on smaller screens. This phase tightened the details, clarified intent and set the standard for the visual and interaction patterns that would guide development.
Testing & Iteration
We ran multiple rounds of testing with restaurant managers and internal support teams and combined surveys, interviews and live prototype sessions to understand how menus were being managed in real environments.
The results reflected what we saw in discovery. Restaurants were working under constant time pressure and their tools were not keeping up.
Key findings included:
- 67% of respondents said they updated their physical menus weekly or daily, but only fourteen percent could update their Grubhub menus that often
- Most restaurants relied on calls or emails to make changes and a few still used fax
- The top pain points were long publishing times and communication issues
- The most common reasons for updates were running out of items or price changes, both of which required fast action
- The most requested features were the ability to turn items on or off, schedule availability and publish updates instantly
These insights clarified the direction. Restaurant managers did not want a complex data system. They wanted control and the confidence that updates would go live when they needed them.
We shifted the design focus toward features that offered speed and reassurance:
- A one-click availability toggle for marking items out of stock in seconds
- Instant publishing that pushed updates without waiting for support teams
- Scheduling tools for recurring changes such as lunch and dinner transitions
This feedback loop shaped our priorities in real time. Each prototype session focused on whether the interactions felt immediate and reliable. Could someone make a change mid-service under pressure without second-guessing it?
Each cycle brought us closer to that goal. By combining quantitative data with live usability testing, we built confidence that the Menu Editor addressed a real operational problem rather than a surface-level workflow gap.
Delivery
As we moved into handoff, I worked closely with engineering to ensure the build matched the intent of the design. We focused on pixel accuracy, consistency with the design system and smooth integration with the existing restaurant platform. The final prototypes were fully interactive, and every major flow was tested across breakpoints to confirm responsive behavior.
I also partnered with our UX writer to finalize error messages and state changes. The goal was to use clear, supportive language that helped users understand what was happening and why. These details were critical for building trust and reducing anxiety in moments where accuracy mattered most.
The screens that follow represent the finalized experience and the patterns that guided development across the product.
Users land in the Menu Editor after signing into Grubhub for Restaurants and see their full menu laid out in a clear grid. Items sit inside sections that can be expanded or collapsed so it’s easy to scan and navigate. Each item card can be selected to view or edit details, and the left sidebar gives direct access to broader tasks like creating items, editing sections or adjusting schedules. This structure helps restaurants manage large menus with less searching and fewer clicks.
Selecting a menu item opens a small action menu with options to adjust availability, edit details, preview how the item appears on Grubhub or create a copy. Copying is especially helpful when restaurants want to reuse an existing item as a starting point and speed up menu creation. These options give users quick access to the changes they make most often so they can keep their menus accurate without extra steps.
When a user selects an item, they see a focused action menu with the tasks they rely on most. They can adjust availability, make quick edits, preview the customer view or create a copy when they want to reuse an item as a starting point. These actions are grouped together to reduce repetitive work and help restaurants update their menus quickly and confidently.
Selecting Create Item opens the item editor where users can build everything in one place. They can upload a photo, write a description, enter calories, choose a section, set a schedule and control availability for coupons, group orders or catering. They can also add sizes, modifiers and tags along with the correct tax percentage so the item is ready the moment it goes live. This unified workflow gives restaurants a clear path from idea to published item without jumping between multiple screens.
Users choose when an item is available by selecting from schedules they have already created or by marking the item as always available. They can also create a new schedule from this view if they need more precise hours. This gives restaurants tighter control over what customers can order and helps prevent mistakes like items showing up during times when the kitchen cannot prepare them.
To help users work faster, sizes, modifiers and schedules are fully reusable. Once they create them, they can attach or remove these groups from any item with only a few clicks or taps. This reduces repetitive setup and keeps menu management consistent across items.
When editing modifiers, users can add or remove options from a group or update prices and calorie information in one place. They can also hide a modifier temporarily if the kitchen runs out of stock. This gives restaurants flexible control over their menu without needing to delete items or rebuild groups from scratch.
Users can set modifier prices on their own or tie them to the size of the item. This flexibility supports menus where prices change with portion size and helps restaurants keep their pricing consistent without managing separate modifier groups for every variation.
Users can also choose whether an item is available for coupons, group orders or catering. This helps restaurants control how each item appears across different order types and prevents situations where items show up in channels the kitchen cannot support.
Users can view a full preview of the item before saving and publishing it. From here, they can choose to make the item available right away or schedule it to go live at a later date. This final step helps restaurants validate content, pricing and options so the item reaches customers exactly the way they intend.
Impact
The Menu Editor shifted Grubhub from a manual, service-heavy workflow to a self-service system that scaled across the restaurant network. Adoption was fast and widespread. More than ten thousand restaurants were using the tool within three months of launch, which confirmed strong product-market fit and validated the core design decisions.
Support demand dropped sharply. Self-service updates reduced unavailable-item requests by more than half, which freed internal teams to focus on higher-value work. This change alone created a measurable improvement in operational efficiency across data and support teams.
Onboarding became faster. Restaurants could now publish complete menus without waiting for internal intervention, which cut the average setup time by five days. This improvement helped restaurants start earning revenue sooner and lowered the cost to bring new partners onto the platform.
The tool became a flagship product within Grubhub’s restaurant suite. Its reliability, scale and adoption set a new bar for how the company approached partner-facing tools. More importantly, it demonstrated the value of investing in systems that give restaurants real control of their data while maintaining accuracy across the broader platform.
Reflection
This project reshaped how I think about designing for real operational pressure. Working directly with restaurant managers and internal teams made it clear that the best tools do not overwhelm users with power. They remove friction, create clarity and protect people during moments when time and accuracy matter most. The Menu Editor reinforced the value of systems thinking, not as an abstract exercise but as a practical way to align design, engineering and operations around a shared model.
The work also strengthened my belief that autonomy and safety can coexist in a single experience. Giving restaurants more control required careful guardrails, clear communication and patterns that felt familiar even when the underlying structure was complex. That balance guided every decision.
What stayed with me most was the impact of small details. A phrase that lowered anxiety, a preview that built trust, a flow that saved a few seconds each day. These moments accumulate and shape how people feel about a product. They also shape how an organization understands the role of design.
This project made that visible. It showed that thoughtful systems, grounded in real user needs, can change the way a company operates and open the door for better tools that follow.
Let’s talk!
If you’re looking for thoughtful, outcomes-driven product design, I’d love to hear what you’re working on.
Say hi!
Empowering restaurants to manage their own menus on the Grubhub platform.
Results
10,000+ Restaurants
Adopted the tool within three months of launch, proving strong product-market fit.
50%+ Fewer Support Calls
Self-service menu updates cut unavailable-item requests by more than half.
5 Days Faster Onboarding
Reduced new-restaurant setup time from 15 to 10 days after contract signing.
Flagship Product
Named the leading tool in Grubhub’s restaurant suite for its impact and adoption.
Context
As Grubhub’s restaurant network grew, the company faced a serious operational bottleneck. Every menu update had to be entered manually by internal teams, and thousands of change requests came in each day. This slowed down onboarding for new restaurants and placed heavy pressure on data operations. Grubhub needed a scalable way for restaurants to manage their own menus while keeping data accurate across the platform so the business could move faster, lower operational costs and support growth at national scale.
Core Challenges
1. Complex and inconsistent data structures
Menus varied across thousands of restaurants with different naming conventions, modifiers, pricing tiers and availability rules. We needed a flexible system that could support all of these variations without overwhelming users, which required rethinking how menu data was organized and presented.
2. Legacy systems that limited speed and scalability
Internal tools were rigid and built for manual entry, not fast iteration. Our design had to work within these older systems while also creating a clear path toward automation and future integrations.
3. Two user groups with competing needs
Restaurant managers needed quick, intuitive actions during busy service hours. Internal data teams focused on accuracy, validation and accessibility. The interface needed to support both without splitting into separate experiences.
4. Simple on the surface with depth underneath
Menus could include long lists of modifiers, sizes and schedules, yet the tool still had to feel as easy as editing a document. Each interaction needed to hide technical complexity behind clear language and predictable behavior.
Who We Served
Restaurant Managers
Independent teams running daily operations who needed a fast and reliable way to manage menu availability, pricing and new items. Many worked from the back office or on a mobile device between orders, so the experience had to be quick and forgiving.
Internal Data and Support Teams
Specialists responsible for reviewing and publishing updates across thousands of listings. They needed tools that protected accuracy and compliance standards while reducing the amount of manual data entry required.
Grubhub Operations and Leadership
Stakeholders focused on efficiency and growth who needed a system that could onboard restaurants faster, lower operational costs and build trust with partners through transparency and autonomy.
Design Strategy
Our goal was to design a system that balanced speed, autonomy and accuracy at scale. Restaurants needed to manage their own data without worrying about breaking anything, and internal teams needed confidence that every edit would stay structured and compliant. The strategy centered on building a modular foundation that could support thousands of unique menus while still feeling simple and intuitive for anyone to use.
Empower restaurants through autonomy
We created a self-service platform that gave restaurants full control of their menu data and removed the bottleneck of manual data entry.
Simplify complexity through modular design
We built a menu system around reusable entities such as sizes, modifiers and schedules so restaurants could create and update items quickly while keeping structure and consistency intact.
Design for speed and transparency
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Build for scale, not only launch
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Definition of Success
Success for the Menu Editor was not about releasing a new feature. It was about changing how Grubhub operated. The company needed to move away from manual, service-heavy workflows and toward self-service systems that empowered restaurants without lowering data quality or trust. Every design choice was tied to measurable goals that balanced efficiency with experience.
Our success criteria focused on three areas: lowering support dependency, speeding up onboarding and protecting data accuracy at scale. Each goal was shared across design, engineering and operations.
1. Reduce dependency on manual support
Before this project, most menu updates required intervention from Grubhub’s data entry and support teams. This created long backlogs, slowed onboarding and frustrated restaurants.
Success meant giving restaurant managers the confidence to make their own updates quickly, safely and without creating errors. From a design point of view, this required:
- Structured input patterns that replaced open text fields so data stayed clean and consistent
- Inline validation and clear feedback that explained errors in real time
- Visual previews that showed exactly what diners would see before changes were published
A successful outcome was an experience where restaurants no longer needed help for basic actions and where each interaction built confidence rather than confusion.
2. Accelerate restaurant onboarding
Onboarding speed had a direct impact on how fast new restaurants could begin earning revenue. Each menu had to be entered, structured and approved before it could go live, and the process often took weeks because of manual steps and communication gaps.
Success meant removing friction at every point in that journey. The design needed to shorten the distance between intent and activation by:
- Creating guided setup flows that covered only what was essential
- Using clear progress indicators and contextual help to keep users oriented and reduce cognitive load
- Aligning design choices with operational workflows so restaurant inputs flowed cleanly into internal review systems
The real measure of success was a smoother onboarding process where restaurants could launch quickly with less back-and-forth and more confidence in their data.
3. Maintain data accuracy at scale
Grubhub’s menu data supported everything from search results to order fulfillment. A single mistake, such as an incorrect price or broken modifier, could cause issues across the system. The challenge was giving restaurants autonomy while preventing errors that could affect diners or operations.
This was both a design and engineering goal, but design played a major role in prevention:
- Controlled components and predefined categories that kept data consistent
- Preview and confirmation steps that helped users verify changes before publishing
- Contextual warnings and safe defaults that prevented actions that could break dependencies like removing a shared modifier or schedule
Design success meant scale without added risk. Restaurants could manage their data independently without increasing errors or instability in the system.
How We Worked
Our core team included two designers, twelve engineers, one product manager, one UX writer and one UX researcher. We moved quickly and iteratively with a shared goal of delivering a product that felt powerful and intuitive.
As Lead Designer, I owned the product vision, user experience and information architecture from concept to delivery. I partnered with our UX researcher to turn field insights into design priorities and with our writer to create a clear and approachable tone across the interface, especially in error states and system messages that could affect restaurant confidence.
Collaboration was constant. We held design reviews with engineers early in the process to check feasibility, while weekly working sessions with operations, support and data teams kept the work grounded in real workflows. Mentorship was also part of our rhythm. I paired closely with another designer on complex flows and helped them deepen their systems thinking while keeping quality strong across the product.
We ran ongoing testing with both internal and external users and iterated quickly based on feedback from real restaurant managers in the field. This loop kept the work fast, practical and closely tied to user value.
Process
Our process moved quickly but stayed grounded in evidence at every step. With a tight 12-week timeline, we focused on clear goals and fast decision cycles. I shaped the work around repeatable learning loops where research, design and validation informed one another in real time. This kept the team aligned, reduced uncertainty and allowed us to refine the experience until it worked smoothly for both restaurant managers and internal teams.
Research
Design
Validation
Discovery
We began by mapping the full menu lifecycle from restaurant onboarding to menu updates to diner visibility so we could identify where delays and errors originated. Our UX researcher and I ran on-site interviews with restaurant managers across Chicago, observing real workflows in kitchens and service lines. We also interviewed internal data, support and operations teams to understand how tickets moved through the system and where breakdowns were most common.
Clear patterns emerged:
- Many menu edits were not complex. They were urgent availability changes triggered by real operational needs.
- Internal teams were spending hours each day processing low-impact tickets, which slowed down high-value updates for restaurants with more complex menus.
- Managers struggled to see how changes would appear to diners until after publication, which often created duplicate submissions and unnecessary support cycles.
These findings defined where the product could create the most value. Restaurants needed more control and more visibility into how their menus behaved, and internal teams needed a cleaner data flow that reduced manual work. The graphs that follow helped us quantify these themes and set priorities. From there, the focus shifted to building a scalable architecture and a clear interaction model that could support thousands of unique menu structures without adding complexity for users.
How do you currently update your menu on Grubhub?
Call
4
2
Fax
1
Other
0
1
2
3
4
5
What are some of the biggest challenges your currently face with updating your menu on Grubhub?
Takes too long to publish
5
Comm. Issues
3
Errors
3
Communication
3
0
1
2
3
4
5
How often do you currently update your menu on Grubhub?
43%
14%
43%
DAILY
WEEKLY
MONTHLY
RARELY
How often do you currently update your physical store menu?
29%
14%
43%
14%
DAILY
WEEKLY
MONTHLY
RARELY
What are currently some of the biggest reasons for updating your menu on Grubhub?
Run out of item(s)
5+
Update Prices
5+
New Offerings
4
2
Showcase item(s)
0
1
2
3
4
5
What are some features you would like to see in a self-service menu tool?
Turn items “on or off”
5+
Scheduling
4
Responsive
2
Instant Publish
2
0
1
2
3
4
5
Information Architecture
Information architecture became the anchor for the entire system. With two user groups and a wide range of menu structures, the work depended on building a model that could absorb complexity without exposing it to users. We broke down how menus were structured in the legacy tools and examined the core entities that shaped every workflow. From there, we rebuilt these pieces into a modular framework that could scale without adding confusion to the interface.
Below are the key IA models that guided our decisions and aligned design, engineering and data operations.
Item Creation Flow
This flow mapped the complete lifecycle of creating an item, from basic details to schedules, sizes and modifier groups. It highlighted friction in the old workflow and revealed where reusable components could replace repeated manual steps. These insights shaped the modular editor that allowed users to create complex items quickly while keeping data structured.
System Entity Map
This model defined the core entities that powered the Menu Editor and how they connected across the platform. It brought clarity to a fragmented legacy system and created a shared understanding of the relationships between items, modifiers, sizes, schedules and categories. This alignment allowed engineering to build a consistent backend that supported thousands of unique menus without custom logic.
Section and Subcategory Flow
This diagram showed how section management connected to the item editor and exposed gaps that created inconsistencies in the menu. By visualizing these paths, we identified patterns that could cause errors, such as undefined schedules or missing size groups, and redesigned them into predictable, repeatable flows.
Design & Prototyping
With insights and the information architecture in place, I moved into low-fidelity wireframes to explore the core interactions that shaped the product. The goal was to translate a complex system into an experience that felt simple and immediate. Each concept focused on reducing steps, improving clarity and giving restaurants confidence in their updates.
Key patterns included:
- A quick blackout flow that allowed managers to mark items unavailable in seconds without losing their place
- Reusable entities that let users create or attach modifiers and schedules globally so they did not have to rebuild the same structures across multiple items
- Inline editing that supported fast updates with real-time validation
- A preview-first approach that showed managers exactly how their changes would appear to diners before publishing
This phase helped us validate what mattered most for speed and accuracy and gave the engineering team a clear direction for how the interactions needed to behave.
Once the core interactions felt solid, we shifted into high-fidelity prototypes in Sketch and InVision. I worked closely with our UX writer to refine microcopy that reduced user anxiety and with engineering to make sure the layouts behaved well on smaller screens. This phase tightened the details, clarified intent and set the standard for the visual and interaction patterns that would guide development.
Testing & Iteration
We ran multiple rounds of testing with restaurant managers and internal support teams and combined surveys, interviews and live prototype sessions to understand how menus were being managed in real environments.
The results reflected what we saw in discovery. Restaurants were working under constant time pressure and their tools were not keeping up.
Key findings included:
- 67% of respondents said they updated their physical menus weekly or daily, but only fourteen percent could update their Grubhub menus that often
- Most restaurants relied on calls or emails to make changes and a few still used fax
- The top pain points were long publishing times and communication issues
- The most common reasons for updates were running out of items or price changes, both of which required fast action
- The most requested features were the ability to turn items on or off, schedule availability and publish updates instantly
These insights clarified the direction. Restaurant managers did not want a complex data system. They wanted control and the confidence that updates would go live when they needed them.
We shifted the design focus toward features that offered speed and reassurance:
- A one-click availability toggle for marking items out of stock in seconds
- Instant publishing that pushed updates without waiting for support teams
- Scheduling tools for recurring changes such as lunch and dinner transitions
This feedback loop shaped our priorities in real time. Each prototype session focused on whether the interactions felt immediate and reliable. Could someone make a change mid-service under pressure without second-guessing it?
Each cycle brought us closer to that goal. By combining quantitative data with live usability testing, we built confidence that the Menu Editor addressed a real operational problem rather than a surface-level workflow gap.
Delivery
As we moved into handoff, I worked closely with engineering to ensure the build matched the intent of the design. We focused on pixel accuracy, consistency with the design system and smooth integration with the existing restaurant platform. The final prototypes were fully interactive, and every major flow was tested across breakpoints to confirm responsive behavior.
I also partnered with our UX writer to finalize error messages and state changes. The goal was to use clear, supportive language that helped users understand what was happening and why. These details were critical for building trust and reducing anxiety in moments where accuracy mattered most.
The screens that follow represent the finalized experience and the patterns that guided development across the product.
Users land in the Menu Editor after signing into Grubhub for Restaurants and see their full menu laid out in a clear grid. Items sit inside sections that can be expanded or collapsed so it’s easy to scan and navigate. Each item card can be selected to view or edit details, and the left sidebar gives direct access to broader tasks like creating items, editing sections or adjusting schedules. This structure helps restaurants manage large menus with less searching and fewer clicks.
Selecting a menu item opens a small action menu with options to adjust availability, edit details, preview how the item appears on Grubhub or create a copy. Copying is especially helpful when restaurants want to reuse an existing item as a starting point and speed up menu creation. These options give users quick access to the changes they make most often so they can keep their menus accurate without extra steps.
When a user selects an item, they see a focused action menu with the tasks they rely on most. They can adjust availability, make quick edits, preview the customer view or create a copy when they want to reuse an item as a starting point. These actions are grouped together to reduce repetitive work and help restaurants update their menus quickly and confidently.
Selecting Create Item opens the item editor where users can build everything in one place. They can upload a photo, write a description, enter calories, choose a section, set a schedule and control availability for coupons, group orders or catering. They can also add sizes, modifiers and tags along with the correct tax percentage so the item is ready the moment it goes live. This unified workflow gives restaurants a clear path from idea to published item without jumping between multiple screens.
Users choose when an item is available by selecting from schedules they have already created or by marking the item as always available. They can also create a new schedule from this view if they need more precise hours. This gives restaurants tighter control over what customers can order and helps prevent mistakes like items showing up during times when the kitchen cannot prepare them.
To help users work faster, sizes, modifiers and schedules are fully reusable. Once they create them, they can attach or remove these groups from any item with only a few clicks or taps. This reduces repetitive setup and keeps menu management consistent across items.
When editing modifiers, users can add or remove options from a group or update prices and calorie information in one place. They can also hide a modifier temporarily if the kitchen runs out of stock. This gives restaurants flexible control over their menu without needing to delete items or rebuild groups from scratch.
Users can set modifier prices on their own or tie them to the size of the item. This flexibility supports menus where prices change with portion size and helps restaurants keep their pricing consistent without managing separate modifier groups for every variation.
Users can also choose whether an item is available for coupons, group orders or catering. This helps restaurants control how each item appears across different order types and prevents situations where items show up in channels the kitchen cannot support.
Users can view a full preview of the item before saving and publishing it. From here, they can choose to make the item available right away or schedule it to go live at a later date. This final step helps restaurants validate content, pricing and options so the item reaches customers exactly the way they intend.
Impact
The Menu Editor shifted Grubhub from a manual, service-heavy workflow to a self-service system that scaled across the restaurant network. Adoption was fast and widespread. More than ten thousand restaurants were using the tool within three months of launch, which confirmed strong product-market fit and validated the core design decisions.
Support demand dropped sharply. Self-service updates reduced unavailable-item requests by more than half, which freed internal teams to focus on higher-value work. This change alone created a measurable improvement in operational efficiency across data and support teams.
Onboarding became faster. Restaurants could now publish complete menus without waiting for internal intervention, which cut the average setup time by five days. This improvement helped restaurants start earning revenue sooner and lowered the cost to bring new partners onto the platform.
The tool became a flagship product within Grubhub’s restaurant suite. Its reliability, scale and adoption set a new bar for how the company approached partner-facing tools. More importantly, it demonstrated the value of investing in systems that give restaurants real control of their data while maintaining accuracy across the broader platform.
Reflection
This project reshaped how I think about designing for real operational pressure. Working directly with restaurant managers and internal teams made it clear that the best tools do not overwhelm users with power. They remove friction, create clarity and protect people during moments when time and accuracy matter most. The Menu Editor reinforced the value of systems thinking, not as an abstract exercise but as a practical way to align design, engineering and operations around a shared model.
The work also strengthened my belief that autonomy and safety can coexist in a single experience. Giving restaurants more control required careful guardrails, clear communication and patterns that felt familiar even when the underlying structure was complex. That balance guided every decision.
What stayed with me most was the impact of small details. A phrase that lowered anxiety, a preview that built trust, a flow that saved a few seconds each day. These moments accumulate and shape how people feel about a product. They also shape how an organization understands the role of design.
This project made that visible. It showed that thoughtful systems, grounded in real user needs, can change the way a company operates and open the door for better tools that follow.
Let’s talk!
If you’re looking for thoughtful, outcomes-driven product design, I’d love to hear what you’re working on.
Say hi!
Empowering restaurants to manage their own menus on the Grubhub platform.
Results
10,000+ Restaurants
Adopted the tool within three months of launch, proving strong product-market fit.
50%+ Fewer Support Calls
Self-service menu updates cut unavailable-item requests by more than half.
5 Days Faster Onboarding
Reduced new-restaurant setup time from 15 to 10 days after contract signing.
Flagship Product
Named the leading tool in Grubhub’s restaurant suite for its impact and adoption.
Context
As Grubhub’s restaurant network grew, the company faced a serious operational bottleneck. Every menu update had to be entered manually by internal teams, and thousands of change requests came in each day. This slowed down onboarding for new restaurants and placed heavy pressure on data operations. Grubhub needed a scalable way for restaurants to manage their own menus while keeping data accurate across the platform so the business could move faster, lower operational costs and support growth at national scale.
Core Challenges
1. Complex and inconsistent data structures
Menus varied across thousands of restaurants with different naming conventions, modifiers, pricing tiers and availability rules. We needed a flexible system that could support all of these variations without overwhelming users, which required rethinking how menu data was organized and presented.
2. Legacy systems that limited speed and scalability
Internal tools were rigid and built for manual entry, not fast iteration. Our design had to work within these older systems while also creating a clear path toward automation and future integrations.
3. Two user groups with competing needs
Restaurant managers needed quick, intuitive actions during busy service hours. Internal data teams focused on accuracy, validation and accessibility. The interface needed to support both without splitting into separate experiences.
4. Simple on the surface with depth underneath
Menus could include long lists of modifiers, sizes and schedules, yet the tool still had to feel as easy as editing a document. Each interaction needed to hide technical complexity behind clear language and predictable behavior.
Who We Served
Restaurant Managers
Independent teams running daily operations who needed a fast and reliable way to manage menu availability, pricing and new items. Many worked from the back office or on a mobile device between orders, so the experience had to be quick and forgiving.
Internal Data and Support Teams
Specialists responsible for reviewing and publishing updates across thousands of listings. They needed tools that protected accuracy and compliance standards while reducing the amount of manual data entry required.
Grubhub Operations and Leadership
Stakeholders focused on efficiency and growth who needed a system that could onboard restaurants faster, lower operational costs and build trust with partners through transparency and autonomy.
Design Strategy
Our goal was to design a system that balanced speed, autonomy and accuracy at scale. Restaurants needed to manage their own data without worrying about breaking anything, and internal teams needed confidence that every edit would stay structured and compliant. The strategy centered on building a modular foundation that could support thousands of unique menus while still feeling simple and intuitive for anyone to use.
Empower restaurants through autonomy
We created a self-service platform that gave restaurants full control of their menu data and removed the bottleneck of manual data entry.
Simplify complexity through modular design
We built a menu system around reusable entities such as sizes, modifiers and schedules so restaurants could create and update items quickly while keeping structure and consistency intact.
Design for speed and transparency
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Build for scale, not only launch
We focused on clarity and feedback at every step. Users could mark items unavailable in seconds, preview changes before publishing and see item status without extra effort.
Definition of Success
Success for the Menu Editor was not about releasing a new feature. It was about changing how Grubhub operated. The company needed to move away from manual, service-heavy workflows and toward self-service systems that empowered restaurants without lowering data quality or trust. Every design choice was tied to measurable goals that balanced efficiency with experience.
Our success criteria focused on three areas: lowering support dependency, speeding up onboarding and protecting data accuracy at scale. Each goal was shared across design, engineering and operations.
1. Reduce dependency on manual support
Before this project, most menu updates required intervention from Grubhub’s data entry and support teams. This created long backlogs, slowed onboarding and frustrated restaurants.
Success meant giving restaurant managers the confidence to make their own updates quickly, safely and without creating errors. From a design point of view, this required:
- Structured input patterns that replaced open text fields so data stayed clean and consistent
- Inline validation and clear feedback that explained errors in real time
- Visual previews that showed exactly what diners would see before changes were published
A successful outcome was an experience where restaurants no longer needed help for basic actions and where each interaction built confidence rather than confusion.
2. Accelerate restaurant onboarding
Onboarding speed had a direct impact on how fast new restaurants could begin earning revenue. Each menu had to be entered, structured and approved before it could go live, and the process often took weeks because of manual steps and communication gaps.
Success meant removing friction at every point in that journey. The design needed to shorten the distance between intent and activation by:
- Creating guided setup flows that covered only what was essential
- Using clear progress indicators and contextual help to keep users oriented and reduce cognitive load
- Aligning design choices with operational workflows so restaurant inputs flowed cleanly into internal review systems
The real measure of success was a smoother onboarding process where restaurants could launch quickly with less back-and-forth and more confidence in their data.
3. Maintain data accuracy at scale
Grubhub’s menu data supported everything from search results to order fulfillment. A single mistake, such as an incorrect price or broken modifier, could cause issues across the system. The challenge was giving restaurants autonomy while preventing errors that could affect diners or operations.
This was both a design and engineering goal, but design played a major role in prevention:
- Controlled components and predefined categories that kept data consistent
- Preview and confirmation steps that helped users verify changes before publishing
- Contextual warnings and safe defaults that prevented actions that could break dependencies like removing a shared modifier or schedule
Design success meant scale without added risk. Restaurants could manage their data independently without increasing errors or instability in the system.
How We Worked
Our core team included two designers, twelve engineers, one product manager, one UX writer and one UX researcher. We moved quickly and iteratively with a shared goal of delivering a product that felt powerful and intuitive.
As Lead Designer, I owned the product vision, user experience and information architecture from concept to delivery. I partnered with our UX researcher to turn field insights into design priorities and with our writer to create a clear and approachable tone across the interface, especially in error states and system messages that could affect restaurant confidence.
Collaboration was constant. We held design reviews with engineers early in the process to check feasibility, while weekly working sessions with operations, support and data teams kept the work grounded in real workflows. Mentorship was also part of our rhythm. I paired closely with another designer on complex flows and helped them deepen their systems thinking while keeping quality strong across the product.
We ran ongoing testing with both internal and external users and iterated quickly based on feedback from real restaurant managers in the field. This loop kept the work fast, practical and closely tied to user value.
Process
Our process moved quickly but stayed grounded in evidence at every step. With a tight 12-week timeline, we focused on clear goals and fast decision cycles. I shaped the work around repeatable learning loops where research, design and validation informed one another in real time. This kept the team aligned, reduced uncertainty and allowed us to refine the experience until it worked smoothly for both restaurant managers and internal teams.
Research
Design
Validation
Discovery
We began by mapping the full menu lifecycle from restaurant onboarding to menu updates to diner visibility so we could identify where delays and errors originated. Our UX researcher and I ran on-site interviews with restaurant managers across Chicago, observing real workflows in kitchens and service lines. We also interviewed internal data, support and operations teams to understand how tickets moved through the system and where breakdowns were most common.
Clear patterns emerged:
- Many menu edits were not complex. They were urgent availability changes triggered by real operational needs.
- Internal teams were spending hours each day processing low-impact tickets, which slowed down high-value updates for restaurants with more complex menus.
- Managers struggled to see how changes would appear to diners until after publication, which often created duplicate submissions and unnecessary support cycles.
These findings defined where the product could create the most value. Restaurants needed more control and more visibility into how their menus behaved, and internal teams needed a cleaner data flow that reduced manual work. The graphs that follow helped us quantify these themes and set priorities. From there, the focus shifted to building a scalable architecture and a clear interaction model that could support thousands of unique menu structures without adding complexity for users.
How do you currently update your menu on Grubhub?
Call
4
2
Fax
1
Other
0
1
2
3
4
5
What are some of the biggest challenges your currently face with updating your menu on Grubhub?
Takes too long to publish
5
Comm. Issues
3
Errors
3
Communication
3
0
1
2
3
4
5
How often do you currently update your menu on Grubhub?
43%
14%
43%
DAILY
WEEKLY
MONTHLY
RARELY
How often do you currently update your physical store menu?
29%
14%
43%
14%
DAILY
WEEKLY
MONTHLY
RARELY
What are currently some of the biggest reasons for updating your menu on Grubhub?
Run out of item(s)
5+
Update Prices
5+
New Offerings
4
2
Showcase item(s)
0
1
2
3
4
5
What are some features you would like to see in a self-service menu tool?
Turn items “on or off”
5+
Scheduling
4
Responsive
2
Instant Publish
2
0
1
2
3
4
5
Information Architecture
Information architecture became the anchor for the entire system. With two user groups and a wide range of menu structures, the work depended on building a model that could absorb complexity without exposing it to users. We broke down how menus were structured in the legacy tools and examined the core entities that shaped every workflow. From there, we rebuilt these pieces into a modular framework that could scale without adding confusion to the interface.
Below are the key IA models that guided our decisions and aligned design, engineering and data operations.
Item Creation Flow
This flow mapped the complete lifecycle of creating an item, from basic details to schedules, sizes and modifier groups. It highlighted friction in the old workflow and revealed where reusable components could replace repeated manual steps. These insights shaped the modular editor that allowed users to create complex items quickly while keeping data structured.
System Entity Map
This model defined the core entities that powered the Menu Editor and how they connected across the platform. It brought clarity to a fragmented legacy system and created a shared understanding of the relationships between items, modifiers, sizes, schedules and categories. This alignment allowed engineering to build a consistent backend that supported thousands of unique menus without custom logic.
Section and Subcategory Flow
This diagram showed how section management connected to the item editor and exposed gaps that created inconsistencies in the menu. By visualizing these paths, we identified patterns that could cause errors, such as undefined schedules or missing size groups, and redesigned them into predictable, repeatable flows.
Design & Prototyping
With insights and the information architecture in place, I moved into low-fidelity wireframes to explore the core interactions that shaped the product. The goal was to translate a complex system into an experience that felt simple and immediate. Each concept focused on reducing steps, improving clarity and giving restaurants confidence in their updates.
Key patterns included:
- A quick blackout flow that allowed managers to mark items unavailable in seconds without losing their place
- Reusable entities that let users create or attach modifiers and schedules globally so they did not have to rebuild the same structures across multiple items
- Inline editing that supported fast updates with real-time validation
- A preview-first approach that showed managers exactly how their changes would appear to diners before publishing
This phase helped us validate what mattered most for speed and accuracy and gave the engineering team a clear direction for how the interactions needed to behave.
Once the core interactions felt solid, we shifted into high-fidelity prototypes in Sketch and InVision. I worked closely with our UX writer to refine microcopy that reduced user anxiety and with engineering to make sure the layouts behaved well on smaller screens. This phase tightened the details, clarified intent and set the standard for the visual and interaction patterns that would guide development.
Testing & Iteration
We ran multiple rounds of testing with restaurant managers and internal support teams and combined surveys, interviews and live prototype sessions to understand how menus were being managed in real environments.
The results reflected what we saw in discovery. Restaurants were working under constant time pressure and their tools were not keeping up.
Key findings included:
- 67% of respondents said they updated their physical menus weekly or daily, but only fourteen percent could update their Grubhub menus that often
- Most restaurants relied on calls or emails to make changes and a few still used fax
- The top pain points were long publishing times and communication issues
- The most common reasons for updates were running out of items or price changes, both of which required fast action
- The most requested features were the ability to turn items on or off, schedule availability and publish updates instantly
These insights clarified the direction. Restaurant managers did not want a complex data system. They wanted control and the confidence that updates would go live when they needed them.
We shifted the design focus toward features that offered speed and reassurance:
- A one-click availability toggle for marking items out of stock in seconds
- Instant publishing that pushed updates without waiting for support teams
- Scheduling tools for recurring changes such as lunch and dinner transitions
This feedback loop shaped our priorities in real time. Each prototype session focused on whether the interactions felt immediate and reliable. Could someone make a change mid-service under pressure without second-guessing it?
Each cycle brought us closer to that goal. By combining quantitative data with live usability testing, we built confidence that the Menu Editor addressed a real operational problem rather than a surface-level workflow gap.
Delivery
As we moved into handoff, I worked closely with engineering to ensure the build matched the intent of the design. We focused on pixel accuracy, consistency with the design system and smooth integration with the existing restaurant platform. The final prototypes were fully interactive, and every major flow was tested across breakpoints to confirm responsive behavior.
I also partnered with our UX writer to finalize error messages and state changes. The goal was to use clear, supportive language that helped users understand what was happening and why. These details were critical for building trust and reducing anxiety in moments where accuracy mattered most.
The screens that follow represent the finalized experience and the patterns that guided development across the product.
Users land in the Menu Editor after signing into Grubhub for Restaurants and see their full menu laid out in a clear grid. Items sit inside sections that can be expanded or collapsed so it’s easy to scan and navigate. Each item card can be selected to view or edit details, and the left sidebar gives direct access to broader tasks like creating items, editing sections or adjusting schedules. This structure helps restaurants manage large menus with less searching and fewer clicks.
Selecting a menu item opens a small action menu with options to adjust availability, edit details, preview how the item appears on Grubhub or create a copy. Copying is especially helpful when restaurants want to reuse an existing item as a starting point and speed up menu creation. These options give users quick access to the changes they make most often so they can keep their menus accurate without extra steps.
When a user selects an item, they see a focused action menu with the tasks they rely on most. They can adjust availability, make quick edits, preview the customer view or create a copy when they want to reuse an item as a starting point. These actions are grouped together to reduce repetitive work and help restaurants update their menus quickly and confidently.
Selecting Create Item opens the item editor where users can build everything in one place. They can upload a photo, write a description, enter calories, choose a section, set a schedule and control availability for coupons, group orders or catering. They can also add sizes, modifiers and tags along with the correct tax percentage so the item is ready the moment it goes live. This unified workflow gives restaurants a clear path from idea to published item without jumping between multiple screens.
Users choose when an item is available by selecting from schedules they have already created or by marking the item as always available. They can also create a new schedule from this view if they need more precise hours. This gives restaurants tighter control over what customers can order and helps prevent mistakes like items showing up during times when the kitchen cannot prepare them.
To help users work faster, sizes, modifiers and schedules are fully reusable. Once they create them, they can attach or remove these groups from any item with only a few clicks or taps. This reduces repetitive setup and keeps menu management consistent across items.
When editing modifiers, users can add or remove options from a group or update prices and calorie information in one place. They can also hide a modifier temporarily if the kitchen runs out of stock. This gives restaurants flexible control over their menu without needing to delete items or rebuild groups from scratch.
Users can set modifier prices on their own or tie them to the size of the item. This flexibility supports menus where prices change with portion size and helps restaurants keep their pricing consistent without managing separate modifier groups for every variation.
Users can also choose whether an item is available for coupons, group orders or catering. This helps restaurants control how each item appears across different order types and prevents situations where items show up in channels the kitchen cannot support.
Users can view a full preview of the item before saving and publishing it. From here, they can choose to make the item available right away or schedule it to go live at a later date. This final step helps restaurants validate content, pricing and options so the item reaches customers exactly the way they intend.
Impact
The Menu Editor shifted Grubhub from a manual, service-heavy workflow to a self-service system that scaled across the restaurant network. Adoption was fast and widespread. More than ten thousand restaurants were using the tool within three months of launch, which confirmed strong product-market fit and validated the core design decisions.
Support demand dropped sharply. Self-service updates reduced unavailable-item requests by more than half, which freed internal teams to focus on higher-value work. This change alone created a measurable improvement in operational efficiency across data and support teams.
Onboarding became faster. Restaurants could now publish complete menus without waiting for internal intervention, which cut the average setup time by five days. This improvement helped restaurants start earning revenue sooner and lowered the cost to bring new partners onto the platform.
The tool became a flagship product within Grubhub’s restaurant suite. Its reliability, scale and adoption set a new bar for how the company approached partner-facing tools. More importantly, it demonstrated the value of investing in systems that give restaurants real control of their data while maintaining accuracy across the broader platform.
Reflection
This project reshaped how I think about designing for real operational pressure. Working directly with restaurant managers and internal teams made it clear that the best tools do not overwhelm users with power. They remove friction, create clarity and protect people during moments when time and accuracy matter most. The Menu Editor reinforced the value of systems thinking, not as an abstract exercise but as a practical way to align design, engineering and operations around a shared model.
The work also strengthened my belief that autonomy and safety can coexist in a single experience. Giving restaurants more control required careful guardrails, clear communication and patterns that felt familiar even when the underlying structure was complex. That balance guided every decision.
What stayed with me most was the impact of small details. A phrase that lowered anxiety, a preview that built trust, a flow that saved a few seconds each day. These moments accumulate and shape how people feel about a product. They also shape how an organization understands the role of design.
This project made that visible. It showed that thoughtful systems, grounded in real user needs, can change the way a company operates and open the door for better tools that follow.
Let’s talk!
If you’re looking for thoughtful, outcomes-driven product design, I’d love to hear what you’re working on.
Say hi!