Consumer facing native app & web app dashboards 

How might we make food delivery smarter & more efficient?

I joined Zume to lead product design for the forward mobile team. At the time, the company had two other product designers. One on the design system team and another helped the sales team build data visualization tools.

My team built admin dashboards for operations staff, consumer apps for ordering food, and kitchen display systems for order tickets.

The company launched a successful pizza business using high tech mobile cloud kitchens while partnering with last mile partners such as Uber Eats, Door Dash and Postmates.  

Our new challenge was to re-design our internal tools for new customers in the food industry. Big corporate brands and smaller restaurant chains who wanted to test new markets & menu concepts with our high tech food trucks. 

Zume, 2019

Scope: 12 weeks to research, design & build a new set of customer-facing web apps.

Role: I led product design from research to implementation as individual contributor.

Team: Myself as lead product designer, 3 PMs and 19 developers.  I worked closely with a second product designer from the design system team.

Type: UX research & prototyping, UI design. 

Tools: Figma, storybook, whimsical, flow diagrams.

Why solve this problem?

Pain points

Restaurants have partnered with third party deliveries to meet customer demand, but have lost control over aspects of the business that matter most— customer service & food quality.

Top restaurant chains & rising independent brands are experts in making really estate decisions to build new stores in order to grow, but this process was to slow to support food delivery demand.

Opportunity

If restaurants used Zume's high tech food trucks and software to make smart bets about where and when to deploy these mobile kitchens then companies could improve the wait time and food quality for deliveries for customers. The businesses could learn from experiments about menu offerings at key times in new markets and make better decisions quicker.

What we already knew

The team at Zume spent had spent the last three years building up a high tech pizza delivery business and built all the necessary tools to handle logistical and operational concerns and make smart decisions about food delivery.

What we didn't know

The team felt confident that our technology platform of mobile kitchen hardware and software could help other businesses do the same. But we weren't what companies might be considering when making such a big decision.

What we might be wrong about

The team at Zume was confident that what we'd learned about building a high tech pizza business could be generalized and used by other restaurants.

But just because the company understood the business of cooking pizza didn't necessarily mean we could solve all the food prep and ordering problems of restaurants who make other types of food and might want to lease Zume's hardware and and software as a platform. 

Discovery

The team knew a lot about building for our core pizza business but much less about the needs of external customers. We didn't have any yet.

Because the team would need more customer insights to do good product work, I worked with my PM to plan a three week research sprint ahead of the build cycle.

Contextual Interviews

I started by visiting Zume pizza's operations, logistics and marketing staff to observe how they used the set of tools in context. The product & engineering team already had a pretty good idea of which tools were still relevant and what could be improved, but I wanted to take a step back and look at how each tool was used across key flows.

At the same time, I reached out to stakeholders from sales & culinary teams to learn more about our customers through them. They were currently giving demos of our technology to sales leads and could be used as a proxy for researching those customer leads directly. The sales team might be a useful proxy for a CTO or CMO type from a large brand.

It turned out that many have them had previously worked at the restaurant brands we were targeting and had lead marketing or culinary at some top restaurant brands. With all of this I wanted to envision what a customer journey with Zume might look like and how we could focus on building out the tools incrementally to support the steps on this journey that might make the biggest difference.

I invited all 3 PMs and each of the three engineering teams to the research appointments. Because the interviews were remote, it was easy for them to pop in or out to observe and ask or answer questions. At least half of the team sat in on one or more of the sessions.

Competitive Research

At the same time I dug deep into the top software that our customers were already using. Our tools would need to integrate with or replace many of these tools. I scheduled some on-site interviews with potential customers such as SweetGreen, Chipotle and Umami Burger. Just as useful was to publicly available training videos made by the software companies.

I captured some key flows as low fidelity design artifacts and created similar artifacts to represent what the team might want to build.
 

A customer journey map to consolidate the research and help the team decide what and what not to build first and why.

I observed workflows that touched many different tools in a few minutes & aimed for a more cohesive UX with the new tools.

I captured copy-only flows of similar software and used this approach to propose how we might build out the tool.

Defining the problem

To support our core business while optimizing for new customers.

