1. New Model for a Food Ordering App

I didn't know what design was when I began the graphic design program at UW so long ago. I had transferred from the University of Montana as a fine arts major, and our tools were rubber cement and Xacto knives instead of paint and brushes. The design problems in the first year's courses stymied me. I kept looking for a spark of inspiration instead of a problem-solving process.

Over time I learned these fundamental lessons from classwide critiques:

Although at that time we were learning to design purely visual, static solutions, these axioms still translate to the design of interactive products:

This process needn't be formal, it doesn't have to produce artifacts, and it can be done alone. I use it in thought experiments to break a problem into parts so I can see how they fit together and interact with each other as a system. Then I break the model and rearrange the parts in fun and useful new ways.

That's the process I used to come up with this project, a new twist on food ordering apps.

There's a television show on the Food Network called Beat Bobby Flay. The premise of the program is that a guest chef challenges Bobby Flay in a timed cookoff to create a dish of the guest chef's choice. There are no recipes they must follow. There is only a time limit. When the time limit expires a panel of judges tastes both chefs' dishes and picks the winner.

I began to riff on how I could could adapt and apply this premise to online food ordering.

Participating restaurants agree to offer a certain dish for delivery through the app for a certain price for a certain length of time, probably a week, but there are no rules on how to make it.

Users can order the dish of the week from any of the participating restaurants. They can order as many times as they like from one or any combination of the restaurants. All users are asked to rate each of their orders. At the end of the week the winning restaurant is announced based on user ratings: "restaurant X makes the best version of dish Y" in a given geographic area possibly defined by ZIP codes.

There are no requirements for non-winning restaurants after the contest ends. The winning restaurant is required to continue to offer the dish at the contest price for a set period of time, maybe a month or thereabouts, but only to customers who rated a dish in the contest using the app. Other customers are charged a higher price. After the end of the month-long time period the winning restaurant no longer must honor the contest price. They can continue offering the dish at the contest price for app users who rated a dish in the contest, or they can raise the price, change the recipe, or even drop the dish if they like. Each week a new dish is announced and a new contest begins.

Restaurants have incentive to participate as a form of advertising, fear of being left out, and to make a good dish at a low price to compete in the game. For users, the app solves the problem of "What's for dinner?", saves money, introduces new restaurants and cuisines, and helps ensure high-quality meals.

Participating restaurants are incented to play by the rules by ongoing user ratings, reviews, and comments in the app and other social media.

 

User Flows

There are two classes of users: Food Orderers and Restaurants. They have separate user flows:

I've decided for now to call the app Rate the Dish!, but the name is not as important as the concept. The concept comprises one or more concurrent contests, each lasting the same period of time. When the time period expires it repeats with new contests in a continuing cycle. Each contest is a competition among restaurants to prepare the best version of a certain dish for a set price. Each participating restaurant's goal is to win the highest user rating for their version of that contest's dish. Each contest entails a trailing special price offer from the contest-winning restaurant. The price offer expires after a set period of time, and is available only to users who participated in that contest by ordering and rating a dish in that contest. The winning dish also may be offered to users who did not rate a dish in that contest, and to the general public, but at a higher price. The lengths of the time periods for the contests and for the trailing price offers, as well as the number of contests in each contest period, are all important considerations for a succcessful product and user experience.

A too-long time period for trailing price offers and/or too many contests per period could result in too much information to display, overwhelming the user. Not enough contest dishes per period may provide too few choices. Too-short time periods for contests and trailing price offers would limit participation. How much lead time a restaurant would need to prepare for a contest after opting in is also an important consideration. And so forth. It may be necessary to iterate on these variables to optimize the design. For the initial version I decided to go with what made sense to me. I haven't done any user testing yet.

