Ideation

Brainstorming

We started our brainstorming process by reviewing the user interviews we had conducted, summarizing and synthesizing our insights, and determining what potential problems we could derive from those interviews.

We first started by having a 5-minute silent brainstorming session, where we wrote down as many problems we could think of based on this primer, without considerations for whether or not we could derive solutions for said problems. For this silent brainstorming session, we used the sticky notes feature on Figma to organize our thoughts into specific areas.

Then, we came together as a group to discuss and build off of each other's ideas in order to derive a more narrowed picture of what large problems our product could resolve. During this first discussion, we drew major themes from our user interviews and sticky notes and used that to organize our succeeding brainstorming of potential solutions within those categories.

An example of sketch drawings in our brainstorming session

Brainstorming potential problems to address

From there, we moved on to another 5-minute silent brainstorming session where we tried to come up with as many solutions as possible to the above problems. Like before, we then came back together to discuss and critique each other’s ideas as well as come up with sketches for the ideas that we had presented. Similar to our problem brainstorming, we made a concerted effort to be as creative as possible with potential solutions to the identified problems.

Brainstorming potential solutions to the above problems, building on solutions

After further discussion, we organized our potential solutions by a few different factors, including how well they addressed pain points, the feasibility of implementation, their ability to be implemented by software/under the scope of this course’s goals, and accessibility to the population. This was helpful in ruling out solutions as infeasible for the purposes of this project while finding others to be more feasible.

This brainstorming process was extremely insightful and helpful, as it allowed us to observe each other’s headspace in relation to our project, and creatively collaborate in a way that allowed us to build off of each other's energy.

Getting Promising Ideas

Solution #1: Ingredient Management

This is a mockup demonstrating a user choosing a meal based on their available ingredients and checking their inventory from scanned receipts.

Pros:

Eliminates considerable time spent manually logging ingredients if that is a current activity the user engages in.

Eliminates time and resources spent trying to choose a meal to create by having an accurate catalog of ingredients.

Has applications in monitoring food recalls, expiration dates, and other natural progressions of the technology to build it into a fully-comprehensive solution.
Low technology competence barriers, both in scanning ingredients and in navigating the application.

Cons:

Difficult technical implementation of receipt scanning + ensuring it works extremely consistently. Identifying how you parse those details into data the app can use for determining meals.
Implementation difficulties with removing spent ingredients. Deviation from estimates versus waste that occurs during cooking. Creates manual work for suer that we are attempting to eliminate.
Could be inaccessible to individuals without cameras of a high-enough quality to properly scan receipts.

Solution #2: Group Meal

This is a mockup of an app demonstrating how a user would distribute cooking costs among individuals and send them the payment request.

Pros:

Straightforward technical implementation and UI that individuals are familiar with, as a result of payment app adoption (Venmo, CashApp, Zelle).
Creates concrete receipt of costs and resources, which serves as an underlying use case for operational management.
Distributing costs for an item/activity has a lot of tangential applications that users may find applicable for other use cases outside of our current thinking.

Cons:

Niche use case that is worked around using current tools. Not definitive whether the decrease in time spent distributing costs/work or lost costs/work is made up by using this application. I.e. pain point isn’t properly solved.
To support users, we would need to implement some system of conflict mediation so that individuals are actually receiving compensation. If a key pain point is not being properly compensated, an application that just sends a message, with no real enforcement / encouragement, doesn’t solve the problem.
This is vice versa for individuals on the cooking end and holds individuals accountable for transparent calculations.

Solution #3: Recipe Discovery

Recipe Discovery App: This is a mockup of the app, demonstrating how a user would open the app, swipe through different recipes, choose ones, and be able to make that recipe.

Pros:

Straightforward UI that is easy to navigate and is familiar to most users. Easy implementation of text-to-speak for accessibility purposes.
Filtering adds another organic layer of focused content discovery. Fundamentally solves the cost and time constraints of students discovering recipes.
Straightforward collection of telemetry data to test assumptions of whether we are solving identified pain points.

Cons:

Unclear at what point (if ever) passive use can translate to having memorized/internalized a certain recipe in a way that is less time-consuming than existing methods.
Unclear whether short-form content can successfully capture the necessary information needed to navigate someone through the cooking process for a meal.
Go-to-market would require a critical mass of content producers so individuals can find recipes based on any given food category, time, or cost constraint.

Page updated

Report abuse