"How might we improve the cooking experience with a mobile platform?"

In order to build a product for cooking, we needed to first understand the pain points in the process of learning to cook a new dish. In initial discovery, I talked to people with a wide variety of cooking experience and observed them cooking.

I synthesized the results into four core insights:

• We tend to stick to our comfort zone - the recipes we already know. Decisions are hard, and time is valuable. Trying new recipes is fun, but often needs an impetus - a dinner party, etc.
• Information quality is unreliable. Many professional chefs will study ~10 different recipes and assimilate the information before attempting a new dish. Home chefs often choose one arbitrarily and hope for the best.
• Failure is discouraging, because there's insult to injury. Especially for home cooks, for whom cooking is the primary mode of sustenance, making a mistake means dealing with the consequences - throwing it away or sucking it up and eating it.
• Preparation is important and it frames the process. Understanding the timing, ingredients, dynamics, and intricacies of each dish prior to execution can cut cooking time significantly. This includes knowledge that is often difficult to communicate in writing, because it is both broad and situationally specific.

Cooking is a learning process, so I studied the cooking process through the lens of our education system.

I made the assumption that cooking, like general education, was more about people than the recipe. We decided to try live instruction through videochat, and validated by running a series of cooking instruction sessions through existing videochat channels. I produced the following insights:

• Cooking alone for yourself is lonely. Having other people there virtually makes it much more fun, because it feels like you're cooking with/for a big family.
• Recipes are just guidelines, and they're built for recall - An analogy would be that recipes are just the class notes, to the lecture - you can learn from them, but it's not what they are optimized for.
• Live feedback is about more than just fixing mistakes. Participants mentioned that even when things were going well, they felt a lot more confident executing with a responsive host.

Participants talked as much about the chef as they did about the food. Most of them reached out afterwards to ask about doing future sessions, and stressed that making a dish perfectly on the first try was incredibly rewarding.

I decided to drill in on the personal connection between host and student. The organic human interaction of cooking over video proved to be a powerful anchoring experience, which I hoped to take advantage of for the purpose of education.

"How might we create a cooking education platform around live videochat?"

A core piece of the experience we were creating focused on live videochat, and thus it relied heavily on a consistent internet connection. In the process of testing, I discovered that when things did not go as planned, class times were stretching from around an hour to two hours or more - and a short break in the connection evoked emotions such as fear, helplessness, and anxiety. To research this, I first mapped user emotions in sessions to identify stress points.

I separated failure scenarios into two regimes: Human Failure and Connection Failure, and conducted research in each. This consisted of ethnographies following failure scenarios, and experiments in which a script was written around a specific scenario.

In researching human failure, I discovered that students often do not know what to look for in cooking, and most recipes do not describe the correct indicators, and rely on time as a measure. Because kitchen conditions, dynamics, and ingredients vary, timing is really an approximation of a number of qualitative indicators - and it is these indicators that we actually need when cooking. Examples of these indicators include:

• Consistency (i.e. thick and smooth)
• Color (i.e. edges are browning)
• Behavior (i.e. bubbling)
• Features (i.e. skin begins to form)

Connection failure was more complex - it was a source of human failure itself, and often required significant extra time to touch base and reestablish frame once the connection healed.

From these results, I decided to organize a recipe by actions and indicators - for each step, there are a series of actions that are to be executed, and a series of indicators (like the ones listed above) that signal the end of the step. I created a protocol for hosts to follow with the intention of giving students a complete mental model of each step, anchored to their interaction with the host in an asynchronous manner such that a connection failure would not be catastrophic.:

• Describe the purpose, action and indicators of the step (set the frame)
• Demonstrate the step, explaining each action and emphasizing indicators (reinforce memory)
• Watch as the users execute, reminding them of indicators. (guide execution)

With this protocol in place, subsequent failure scenarios took, on average, only ten to twenty extra minutes, as opposed to double the course time (~an extra hour).

In the process of researching the recipe, I looked for ways to represent the situational knowledge surrounding a recipe that formed a basis of understanding. We knew that chefs would often provide personal tips to inform the user before and during a cooking session, but wanted to build a conceptual framework for them. To do this, I looked for problems with similar pain points. In road navigation, our main pain points are relevant:

We tend to prefer the routes and roads that we know; There are many ways to arrive at a destination; Failure (accident or wrong turn) is highly discouraging; It’s helpful to study the route in preparation.

I studied the interface of Google maps to identify analogous information categories to the tips we were trying to distil. In particular, two views caught my attention:

