Matching People with Dietary Restrictions to Restaurants
My Role
Product Designer
Timeframe
3 months
Team
Two Designers
Overview
What is Paprika?
Paprika is a B2C mobile application that aims to match users with restaurants that fit their specific dietary preferences. Matching user dietary preferences to restaurants was the main value proposition of the application and we built our designs and flows around this philosophy.
My Work: End to End Mobile Design
I onboarded Paprika in July 2023 as one of the founding designers, where I worked with another designer to design their end to end mobile experience of Paprika reporting directly to the Head of Product.
During the process, we had daily stand up meetings with the Head of Product to report on progress and biweekly meetings with the engineering team to discuss feasibility and foster alignment on designs.
During the process, we had daily stand up meetings with the Head of Product to report on progress and biweekly meetings with the engineering team to discuss feasibility and foster alignment on designs.
Our Design Process: Designing From The Ground Up
We aimed to finish the research synthesis and end to end mobile designs by October 2023, which gave us a 3 month timeline. However to increase velocity, engineering would start working on a flow, as soon as we finished it.
User Research
Existing User Research
Preliminary formal and informal user interviews were done by the Head of Product, prior to the onboarding of the current design team. The primary personas were users with dietary preferences and restaurant owners who cater to dietary preferences.
PAIN POINTS #1
Allergen Info is Difficult to Find + Understand
Users often have call restaurants, who often may not know themselves or scour the restaurant website to find dietary info
Dietary Info for Menu Items is often in 10pt font and not organized very well.
INITIAL DESIGN DECISION
Make Allergen Information Accessible and Scannable
PAIN POINTS #2
Vague Context Surrounding Dietary Label
Users aren’t informed how to obtain a dietary accommodation:
Do they need to ask for a substitution?
Do they need to ask for an ingredient subtraction?
Different cooking environments to prevent cross contamination?
Do they need to ask for a substitution?
Do they need to ask for an ingredient subtraction?
Different cooking environments to prevent cross contamination?
INITIAL DESIGN DECISION
Dietary Information Should Have Sufficient Context
PAIN POINTS #3
Inaccurate Online Information
Users often read information, only to find this information is inaccurate upon arrival
This incites frustration at best and at worst, results in a fear of an adverse reaction due to inaccurate information.
INITIAL DESIGN DECISION
Design ways to verify Information and report Inaccurate Information
Addressing Pain Points
Considering User Needs Within The Product Requirements
Paprika is a B2C mobile application that aims to match users with restaurants that fit their specific dietary preferences. Matching user dietary preferences to restaurants was the main value proposition of the application and we built our designs and flows around this philosophy.
The core structure of our app includes:
1. Restaurant Feed: Discovery section where the user is recommended restaurants
2. Restaurant Details: Informational section for important restaurant information
3. Restaurant Menu: Contains various menus within the restaurant
4. Item Screen: Contains dietary/allergies labels and how to acquire any dietary/allergies labels
1. Restaurant Feed: Discovery section where the user is recommended restaurants
2. Restaurant Details: Informational section for important restaurant information
3. Restaurant Menu: Contains various menus within the restaurant
4. Item Screen: Contains dietary/allergies labels and how to acquire any dietary/allergies labels
USER FLOWS
Finding the Flow from Product Requirements
Based on our required screens, we drafted a user flow to better visualize the user journey through the app and what screens we should pay special attention to in order to respond to the user pain points listed above.
ADDRESSING PAIN POINT #1
How might we visualize important dietary information so that it is easy to understand and accessible?
As of 2023, Paprika supports 10 allergen label (e.g. gluten free) that can be associated with restaurants and menu items. With this information, our goal is to create a way to visualize this dietary information at restaurant card, restaurant details, and menu levels of the app. We brainstormed ways and came up with two primary ways to visualize dietary information:
Restaurant Feed Level: Reducing cognitive load with % Dietary Match Tag
Paprika is a B2C mobile application that aims to match users with restaurants that fit their specific dietary preferences. Matching user dietary preferences to restaurants was the main value proposition of the application and we built our designs and flows around this philosophy.
Restaurant Details Page: Creating functional restaurant dietary labels
Our goal in designing restaurant dietary tags was to create tags that would help understand which dietary labels they matched with. However, while designing this, we found a golden opportunity to link the restaurant dietary labels to the dietary menu within the restaurant menu.
That way, we give users another pathway to find menu items that fit their specific dietary preferences.
That way, we give users another pathway to find menu items that fit their specific dietary preferences.
ADDRESSING PAIN POINT #2
How might we give contextual information to dietary information if necessary?
To give context to dietary label, we used color coded labels with explanations on what this label means if the user wanted more information.
ADDRESSING PAIN POINT #3
How might we promote verified information while reporting inaccurate information
Paprika is a unique position because it allows the community to input restaurants, menu items and dietary labels. Therefore, Paprika needs a way to separate information that is verified by Paprika vs information that is inputted by the community. Our solution to this was having specific symbols to denote this on restaurants, menu items and dietary labels
Design Process
DESIGN SYSTEM
From atoms to organisms
After understanding what components we needed from low fidelity sketches, we moved on to componentizing and creating a rudimentary design system to make sure that Paprika’s visual identity was consistent. As of finishing the end to end mobile design, we are currently working on updating the design system and working out the component system.
CARD VARIATIONS
Restaurant Cards: Working Through Variations
We made multiple iterations based on developer and founder feedback on several components of the app. However, we spent the longest iterations on the restaurant cards. Our biggest challenge aligning on what information we felt was important to present in the card and how the card would scale when more or less information was present.
USER FLOWS
How does the restaurant card scale with more or less information?
One of the challenges that we faced, was missing information from restaurants. The Paprika team was pulling restaurant information themselves and sometimes some information that we may want to put on the restaurant card is not available. This is a situation where we have to consider empty states and how information scales on the restaurant card .
SCREEN FLOWS
Understanding Paprika Through Screen Flows
I've included the 4 main user flows that will be available in the application.
Onboarding
Finding a Restaurant/Menu Items
Map Feature
Writing a Review
HIGH FIDELITY
Finalizing Designs and Forming a Stakeholder Presentation
We completed the MVP after 3 months and our MVP is currently in development (about 50% done). Our key performance indicators are user growth and retention rate as well as average screens per visit. After launch our goal is conduct rapid usability testing and conduct design sprints to see what improvement can be made. These high fidelity screens are only the most important screens and do not represent the entirety of the app
TAKEAWAYS
Learning to Better Communicate My Design Decisions
While working with many different types of people, I've learned the importance of being articulate and clear when explaining design decisions and rationale to my coworkers. I've also been trying to be more mindful of how much I'm saying as well, bearing in mind who my audience is. My fellow designer might want to have a little more context behind the design thinking while stakeholders will want summarized and shortened versions.
Advocating for Accessibility and Usability Over Style to Stakeholders
While designing, I'm being more mindful of why I'm advocating for something. While talking about my design decisions, I've been trying to bring accessibility, usability and overall functionality at the forefront of my rationale rather than advocating for thing for more aesthetic reasons.