A Recipe for Success
A case study about focusing on user’s problems, not perceived solutions
Everyone who reads this sentence can probably name a restaurant they love and look forward to visiting. COVID has upended just about every facet of our lives, but we still find comfort in the food from our favorite joints.
That was the line of thinking that guided me and my teammates Kathy Le and Clara Park to our eventual idea for the 4th project in our UXDI Bootcamp: we’d create a digital solution to help facilitate food waste in restaurants.
The premise of our original idea was simple. Here’s a look at our original opportunity statement:
We will improve the experience of sharing/selling unused ingredients for restaurants and local businesses.
The user struggles today because they don’t have a clear way to share/sell ingredients and are forced to toss them, creating food waste.
This problem arises because there isn’t a central platform for local food businesses to share information about unused ingredients, especially fresh produce ingredients that expire quickly.
It makes sense, right? COVID throws off demand even more so than normal, so there must be an opportunity to help restaurants manage their ingredients and cut down on food waste at the same time. We got to work, setting up interviews with restauranteurs and other foodservice lifers, people who could test our statement through user interviews.
Turns out we weren’t too far off from a great opportunity.

Step 1: Prepping
The beauty of the UX process is that even if you start with a premise that has flaws, your users (in this case, the owners of restaurants and food service businesses) will tell you what problems they’re facing and whether your ideas might hold water.
By the time we finished our interviews, it was clear that liability concerns and a limited window for repurposing ingredients made it hard to enact our original vision. It was equally clear, however, that these restaurants could use support with their inventory and ordering processes. Our final research insights:
- Businesses already take necessary internal measures to ensure they are using and serving the best quality food for their customers. Anything that is already cooked or had a short shelf life often times cannot be reused or repurposed, ends up as waste due to liability concerns with giving it away.
- Business owners have easy-to-use systems that allow their employees to manage the inventory process. However, management cannot delegate the convoluted ordering process, because there is no standard communication method for placing orders with different distributors/vendors.
- While food waste is expected in the industry, restaurants would benefit from a way to predict demand. There is a lack of information on what tools and resources restaurant owners can turn to for this need. Access to market trends and reviews of trusted business partners/distributors can ultimately help restaurants optimize their operations. These tools can also help revisit order guidelines, allowing owners to adjust quantities to changing supply and demand.
It was time to PIVOT!

Step 2: Cooking
Our mid-fidelity design focused on the three insights above, namely attempting to solve for inventory and order processes while also adding a ‘community’ component. While this feature was definitely an interest based on our interviews, it wasn’t part of our minimum viable product. More on that later.
The mid-fi tested well, but a couple of key things stood out during testing. For one, the arrows and quantity boxes are close in size and proximity. This led several users to group them together, under the assumption that clicking the arrow would increase the amount in the inventory (it actually opened up the items ‘Details’ page).
On top of that, there are a lot of ways for users to interact with this page. Between the search function, the sort carousel, and each item's detail page, users had a lot of info to look at on their mobile screen.
Our initial hi-fi design improved on these points but missed the mark on things our users hadn’t pointed out (you can check it out here). The gradient design was cool, but would likely be a source of accessibility and graphical issues as users moved through the various tasks they needed to complete.
Users did express confusion on one key aspect of the process: how was the data getting “into” the app? The nature of these designs and prototypes tends to be a lot of smoke and mirrors, but anything that isn’t built either isn’t important and/or doesn’t get tested. It was clear from the feedback that we got in testing and from our instructors that some kind of onboarding workflow had to be drawn up. While it meant a significant investment of time, it also led to an overall polished look that better expressed what a typical user might have to do in order to get their data into the application. You can check out the high fidelity prototype here.
Step 3: Plating and Serving
In the end, the focal point of the app was reduced to the two processes I mentioned back in the beginning: inventory and ordering. While the community aspect would be a welcome addition to the app, it wasn’t a feature we needed to have at launch. Putting a button on the tab bar that doesn’t go anywhere distracts users in usability testing and also takes away your focus from what you learned was absolutely essential in research.
While we eventually removed it, one look at the MSCW matrix we completed at the beginning of our design phase would have told us that we needed to take it out before we even got to a mid-fidelity wireframe:

After making these final changes, the design feels much more like a real product: built to serve a key task with a clear goal in mind. It’s the kind of project we might pick up after we finish the bootcamp because of how much sweat we already put in. Even if we don’t, it showed us the value of designing through the UX process, allowing us the space to pivot (PIVOT!) and iterate based on what we learn at the end of each interval.
Step 4: Cleaning Up
This project was thoroughly satisfying, but also pretty challenging. In addition to the learnings described above, my personal takeaway was the need for finding a balance between user needs and business goals. The more work we do that dives into a real-world setting, the more it becomes evident that UX design can deliver on both fronts.
As far as the next steps for this app, I’d look to focus on these items, testing to ensure they meet the needs and expectations of our users:
- Change any modal windows that are time-based to ones that can be dismissed by the user, especially if they cover something the user will understand with frequent use (i.e. something explaining why orders are pre-filled based on inventory)
- Change any gestures that seem unintuitive (i.e. swipe to delete) to something more user-friendly
- Consider other integrations that feed off of existing permissions. If a user signs up with Google and gives access to their Drive files, they might be interested in sharing their calendar to get more detailed insights (i.e. your order is arriving on Friday at 8 am local time!)
- Consider other viewports, especially tablets. Restaurants and other foodservice businesses have these tools in their belt already and would likely feel comfortable transitioning to this app as a result.
Thanks for taking the time to read through. If you’re ever in doubt about what is most helpful to your projects when trying to determine a feature’s usability, don’t forget Patrick Star’s timeless words.