I initially was concerned about how to make it a fair contest, i.e., a "blind taste test." Basically, it was a question of how much information to display in the contest menu's restaurants list. Should users know the names of the restaurants? Should they see a picture of each restaurant's version of the dish? And a description of each restaurant's version of the dish? Would any of this information unfairly influence how many and which restaurants receive orders and ratings for their dish? Would requiring this information be a burden for restaurants? After agonizing over these questions and considering several alternative designs I finally decided that users would probably want to see pictures and descriptions and know the restaurant names. And fairness, or whether it was truly a blind taste test, would probably be of little concern to them. Restaurants would know this, too. The app makes no claims about the scientific validity of the contests.

 

Time Periods and Number of Dishes

How long should each contest last? Common terms for time periods indicate how we think about duration: seconds, minutes, hours, days, weeks, months, etc. One week makes the most sense for the duration of each contest. Then how long should the trailing price offer last? One month makes the most sense. Then how many dishes/contests per week? One would not be enough, nor two. Three might be okay, but why stop there? All the options seem arbitrary until you get to seven: one for each day of the week. But is seven too many? It might depend on the length of time before the trailing offers expire.

If trailing offers last one month after each contest then that's four weeks. At seven dishes/contests per week there would be: 4 weeks x 7 dishes/week = 28 current price offers from past winners at any given time, plus 7 contest dishes for the current week. That seems like too many choices. And how would navigation work for each week's contests and four weeks' worth of trailing price offers from past winners? I had a vision of quickly browsing through all the offers, but putting all the past winners in one list would make that difficult. Items near the top of the list would be unfairly advantaged, and there would be too many items for users to easily scan and digest the information.

If 28 is too many items for 1 list, an alternative is to split the list into 4 lists, one for each week of past winners. This also provides a tidy concept for navigation: Current Week, Past Week 1, Past Week 2, etc. But with trailing offers lasting a month there are 4 weeks of past winners, plus the current week. 5 weeks does not fit nicely into our list of time-period terms, and 28 still might be too many past winners. Cutting the trailing-offer time period from 1 month to 3 weeks solves both problems. And 7 still seems right as the number of dishes/contests per week:

 

This concept represents a fundamental change in the standard model for ordering food from a restaurant. Instead of many restaurants, each with its own menu and prices, there is one new menu with set prices each week for many restaurants, and the restaurants compete to make the best version of each dish on the menu. The app's weekly competitions could be a win-win for both users and restaurants with many dimensions for strategy, game-play, and financial rewards. It has potential to grow into more than just a utility for ordering food delivery. It's not unreasonable to think it could gain a social following and even become a community. The app could earn revenue by charging a small percentage of each order, but might also sell market data, including data from user voting on future dishes and prices, and perhaps advertising.

 

Future Dishes and Prices

In keeping with the spirit of putting users in control, the dishes and prices for each week's contests are decided in advance by user voting. In-app Price Credits are included as an extra incentive for users to vote on future dishes. One Price Credit can be used to change the price of a past winner to its contest price if you didn't rate a dish in its contest.

Users can nominate up to seven dishes each week to appear in a future week's contest. They also can choose their preferred price for each dish from a price range. The price range for each dish is determined by an algorithm based on average prices for the same general dish in a given geographic area.

Since there are no rules on how restaurants must prepare the dish they are free to strategize by varying their recipe, ingredients, serving size, and non-contest price, among other variables. Of course after the contest's submission deadline has passed restaurants cannot make any further changes to their dish.

Restaurants can use the app to create an account, to opt in or out of each week's contests, and to upload the required items for each dish they opt in to. There could also be an opportunity for a desktop companion app for restaurants with a dashboard of KPIs and other metrics, and/or integration with popular restaurant POS systems.

 

Opting In

Once the dishes and prices have been decided restaurants can use the app to opt in or out of the contest for each dish. It's unknown how much time restaurants would need to prepare for the contest, but three weeks seems sufficient. The app's requirements for participating restaurants include submitting a description of the restaurant's version of the contest dish, a photo of the dish, and the non-contest price for the dish.

