Cross-platform recipe creation tool.
Problem: How might we increase engagement with our recipe content?
Anova Culinary, maker of the Anova Precision Cooker—an Internet-connected cooking device that uses the sous-vide cooking method—provided recipe content to its customers. People used that content by reading recipes online and by cooking from them with a native app on a mobile device. We measured this by the number of recipes viewed online and the number of cooking sessions started using a recipe in the app each month. We wondered what we might do to increase that engagement.
Solution: Allow users to create recipes.
We hypothesized that if users could create, publish, and cook their own recipes (user-generated content), those published recipes would increase the number of recipes viewed and the number of cooking sessions started with them. We also measured the number of recipes created and the number of recipes published. Starting with a collection of just over 1,000 recipes, our efforts lead to 600,000 new recipes from our users in 6 months!
Audience: Users of the Anova Precision Cooker.
Role: I was the mobile product designer responsible for the user experience and user interface design of the recipe-creation process and form.
Scope: We reused an existing content management system with existing recipe content to design and deliver a new feature for users. We built it following week-long iterations in an Agile environment following a build-test-learn model.
Left: Old web-based add recipe form. Right: New recipe page with a publish button.
Strategy 1: Open up the recipe content management system.
A recipe content management system (CMS) was already built and accessible by a web-based add recipe form (pictured above, left). However, it was guarded by in-house staff. Interestingly, feedback from the staff indicated that the add recipe form was buggy and difficult to use.
With buy-in from these staff members, we opened up the CMS to all users, free of charge, with no limits on what they could create. However, the add recipe form wasn't built with end-users in mind. It wasn't user friendly and there was no preview or publishing capability. When users saved content, the CMS automatically published it.
We eliminated the old add recipe form and replaced it with a new page. As a result, a user saw a completed recipe page that they could read, edit, publish, or cook from when they created a new recipe. We enabled inline editing and removed many elements that looked like a form. We also added a section that clearly separated the actions of saving vs. publishing.
Results: Unimproved recipe creation.
We expected users to add new recipes while browsing. They did not, which was disappointing. Despite loving to browse recipes on the web, our users simply did not like creating recipes during that time. Either the new page didn't meet their needs or it was out of the context of cooking. We deduced that this new page was not helpful when people were in the planning phase of cooking. However, this effort was not lost as it laid the foundation for more to come. We switched our focus to offering users a way to create recipes in the context of cooking.
Iterations made to the remote-control cooking interface in the iOS app: 1) starting interface, 2) newly added recipe name field, 3) redesigned remote-control interface, and 4) refined interface emphasizing recipe name.
Strategy 2: Enable users to create recipes while cooking.
Because the Anova Culinary Precision Cooker was a connected cooking device, users could control it from an iOS or Android app that the company provided free of charge. Up until that time, users simply used the app as a remote control, entering time and temperature to start the Precision Cooker from anywhere in the home. We wondered, what if they named what they cooked? We added a name field to the remote-control interface (pictured above, number 2). Time, temperature, and name became the foundation of user-generated recipes. We called these recipes "snippets" and made a few iterations.
Results: 300,000 recipe snippets in the first 3 months.
We were blown away by how many recipes people named. We discovered a user behavior that indicated they wanted to input more details about what they cooked. But how many details did they care about?
Iterations made to the create recipe experience in the iOS app: 1) a cooking history called My Recipes, 2) the ability to add and edit recipes, 3) the next level of detail: Add Cover Photo, 4) additional details a user could add, and 5) the ability to publish.
Strategy 3: Allow users to add more details to their recipes
It was obvious that our users loved naming what they cooked. What if we gave them all the web-based recipe tools directly in the app, with the ability to publish a recipe when finished, as a method of adding details? We hypothesized that a user would create a recipe while they were cooking.
This process required several iterations (pictured above), first by providing a simple history of what users cooked so that they could cook their recipe again (1). Then we provided an editable history (2), wherein users could add 1 more detail to their recipe, a cover photo (3). Next, completely editable details became available (4), followed by a publish button (5).
Result 1: The number of recipes created doubled.
Users continued creating recipes with various levels of detail. After another 3 months, 300,000 more recipes were created, totaling 600,000 recipes in 6 months.
Result 2: Nearly 5,000 recipes were published.
It was one thing for users to enter details about a recipe and another to get them to share what they created. In order to share, we provided a mechanism to publish what they created to the company's online collection of recipes, which would make them publicly viewable by anyone. Nearly 5,000 new recipes were intentionally published to the company's collection.
Result 3: Users published incomplete recipes.
We had a problem with quality. Because we wanted to promote a large quantity of recipes over quality, we allowed users to publish anything, without limits, in any state of completion. However, a majority of these published recipes were missing details a cook would expect to see, such as ingredients and directions. They weren't very useful.
Summary
The product team was astonished by the discovery of a new user behavior and the number of recipes created. However, there was much work to be done to improve the quality of this user-generated content. In the spirit of full-disclosure, I am unable to identify how this affected user engagement as measured by the number of recipes viewed or the number of cooking sessions started by a recipe. I left the company without obtaining those results.
Left: Recipe publishing feature with a progress meter for quality. Right: Checklist of items indicating higher quality.
Work left to be done
Improve recipe quality: On the web, we implemented a progress meter that indicated content quality as measured by completeness (pictured above). The more fields a user completed, the higher we rated the quality using 4 levels: beginner, intermediate, advanced, and professional. We also provided a checklist of items needed to achieve a higher quality level. However, because users did not use the web-based page to create recipes, this feature still needs to be added into the app. Due to shifting priorities, it has not yet been implemented.
Improve user experience: We hypothesized that users would want to record details about what they cooked during the act of cooking. Therefore, we built out a user flow that would provide a way to create a recipe immediately after a user started their Precision Cooker via remote control. Due to shifting priorities, this has also not yet been implemented.
Improve engagement by sharing: As mentioned earlier, the primary method of sharing a recipe was by publishing it. However, methods need to be developed that allow users to share their recipes on social media networks.
Administrative recipe-moderation dashboard.
Additional learnings
In case you're wondering, did we really allow users to publish anything? We learned that some people will create something inappropriate. We had the foresight to implement a flag feature, which would allow any user to flag a recipe for any reason. In-house staff were able to act on flags using admin pages we built (pictured above), which enabled them to locate flagged content, remove it, and monitor recipes.
Recipes were accessible online via a web browser, an iOS native app, and an Android native app. As a cross-platform experience, this feature challenged our product team in many ways. Synchronizing user-generated content (such as recipes) with a user's online account, the company's CMS, and the user's local device was difficult. When users logged in and out of their mobile devices, they would sometimes lose content or receive duplicates of their recipes. The need for better management of user accounts became apparent and is the topic of another case study.Building a content-creation tool involves interaction-design concepts, such as saving content as a draft, previewing it, publishing it, unpublishing it, and deleting it. We loosely followed the model used by Wordpress to publish a blog post, which provides methods to do all the above. We debated implementing an auto-save feature so users would not need to remember to save what they created. However, we decided against this because the effort required to implement it was out of scope.
It also forced us to confront concepts of privacy. What makes content private, public, or shareable? If the user shares private content, is it public? We followed a common model that private, unpublished content remained private so long as no one had the URL to it. This meant it was shareable and viewable if someone had the link, but it was not indexed nor searchable. Conversely, public content was intentionally published by the user, was indexed, and was searchable.
The concept of creating recipes is a unique challenge. We never fully investigated the context of cooking and how a cook takes notes or records a recipe for future use or for historical reflection. More research needs to be done about this. We made many assumptions despite preliminary feedback that users may not want a form-based creation tool. During user testing, we discovered that some users took pictures of recipes from books and magazines and used that image as a reference when cooking. Others copied recipes from online sources, such as the URL to recipes from other culinary websites. We debated whether a cook would rather take free-form notes or follow a structured form of ingredients and step-by-step directions. We also learned by watching recordings of website usage, with a service called FullStory, that some users preferred to copy existing recipe details from other users, going so far as to copy-paste ingredients and steps from a published recipe into their own.
Video demo reels
The following videos showcase a working prototype of the developed product.
Add recipe: desktop
Add recipe: mobile (native iOS)