Designing For Marketplaces: Kitchensurfing
Everyone is a chef. Every kitchen in the world
is an ad hoc restaurant waiting to happen. (2012–2014)
Kitchensurfing launched in early 2012 with a small team of founders and early employees. Between the launch and my departure at the end of last year, our product and design went through many changes. These posts document what I learned as a co-founder and lead designer at an early-stage startup.
What if restaurants didn't exist?
A few years ago, if you wanted to share a meal with your friends, you had a few familiar choices: go to a restaurant, order takeout, or cook at home. Of all the dining experiences I had, memories of meals shared at home stand out the most. The problem: If I wanted to enjoy a memorable meal at home without cooking, my options were limited to ordering pizza or hiring a caterer — either too formal or too expensive for most occasions. Surely there was a better way.
First, we looked at pain points for chefs and diners:
Chefs
- 60–80 hour work weeks are commonplace
- Low salary: ~$10/hr for many line cooks
- No personal ownership of the food being prepared
- Start-up costs for new restaurants are prohibitive
Customers
- Restaurants are expensive (food and beverage markup, gratuity for service)
- Restaurants are loud and lack privacy
- Health concerns (excess salt, oil, fat; allergy risks)
- Convenience (difficult to get a table at a busy night, cooking for a group is a lot of work)
- Taste (delivery food is usually terrible)
- No price transparency for caterers/private chefs
- No central place for reviews of independent chefs
“Pay the chef, not the restaurant.”
If we were able to bypass restaurant and catering industry markups, the cost of a meal to a customer would be reduced, while the removal of overhead costs would allow chefs to increase their take-home pay.
After conducting interviews with diners, restaurant chefs, and caterers, we discovered that booking a private chef was not as expensive as we had expected. In fact, $50–100 per diner could cover the ingredient and labor costs for a three-course meal.
At this rate, chefs could earn more money from a private gig than by working a typical restaurant shift. In addition, chefs could take more ownership over the food they serve and work in clients’ homes rather than hot, crowded restaurant kitchens.
We believed we could expand the private chef market beyond a service for the “1%,” change the way regular people eat at home, and create a new market for independent chefs and.
We're changing the way people eat at home.
With that, Kitchensurfing was born. Our mission: To create an online marketplace where anyone could easily find and book a chef for their next dinner party, birthday party, or any other occasion. Chefs would source all ingredients, cook, serve, and clean-up. Users would be able to choose from thousands of chefs, including skilled cooks from well-known restaurants, recent culinary school graduates, and experienced private chefs.
Next, we set to work building the first version of Kitchensurfing.com.
Brand
The big questions: How should Kitchensurfing look and feel? What type of experience should our users have? Because Kitchensurfing’s end-user experience would occur in a very personal space — a user’s private kitchen — it was especially important for customers and chefs to identify with the product on a personal level.
When I design brands, I like to start with a digital touchpoint like a landing page because it’s often the first experience a new user will have with the brand. At first, I designed some awful shit:
Early Iterations of the Kitchensurfing Landing Page
Typefaces + Colors
For the logo, we chose Creighton, a font based on an old typeface called Hermes Grotesque. I was looking for a modern sans-serif that was humanist, bold, and round.
For the copy, I chose another humanist sans-serif: PT Sans. (It didn’t hurt that PT Sans was available for free via Google Fonts.)
The first homepage looked like this. At first, we planned to list available kitchen spaces for rent, but quickly dropped this idea when logistics became difficult. We also changed the hero image to a shot of people eating together. (We sell dining experiences, not yogurt.)
Product Design
Our challenge: How do you get users to spend $500 on a website they just discovered, when that $500 also means hosting a dinner party for 10 guests and inviting a stranger into their home to cook food they’ve never tried before?
Trust
Companies like Etsy, Kickstarter and Airbnb empower individuals to create their own businesses. They don’t employ the users who post products, projects, or spaces, and thereby encourage diversity and creativity in their listings. You can live in a small town on the coast of Maine and cover all your bills by selling hats on Etsy. The platforms empower unique users like these by providing great infrastructure.
How we created trust:
- Real Names — Real names make interaction feel personal. ( I remember using aliases like “gravedigger84” and “borahm.” People always thought my name was an alias.)
- Photos — Profile photos and high-quality images for the listing (whether of food or rental cottages) make the user and product feel real.
- Reviews— Both number and quality of reviews are important. A chef listing with 5+ reviews appears more trustworthy than a profile with 0 reviews.
- Secure Payment — The site holds payments in escrow and only releases funds to the chef after the meal is completed without issue.
- Activity — Users like to see evidence that other people are using the site. Comments, reviews, inventory figures, and press links all create the impression of activity.
- Transparency — Structured data like employment history, expected response time, hourly rates, and service locations help set user expectations clearly.
- Curation — If users have a negative first experience, they won’t come back. I did personal taste tests for at least the first hundred Kitchensurfing chefs.
Friction
In a world of “1-tap” apps, it’s easy to say user experience should be simple and frictionless; but friction can be used to create more engagement. Amazon can pull off a “1-click” experience for returning users because they have earned your trust (that’s why you saved your payment and shipping information).
Kitchensurfing’s offline experience was not simple enough to expect users to “buy” a chef with one click. We were empowering users to create a social experiences in their homes, but those experiences depended on chefs. That meant our product had to create a connection between two people who didn’t know each other.
The mechanics are similar to dating sites like OKCupid, except there is no payment involved…
Search/Discovery
Which chefs can I book? Is this chef in my price range? Do this chef make food I like? Does this chef have experience with my dietary needs? Have other users booked this chef? Does the food look good?
Chef Profile
Can I trust this chef? What kind of menus to they offer? How can I contact the chef? Are they available in my area? Do they share my perspective on food?
Messaging
My event date, price range, and a brief description of I’m looking for.
Rather than selecting from fixed options, we wanted to make the user feel comfortable and encourage communication with the chefs. Messaging is an easily understood mental model that creates trust between people. While not as efficient as a “buy it now” button, our focus on messaging enhanced the quality of inquiries by making users feel invested in their request and providing a feeling of accomplishment.
Our first version was essentially a messaging app on steroids: a conversation with structured data, contractual components, and simple e-commerce functions.
Choice
We were able to create trust between people who didn’t know each other. This allowed us to observe a set of new behaviors with a relationship to conversion rate:
- Volume of replies: Users who received menu proposals from 3 or more chefs had a 3x higher conversion rate than users who received only 1 reply. However, users who received 5 or more replies had a lower conversion rate.
- Key price points: Most requests and bookings were for the $40–60 per person range, while we also saw a high rate of requests for greater than $100 per person.
- Response time: Chefs who replied quickly were more likely to be booked.
From this data, we defined our next steps as user and business goals:
User goal:
- As a User, I want to receive the right amount of menu proposals (3–5) so that I can easily compare price and menu quality between offers.
Business goals
- Increase transparency on the supply side of the marketplace in order incentivize chefs to “close” bookings with faster responses and more competitive pricing.
- Align user expectations with chefs available in their price range.
After a few exercises, we built a user-facing tool called “Match” and later added the “Market” (a pool of “Match” requests from users) for chefs. The first version of Match was an RFP (request for proposal) tool with simple data points.
Instead of sending a request to one chef at a time, your request would go through our “system” and match you with multiple chefs based on criteria like timing, price point, and food preferences. The system would make sure you always received 3 menu proposals.
The customer was thinking that the system was working for them and there for selecting the right chefs, but we actually had humans in the backend assigning requests to the chefs — so much for technology ☺
It worked! For a while…
Using “Match” as our primary user interface, we created an online marketplace with a few thousand chefs spread across seven cities (New York, Berlin, Boston, Chicago, Los Angeles, Seattle, and Washington, D.C.). In our first year, our chefs served over 65,000 guests while maintaining consistently high NPS Scores. Some of our chefs made more than $150K a year from Kitchensurfing bookings alone. On paper, these were huge successes.
However, each new city launch created huge pain points for our operations and customer service teams and we were unable to quickly scale the product in new markets. Our product simply wasn’t ready to scale.
We identified three key areas that contributed to sluggish growth and the development of a difficult product to scale:
- Infrequent use cases. Users though of Kitchensurfing for special occasions only, meaning the needed an “excuse” to use the product.
- Long lead time. The “aha!” effect of the in-home experience with a chef came too long after discovery, request, and booking. This delay failed to encourage repeat behavior.
- High price as a barrier to entry. Even though our average price per person was competitive with restaurants, hosts had to foot the bill and organize cost-splitting off-platform.
We built a product that our users loved, but we knew we had to change something if it was going to scale. In summer 2014, we decided to rethink our core business.
Continue to “Designing for On-Demand Services: Kitchensurfing Tonight”
Credits
Product Management
Borahm Cho
Design, Creative Direction
Borahm Cho
Concepting
Chris Muscarella, Borahm Cho
Development
Lars Kluge, Alex Rakoczy, Mariusz Roliński
Marketing
Ben Cole
Operations
Max Siegal, Eileen Belfield
Follow me on Twitter or shoot me an email (borahm@borahm.de).
Im looking for new and fun things to work on.