3 weeks is consistent with the length of time for trailing price offers, and works out nicely for the complete cycle. If it is learned that 2 weeks is viable the cycle could be shortened by a week, etc. Less time between user voting for future dishes and seeing the results appear as the weekly contest is desirable if it doesn't impact restaurants' ability to participate:

The repeating contest cycle

 

Restaurant Participation

The minimum viable product would require participating restaurants, but participation could be disruptive for many restaurants' current business models and procedures. In general, it seems the more systematized/less agile a restaurant's business operation is, the less suitable it may be for this new model.

However, the restaurant industry is quickly evolving. Delivery-only "ghost" restaurants, pop-ups, licensing, virtual brands, and virtual kitchens are just some of the recent industry trends creating a new breed of eateries. I believe Rate the Dish! could find initial acceptance among this new class of restaurants and in doing so light the way for older establishments to adapt.

I made an interactive Figma prototype of the Food Orderers' flow. Here are the main screen designs:

Order Food, This Week's Menu

Order Food, Past Winners

Future Dishes

How It Works

Other Features

 

This concept offers a novel spin for online food ordering at a critical moment of opportunity in the food delivery business. Food delivery apps have never been so popular and in demand as they are now due to the Covid-19 pandemic, and it's beginning to appear that the pandemic may continue indefinitely as new variants of the virus come and go. Even if the pandemic ends it's doubtful that many patterns of daily life will return to the way they were before. Increased reliance on food delivery may become a permanent part of how we live.

The background conditions of technology, economy, work, and wages had already created a large market opportunity for food delivery apps: Busy professionals face a pressing daily problem of "What's for dinner at a reasonable cost of money, time, and effort?" Rate the Dish! addresses this need in an engaging new way that saves time and money for users and is also a new sales and marketing opportunity for restaurants.

This project began as a humble portfolio idea, and I hadn't thought about it as anything more, but when I received encouragement from the few people I showed it to I decided I should try to make it real. I don't have prior experience as a developer or a founder so I'm currently considering how best to proceed.

 

Strategy

It's easy to imagine the app being a success if it were up and running with a sufficient number of participating restaurants. However, it might initially be difficult to persuade restaurants to participate. Also, the app would need to partner with a delivery service or build its own. An existing relationship with the restaurant industry would be extremely advantageous in addressing these issues.

The competitive environment and current interest in restaurant delivery opportunities make it urgent to expedite development. Time is of the essence in achieving operational status.

For these reasons, acquisition or partnership with an existing player in the space appears to be preferable over establishing an independent startup.

 

Partner Candidates

After quickly assessing the landscape of candidates it seems DoorDash would be an ideal partner. They already have established relationships with a multitide of restaurants for their existing delivery service, and many features that would combine well with the proposed app.

Digging a little deeper reveals several pages of innovative new ideas and businesses in this space, but I've found none yet with the same concept as described here. These are just a few that caught my eye: The On Demand Company, Byte Kitchen, All Day Kitchens, Virtual Dining Concepts. It appears there is furtile ground for continuing innovation and plenty of suitable candidates for partnership discussions.

 

Intellectual Property

I've been researching the best way to protect my intellectual property in the idea described in this document, but I've been puzzled and surprised by what I've found. Between trademark, copyright, and patent, nothing really seems to fit. You can copyright a computer program's code if it's written, or visual designs if it's not, but neither of those protects the underlying idea of the code or visuals. It sounds as if someone could steal the concept and vary a line of code or some colors or a pixel and escape copyright protection. On the other hand patent does protect the idea but it's for finished products and can take years to achieve. I think my idea might be patentable, but that would require a long process without IP protection in the meantime.

However, I also discovered that copyright law was updated in 2005 with 'preregistration', a new class of protection for certain types of work that are likely to be infringed upon before they can be completed. Apps are included as one of those types of work. I'm currently engaged in the process of copyright preregistration for the Rate the Dish! app concept and designs.

G Letz Design: Footer copyright
(c) Copyright 2021, 2022 Grant Letz. All Rights Reserved.