Rather than design a separate suite of tools, we decided to redesign our core tools so that they were optimized for the customers we hoped to have. So these new tools would still need to support the existing core business of Zume's pizza delivery company.

One way to do this would be to prioritize the tools and redesign them one by one, but we wanted to focus on growth and support the sales process by designing for what we knew about existing sales leads.

How might we partner with top brands to make food delivery smarter & more efficient? 

The core team decide to focus on the toolset that was concerned with ingredients and menu items so that customers could maintain customer facing menus and make sure kitchen staff was stocked and prepared to make the food.

There were some other tools that might be nice to have as well, so I wireframed out how these tools might look and interconnect with each other.

One less obvious, but important entry point to adding or editing a food item was through a customer facing menu.

The advantage of using customer facing menu as entry point is that the user could understand changes in context.

It could be useful to surface some of the fields within the menu (rather than the menu item page) for common changes.

Once I shaped the basic flows with the core team, we started planning out the upcoming build cycle. While we did this, I worked up some higher fidelity variations of the menu entry point. 

Variation 1: All the top point of sale tools used a table-based design pattern for their systems. If we did the same, our customers wouldn't have to learn a new mental model.

Variation 2: I focused on previewing the end customer experience of ordering. 

Variation 3: With compact cards we could offer key details so admins could compare and double-check across their many menus.

Even though the menu items & ingredients toolset was core to business operations and an important first step in setup, I wanted to begin to explore some of our other internal tools. If we could use them to support sales, they might prove even more important than the core tools.

Must have: Tooling for customer facing menu items and ingredients. So customers can order and so ingredients for menu items are available for cooks.

Nice to have: Demographics for area within a given drivetime of a kitchen location.

Nice to have: Customer facing operations tools for staff to support logistics for each mobile kitchen.

In my research with the sales team, I found that one of our internal tools for placing trucks in ideal locations might help with sales. Even though this tool was slated to be redesigned later, I talked to my PM about working up some designs so that we could consider building this sooner than planned.

Step 1: Review demographics of map areas to estimate the opportunity of placing a mobile cloud kitchen.

Step 2: Estimate the delivery ranges of those locations by time of day and day of week.

Step 3: Factor in competition for food delivery for a given set of locations.

I reviewed the mocks with the core team and we decided to ask a few engineers from the team to rough in the map tool so we could consider things further and test it out on a local server.

The sales team was excited by these early efforts and the PM and I decided that I should prototype things out further.

Step 1: Side filter handles are set so that no data is filtered by default. 

Step 2: The map centers and zooms on the address that is entered.

Step 3: If competitor food types are selected, pins appear on map to indicate locations.

Competitor drive time radius can be turned on to indicate radius for each.

Delivery area tab is an alternative to delivery radius.

Competitor data appears as an area as well. Proposed store location sits on top layer and is translucent. 

Because the second tool had potential to support the sales team, the core group discussed adding this upcoming build cycle. It wasn't difficult to estimate how much engineering time this tool would add. We already had a roughed-in tool that worked. On the other hand, this tool would benefit from intensive front-end engineering work to get the UX right, so we talked to another team about pulling some engineers over.

The initial plan was to build out the most foundational tools first and tools like this later. But we discovered a big opportunity in using this tools to support sales and customer adoption. 

Outcome

As the product team moved into implementation on the menu tools, the sales team was already offering demos of work in progress map tool and signing new customers.

By offering these tools as part of a technology platform as a service the team increased the number of monthly deliveries by more than 300% and grew monthly revenue by 1.5x. 

Success story: A fast growing pizza chain was the first businesses to sign up to use the new platform as a service Link to Video.

Impact

Companies that adopt new ways to prepare and deliver food using Zume's cloud connected mobile kitchens are in a better position to adapt and respond to emerging challenges and opportunities.

In March of 2020 Zume's first customer set up a cloud connected mobile kitchen near area hospitals and gave away over 15,000 pizzas to support medical workers.

Update: In spring of 2020, one of the first customers from this project used Zume's cloud connected mobile kitchens in adaptive new ways to respond to challenged of the covid-19 pandemic.

More Case Studies