2025
Book a local personal chef, effortlessly
b2C
marketplace
startup
web → mobile
shipped
Role
Product Design Intern
timeline
March - June 2025
Team
2 software engineers
2 software engineer interns
1 product design intern
5 business team members
contributions
Product design
Brand design
Logo design
Design systems
Code implementation
overview
Feast is a NYC-based marketplace connecting customers and businesses with personal chefs for convenient, affordable at-home dining. When I joined, the product existed as a rough web demo functional enough to test, but not ready to ship to real users.
As the only design intern, I was tasked to redesign the discovery and booking experience — initially for web, then primarily for mobile, working closely with the CEO and CTO. I also led a visual identity refresh through redesigning branding, logo, and updating the design system.
Impact and notes
Visual direction evolved under a new team and ownership shortly after my internship. The content structure, information hierarchy, and design system updates I established, including my logo design, carried through into the active Feast iOS apps. Feast is now live with its first cohort of chefs and customers.
The current App Store version reflects a second redesign following leadership changes after my internship. The work shown here is from March - June 2025.
the problem
Booking a personal chef is a high-trust decision, and users need to feel confident before committing.
Feast’s original web app prioritized quick browsing, but didn't give users enough to work with, which made it difficult to confidently evaluate and book chefs.
Because the product was pre-launch, there was limited formal user research to build on. With a small internal team looking to launch quick, I gathered initial impressions through team walkthroughs and and my own heuristic evaluation of the web demo to pinpoint issues.
Chef discovery page (initial web demo)
Chef-only card images
Users needed click into profiles to see any food images, which slows down comparison and decision-making
Chefs from different locations
Users are rarely looking across states. so location should filter results from the start to show only relevant chefs
Chef profile page (initial web demo)
Unverifiable chef credentials
Feast background-checks chefs before they join the platform. This was communicated on the marketing site, but not shown as credentials throughout profiles
Unclear upfront cost
Similar marketplace platforms show minimum cost per service as a standard. With more experienced chefs, this becomes increasingly important information
Chef menus (initial web demo)
No imagery
With only one photo per chef and no food imagery for menus, users couldn't form a sensory impression of what they'd actually be eating
No portion size communication
There were no specific labels for what was included in each portion, which made it unclear how much customers were actually paying for
Cross-menu selection limitation
To manage grocery logistics and per-order costs in early stages, the team wanted to restrict customer selections to one menu only — designs didn't communicate or guide customers within this constraint
No portion size communication
There were no specific labels for what was included in each portion, which made it unclear how much customers were actually paying for
the challenge
Revamp discovery and booking flows, so users actually understand who they're looking at, and what they can order.
Across the customer-side user journey, I primarily worked on three core areas; browsing, item selection, and booking.
To get a better sense of how these flows existed already, I conducted competitive analysis of 12 similar products to gather common patterns
Platforms like Shef demonstrated that credibility signals need to be concrete and countable: number of ratings, meals cooked, or food safety certifications that give users verifiable proof rather than just a profile photo.
Feast, like Yhangry, structured ordering around menus, which was a deliberate choice that made grocery procurement more predictable and cost-efficient. This required more design work to communicate clearly to users.
key design decisions
Browsing chefs in discovery
As the team prepped for an early April product demo to local gyms and studios in NYC, I initially worked on redesigning chef discovery on web, building out what metadata belonged on a chef card, how to communicate pricing upfront, and what credibility signals needed to be visible first.
Web platform redesign, discovery page
Prioritzed ratings, minimum cost, and description previews within the chef cards to show relevant information quickly
Introduced carousel photo galleries within the cards
Included "Top chef" designation to generate interest and credibility
Added cuisine filters, ultimately scrapped for V1 due to a limited number of initial chefs (and therefore cuisines)
1.1 The pivot to mobile
Just a few weeks later, the founders made the call to pivot the product mobile-first. From my web redesign, I carried forward my core decisions on metadata and information hierarchy.
As I redesigned discovery for mobile, I kept going back to two questions: "How do I know which chef to pick?" and "How can I trust this person?" Both pointed to the same solution: show more meaningful information faster, like ratings, minimum cost, and bios, before a user has to commit to clicking into a full profile.
Variation 1 of discovery used a single-column feed: each chef got a full-width card with a large photo and expanded bio preview, similar to a social media feed. Variation 2 used a two-column grid that let users scan and compare multiple chefs at a glance. A "Top Chef" badge shows experience verification and generates interest in the chef.
The deciding factor was shown during walkthroughs, where we saw that testers in Variation 1 consistently went back to the feed page to compare chefs side-by-side. The grid made that comparison faster, so we went with Variation 2.
1.2 Additional discovery flow explorations
I also explored a menu-item first discovery flow, where users search for a specific dish first in order to find nearby chefs who cook it. This was deprioritized for V1 because it buried chefs until later in the flow, and initial launch would have a limited number of chefs, let alone dishes.
Viewing a chef's profile
I realized that with Feast's limited initial chef pool, we didn't yet have the meals cooked volume that platforms like Shef relied on. That constraint pushed me toward solutions that could build trust without accumulated data, like photo galleries and detailed bio introductions.
Early feedback from walkthroughs showed that users wanted to know more information about a chef upfront. That meant the profile page needed to do address missing metadata that gave customers a better sense of the person. I explored two profile metadata arrangements. Variation 1 displayed number of bookings, years of experience, ratings, and reviews. Variation 2 exchanged bookings and experience for minimum cost and a cleaner visual layout.
The deciding criteria was that minimum cost was the first question real users asked, and years of experience typically appeared in the bio anyway. We went with Variation 2, which communicated the same information while taking up less real estate.
Beyond metadata, profile pages included photo media, expandable bios, and chef specialty tags.
2.1 Chef menus and reviews
To address the cross-menu limitation communicated by the business team, I restructured the menu section into a simplified single-menu-at-a-time format with explicit instructional copy to removing any ambiguity.
I also included the existing photo gallery section and introduced a review section.
2.2 Chef video introductions
One feature I proposed independently was video introductions, as a way to convey personality and technique in the absence of a review history. Chefs could record or upload short videos introducing themselves, showing their cooking style, or highlighting a signature dish. This feature was developed and shipped into product.
My rationale was that seeing a chef's personality, dishes, and technique through video would lower hesitations or perceived risk of booking, more than any static content could.
I also explored pre-call feature (allowing customers to schedule a video call before booking), but scrapped this for adding too much friction and logistics into the booking process.
Booking and checkout process
The original web demo had booking and checkout all in one modal, which presented a few issues.
Details competed for attention
Date selection, price, and menu selection details (not shown in image) were all condensed together
No field for dietary restrictions
Missing a text field to note dietary preferences, allergies, or additional requests or comments
Unclear pricing breakdown
Subtotal didn't explain the service fee, or variable Instacart grocery costs, which risked surprising users
3.1 Progressive disclosure and transparency
I broke down the booking into a sequence of 5 steps using progressive disclosure to reduce cognitive overload. Once a menu is clicked, users enter a page with only dishes from that menu in order to prevent cross-menu selection confusion.
I added additional information within menu items to add clarity, and pricing and subtotal information. I also worked with engineering to ensure user-side compatibility with chef-side calendar inputs.
Chef menus (initial web demo)
After selecting availability, service duration, and adding notes, users are prompted to enter an address using familiar, industry-standard input patterns.
I redesigned the review order section to improve cost transparency by breaking down specific food costs and additional fees.
This iteration reflects an earlier design; as pricing requirements evolved, I partnered with the business team to adapt the structure and ensure all necessary fields were captured in the final product.
user testing
Lightweight usability testing to give us quick insights
With tight deadlines and feature pivots, I prioritized quick testing. I recruited 3 internal team members and 5 remote users in NYC who fit our target profile, and facilitated in-person and virtual think-aloud sessions on the booking prototype to uncover confusion and inform any new iterations.
Observed usability patterns
From those testing sessions, I gathered valuable insights on what design decisions worked, and also had an initial direction of what we could improve in future versions.
Pricing transparency vs. subcost clarity
The pricing breakdown helped reduce any “surprise total” confusion, but some testers still expressed uncertainty around how individual subcosts like chef service fees were defined, which showed a potential need for pricing structure considerations.
Trust in chef credibility
Users tended to look for strong trust signals like reviews and verification tags before committing. In future versions, we noted to add a verified tag, which felt more common to users.
Menu structure comprehension
While users successfully navigated the flow, some hesitations during menu selection suggested ways to improve information hierarchy and labeling clarity.
additional design work
Worked across branding, design systems, and marketing
Beyond the core booking experience, I led a visual identity refresh. I redesigned the logo to include symbolic representations of dining. I ideated on a version of the web landing page, and throughout my internship I established an early design system.
My logo redesign was delivered and adopted by the team across the mobile product, social media and marketing materials, and the chef-side web platform.
In my initial work on web before the pivot to mobile, I even built out sign up & login screens in code and contributed directly to the codebase.
I also worked on auditing and testing chef-side onboarding demos, and redesigning features within the chef portal on web, such as menu creation and ingredient listing within dishes.
My audits and initial redesign concepts for the chef-side portal
Blurred for confidentiality purposes
Towards the end of my internship, I worked on initial UX concepts for introducing gift cards within the checkout process.
Reflections
What I’ve learned
Startups move fast
In hindsight, that was obvious. But I had to make decisions quickly, test rapidly, and adapt to many product changes. I learned how to adapt my work to the pace and technical constraints that come with speed.
Always ask questions, no matter how simple
By asking the founders questions not only about the product but also the business model, I got to truly understand the business side more and see why we were making certain decisions. Understanding the whole system helped me as a designer.
Kind words from the CEO, Ryan
Looking ahead
Feast has gone through many changes and pivots, but is now live on the App Store today.
I was so grateful to be building alongside incredibly supportive team members and to be learning so much from my role. I was truly pushed harder and grew immensely from my work and collaboration.
Matthew (software engineer), myself, Nand (software engineer intern), and Joyce (software engineer intern)
Want to learn more about this project?
I'd love to share it over a chat! Please contact me at rachael.huang.27@dartmouth.edu