A deep-dive into iterating on Kitchensurfing's new on-demand product, launched Winter 2014 in Manhattan.
In late 2014, Kitchensurfing launched a fixed-price service that put a chef in your kitchen with only a few hours notice. It launched with a scrappy, mobile-only MVP, and I helped to evolve it to an easier-to-use, cross-platform experience.
Getting to MVP
Kitchensurfing's flagship product connected customers with a broad marketplace of private chefs who designed and promoted their own menus. This chef-centric dinner party experience was loved by customers once they’ve had it, but the complexity of connecting with a chef who is available, picking a menu, and solidifying party plans with a large group made the process more burdensome than fun.
To bypass those painpoints, we hoped to build an "instant book" product. Early on, we did short tests reusing much of the backbone of the original product – including chef-facing menu creation tools, existing chef talent, and legacy front-end user experiences. But nothing was quite sticking – our freelance chef community wasn't willing to commit to schedules, and outsourcing the creation of menus made high-quality merchandising very difficult.
Soon it became clear that we should test an entirely different business model, centralizing menu creation and chef talent to enable Kitchensurfing provide a lower-cost, on-demand product. In that vein, the team decided to try a mobile-only approach that was disconnected from the other marketplace-driven Kitchensurfing experience.
Some of my early wireframes exploring instant booking
DEFINING AN AUDIENCE
We had an MVP that allowed customers to choose a menu and get a chef in their home the same night. We were getting bookings from friends and family – mostly early-adopter, tech-industry types – but needed to start tailoring the product for a more specific user who found real value in having a chef on-demand.
After a series of interviews with repeat bookers, we found that the most passionate users were professional couples with a small child – people with no free time. They had a strong desire to spend time with their significant others having a more meaningful meal experience than ordering Seamless in front of the TV, but still needed to be home for their child. This isn't especially surprising with hindsight, but the dinner party product, geared towards special occasion use cases, attracted a different demographic of hosts whose motivation was more geared towards having a unique experience aimed at impressing their friends and family.
THE DESIGN PROCESS
At a startup, time is always a constraint. The MVP was built in a matter of weeks, but was very limited in its scope – a 3-step, single-directional flow with booking only for the current day.
We needed to rapidly iterate on features to bring value to both the customer (booking more than a day in advance, saving booking details for quicker checkout, optimizing for multiple screen sizes) as well supporting business needs (building acquisition-specific landing pages, coupon systems, and back-end tools to schedule menus).
Improving the web experience
The initial layout was designed “mobile-first” with poor scaling for tablets and larger. However, we looked at the data and even with the suboptimal experience, over half of our early customers were coming from larger screens. It turned out that our married-with-children audience did their meal planning in front of their computers, rather than on their phones. I redesigned the layouts for each breakpoint, focusing on legibility and hierarchy. At the same time, I worked with our Ops team to develop a more cohesive photographic style guide for our menus, so maintaining one aspect ratio for our photos was useful for both merchandising and performance: the previous photo-heavy layout took long to download and its aspect ratios were hard to optimize shoots for.
Optimizing for iPhone
The original designs were mobile-only responsive web views in order to lightly test a “semi-native” iOS experience. They were also Kitchensurfing’s first attempt at native mobile, as the business had a hunch that a quick-book experience was an ideal use case for a phone. After several iterations in design and production that used highly customized UI, we decided to use lightly-styled nav and tab bars to allow users to navigate through bookable dates and areas of the site.
Remembering user's information
Our passionate repeat users complained about typing in their location and credit card again and again, and the Kitchensurfing product team needed account information to start measuring user behavior. However, we had experienced drop-off in the "dinner party" product funnel at the log in step, so were wary of requiring user accounts.
To add account creation functionality while making it feel less burdensome for customers, we used a modal view only at the point of purchase, and provided tools to save location and credit card quickly thereafter.
Building a referral program
Early on, word-of-mouth was our largest source of new users, and we wanted a way to incentivize and track that behavior.
After interviews with repeat customers, we learned that gifting was more important than “getting" for these affluent users. They told us that their reason to spread the word to friends was that they thought it was an excellent experience they wanted to share – not that they wanted a discount from us – and they expressed that they were more likely to share directly with specific people than to blast their social networks. Rather than a “get coupons for sharing" scheme, we decided to try to encourage customers to invite their friends by providing bonus add-ons for future dinners, and using language more focused on gifting an experience than sharing a discount.
Improving first-time user experience
As we added features and began targeting new audiences, a fair number of users were jumping right into the shopping flow with limited context. Knowing that hiring a chef to cook in your home is a new experience for most people, we needed to provide much more up-front education to build trust.
To see exactly where potential customers were getting confused, I performed usability tests with a small set of people who had never used Kitchensurfing before. While the overall flow was easy to navigate, some trends emerged. Users didn't have a clear understanding about how the in-home experience felt.
I combined the user questions and comments with common points of confusion our customer support team has heard, our current FAQ, and concerns heard during interviews with users who signed up for our newsletter and then never booked. I then ran a card sort activity with representatives from customer support, marketing, design, and product to better clarify where in the product we should answer those questions.
Shifting from "Acquisition funnel" to "Educational flow"
Combining the results of the card sort with quantitative data about user behavior resulted in a revised set of user goals. The biggest change from our previous approach was to provide much more context up front in landing pages, and open up the navigation to allow users to visit the landing page from wherever they are in the funnel. The shift of mindset is reflected most concisely in it's renaming to "How it Works."
Throughout this, I worked with a copywriter to make messaging clearer without sacrificing voice, directed a photo shoot to develop a high-level visual story of the in-home experience, and performed A/B tests to optimize both for conversion.
But wait, there's more! I also...
- Designed back-end interfaces to help manage chef and menu inventory
- Updated the global navigation so organic customers can access the same information as acquired users
- Edited and redesigned the FAQ, and migrating relevant information into the funnel where questions naturally arise
I left Kitchensurfing in mid 2015 to help build the BuzzFeed News app. Kitchensurfing closed business in early 2016. Rest in peace.