PRODUCT DESIGN AT PLATTER
Platter
Platter Banner.jpg
Introduction
Founders: Ronak Shah, Daniel Truong

Designers: Irene Guo, Katie Chen, Anna Wang, Samuel Huang


Developers: Garrett Gibo, Carmen Li, Rohith Kasar, Takashi Yabuta
Role: UX Design Intern

Skills: User Testing, Design Systems, Wireframing, Prototyping

Timeline: 10 weeks
Platter will be a next-generation food marketplace aligned to help local chefs sell food and connect to their community. I worked with 3 designers for 10 weeks to create the designs for a mobile food ordering platform geared specifically towards home chefs.
Context
Now more than ever people realize that they have the ability to create their own small business whether that is through social media or word of mouth. Platter’s founders noticed that many people started to create their own food business and saw an opportunity to create a better experience for these food sellers.

Currently, there is a lot of friction for food sellers to create menus, advertise their food, and manage different orders. Platter’s vision is to allow people to eat better food from local and authentic chefs.
The Problem
Local restaurants and chefs are being overshadowed on big and established food marketplaces, and lack resources to compete with big chains. Additionally, local restaurants are forced to pay an effective 15% tax on pickup to use established food marketplaces, whereas larger chains have more negotiating power to mitigate such fees.

Additionally, local students and residents have a difficult time getting access to authentic and local foods — and are instead funneled into ordering from national chains (when using said established food marketplaces).
The Solution
Platter will be a next-generation food marketplace aligned to help local chefs sell food and connect to their community.

Chefs and Restaurants will pay us as a service cost to enable pickup from our app. Our app will be a community of chefs, therefore providing a network effect to enable many local chefs (in addition to a low-cost Point of Sale system for the chefs).
User Research + Insights
We wanted to discover the pain points that local food businesses when it came to selling food to their community and what tools they currently use to run their business.

We were able to interview both food sellers and people who currently purchase food from local chefs and came up with a couple of insights. However, I was given the responsibility of the seller side of the application so my work will be developing the sellers' experience.
Platter Insights.jpg
From our research data, we were also able to create 2 personas to display the common types of sellers that would be part of the target users of Platter.
Platter Paayal.jpg
Platter Anchitha.jpg
Problem Statement
How might we give sellers a simple tool to create, host, and update their menus?

How might we help sellers organize and prepare for the various types of orders that they could receive?

How might we streamline the communication process between sellers and buyers?
Key Requirements
After reviewing our research data and thinking through our insights, we realized that home chefs needed a place where they could show buyers more about who they are and what they could make for them as well as somewhere to take orders. Because of this, we created a list of features that allowed home chefs to host their menus as well as process customer orders.
Requirement List.png
User Flows
After we figured out which features we wanted to include, we decided that we would outline the potential user flows.
Create a new menu
Creating Menu v2 (1).jpg
Processing an order
Processing Order (1).jpg
Ideas and Sketches
We created sketches of design for the screens for the two main flows that we have. We wanted to get the idea across to test it so that we could easily iterate on it.
New Menu Sketches.jpg
Processing an Order (Accept).jpg
Processing an Order (Reject).jpg
User Testing + Design Iterations
After we created our two main user flows, we wanted to test our designer and identify potential issues with our design. We asked the local chefs to complete two tasks:
 
  1. Imagine that you launched a new menu with items that you make every day as well as items that someone would need to preorder a couple of days before. Please take me through the process that you would take to make this menu.
  2. Imagine that you have customers ordering dishes on Platter. Please take me through the process that you would take when you receive an order.
Creating a menu
New Menu Form
Make menu.png
Menu Creation Form
Menu Selection.jpg
First Page of Menu Creation
When tasks with creating a menu with both pre-order and same-day orders our chefs weren’t quite sure what that meant. Furthermore, once we explain the idea to them, we could tell that the pre-order versus same-day orders options used lacks clarity.

After discussing it with the team, we realized that it was not necessarily an interface issue but a copy and communication issue. Since we are using words that aren’t commonly used and understood we needed to explain the idea to our chefs. In order to do this, we adjust the flow in that we added a page before the menu form laying out the types of menu that a chef can choose from.
New Menu Form
Daily Order Order times.png
Pickup Times
Menu Days.png
Redesigned Pickup Times
When tasks with creating a menu many chefs had trouble understanding this calendar-like interface to book time. I think this is because this interface is not standard. Furthermore, when the chefs included more days, it became increasingly more difficult to input the times they wanted.

We decided to go with a list format of each day and a numerical toggle to adjust the time. This is because we understand that it’s more standard and there would be more clarity for our chefs.
Processing an order
Ticket Queue
Tickets Screen.png
Ticket Queue
Queue - Recieved.png
Redesigned Ticket Queue
When we had the chef think through the process of an order we realized that the way we categorized the tickets didn’t make sense. We learned that the status of the tickets is more important than the time. Furthermore, we learned that it could cause confusion between accepted tickets and nonaccepted tickets.

For the redesign, we organized it so that the tickets are divided based on status instead of timeline on the ticket queue
Ticket Confirmation
Accept and Reject Form.png
Order Editing Option
Ticket Confirmation.png
Redesigned Order Editing Option
When we had chefs check the confirmation page of the order, we realized that were lacking specificity and clarity. For example, we weren’t considering if someone wanted to order both daily order items and pre-order items in the same order. They mentioned that they also cared about the clarity in price and payment information. We also noticed that they took a longer amount of time to understand the “Reject” option. This led us to question the copy and the treatment of the button.

For the redesign, we organized the content to clearly separate daily order items and pre-order items. Furthermore, we created a section for the order amount as well as payment information. We also changed the “Reject” button for a couple of reasons. First, "Reject" isn’t a proper way to describe the option. Instead, it gives the chef to edit the order. Second, it’s a secondary action and it’s treament should reflect that so we changed it to not be filled
Order Editing Page
Suggest Edits.png
Order Editing Option
Finished Cooking (1).jpg
Redesigned Order Editing Option
Once the chefs chose to adjust the order, they couldn’t easily where to go. They were expecting an input option. Furthermore, they realized adding a small note to the order wasn’t enough, they wanted to adjust other aspects of the items (quantity, dish, pickup time).

For the redesign, we wanted the default to be in editing mode. Furthermore, we wanted to give our chefs the ability to adjust all those different parameters easily and quickly.
Style Guide
For this application, we wanted to give add a rustic feeling to the application because it is home-based cooking. The goal was to make it feel less corporate and more homey and warm.
Primary Color Pallette v2.jpg
Secondary Color Pallette v2.jpg
Text v2.jpg
Final Design
Creating a new menu
 
Add a new dish
Edit the customer's order
Outcome + Learning
Just after 10 short weeks, we were able to conduct user research, create lo-fi prototypes, conduct user testing, and finally design a hifi prototype. I'm quite proud of the work all the designers on our team was able to pull off!
What I learned
1. Prioritization is key in that sometimes limiting the options given to your users so that they only have the most crucial ones is important.

2. UX writing is very important because terms that might seem clear to you might be confusing for other people.
What I would do next time
1. I would try to iterate faster and more because I think giving yourself more pressure to use your creativity would help improve your designs and provide more options.

2. Create a constant communication framework with team members who aren’t necessarily working on the same feature as you to get a new perspective on your designs.
What's next?
Let’s continue the conversation!
linkedin.png
mail.png