POI Background - These are info that provide background information on the point of interest. (insightful review excerpts, interesting photos, related listicles, dynamics). This provides a richer understanding of the POI, instead of surface level metadata (name, rating, category).

Route Context - These are info that give context to the actions you need to take (traffic, accidents, construction, different routes and their eta). These show the context/reasons why you're taking the route that you are (i.e., taking 280 instead of 101 to avoid an accident).

From these insights, I realized that we could categorize chef's tips into two main purposes - informing background understanding, and establishing action context:

• Ingredient background - we need background knowledge of various ingredients to form a basis of understanding for how to use them. This is especially important in recipes using specialty or rare ingredients, as they often require special treatment.
• Action Context - there are a million ways cooking techniques can be modified in different contexts. Providing reasoning behind or extensions of actions not only helps a user understand why they are executing a certain way, but also learn about each specific technique in isolation.

This provided an organizational framework for tips, which had not been clear cut. For example, with a tip like "when stirring the palm sugar, keep on low heat", we could recognize the intention behind the tip - it was less about the act of stirring and more about the palm sugar - and rewrite it as "palm sugar has a low melt temperature and high burn temperature, so you don't need a lot of heat to bring out its sweetness".

Thus, I decided to split the interface for each class into three separate panes:

Overview pane: General information and photos, chef profile and description, materials and equipment needed

Instructions pane: Summary of steps, along with tips from the chef concerning important steps and the things to watch out for when executing them.

Ingredients pane: Quantities of groceries needed, and background information on specialty ingredients needed for a dish, including origin, taste, cultural context, other uses, and trivia

Summarizing research, I moved forward with three core insights to frame the process:

• Food is a basic human experience, and shared experiences are powerful.
• Recipes are guidelines for recall, and cooking skill is based off of a body of intuitive knowledge
• We serve the function of cooking education by anchoring intuitive knowledge to a memorable shared experience

To guide the process of scoping, prototyping and producing an MVP, I created user profiles. Our target student users were, in general, young busy professionals who cook, love variety, and have enough income to go out to eat a couple times a week:

To define a feature set for an MVP, I evaluated each feature we were considering based on necessity, impact, and complexity of development.

Necessity was the simplest to evaluate - What do we need for our product to function? This consisted of features like feed, schedule, payment, and live video.

Impact involved talking to stakeholders. For each feature we were considering, I built a case around it consisting of quotes and insights, proposed scenarios, and best practices. I then evaluated them based on these cases. For example, a checkpoint feature was seen has high-impact, as it was novel, solved a problem we were facing (organizing four people), and most hosts found it intuitive. A timer was low impact, as almost everyone had a kitchen timer already.

Complexity involved talking to engineering. I talked to the team and evaluated our features from those conversations.

For the MVP, I decided to include all necessary features, and one low complexity/high impact feature - the checkpoint. I created user stories to organize them, and we moved forward to prototyping.

Next, I sketched out a full flowchart, and then moved on to prototyping:

Prototyping involved many different iterations. With each iteration, I would approach stakeholders with the wireframes/sketches/prototypes and observe their interactions. You can see the final app images produced below.

In addition to the ones detailed, I decided to produce two features - a checkpoint (for async teaching in groups) for the MVP, and a class creation host-side interface. When video stability required more attention and time than planned, we created a simple web app form for the latter and delayed the in-app feature to after the MVP.

We launched an alpha version to a group of users and received positive feedback. All of our hosts were volunteers, who continued teaching after the alpha was officially over. A majority of students came back and booked more classes.

I learned a lot from taking a product from idea phase to launch. Because the idea I was approached with was incredibly broad in both scope and target, I had to continuously redefine the problem as work progressed. In this search, I reached out to subjects including education, navigation, and communication for inspiration.

• A product is more than what you see - it consists of so many different components working together behind the scenes: Brand, Identity, Application, Community, Protocols, Standards. These elements all come together to form an ecosystem. There is so much more than meets the eye, and I learned a lot from building it from the ground up.
• Build bridges, not silos - working together with and getting feedback from engineering throughout the whole process was very important to building a great product. Sharing knowledge across diverse backgrounds and tackling challenges together often led to more novel, cohesive, better solutions. The process of building a product is nonlinear and things change quickly. It was only through working together that we could adapt to changing priorities easily and effectively.
• Have a strong bias towards action; fail fast by validating everything - it's the best way to move forward. A bunch of invalidated assumptions do not equate to one large failure - in fact, it's usually the opposite. Continunously testing and validating helped me realign myself often and spot mistakes way before they became catastrophic.