Personal Project · UX Research
A research-led exploration of the everyday cooking decision — why it exhausts working professionals, and what a technology-assisted solution might look like if it started from real behaviour rather than a feature list.
The question "what do I cook?" sounds trivial until you have to answer it twice a day, every day, with limited time, a half-stocked kitchen, and a household that has opinions. For working professionals cooking their own meals, this small decision is quietly exhausting — and the alternatives (ordering out, eating at cafeterias) are either expensive or nutritionally frustrating.
Our starting problem statement, sharpened through a decision matrix across eight candidate framings, was this:
That brief told us where the pain was. It didn't yet tell us why. So we went to find out.
We ran a diary study — not interviews or surveys. The reason was deliberate: cooking decisions are habitual, contextual, and often invisible to the person making them. A retrospective interview would have produced rationalised answers. A diary study caught the actual moment — what they cooked, why, what they skipped, and what frustrated them while it was still fresh.
Diary studies generate a lot of noise. Before we could look for patterns we had to standardise the data — cleaning inconsistent phrasing, tagging each entry by participant, and pulling every statement into a shared workspace where the team could scan across all participants at once rather than reading one diary at a time.
Left: affinity groupings beginning to emerge. Right: the full cross-participant scan before clustering.
Scanning across participants rather than within them was the move that mattered. Patterns that looked like personal quirks in one diary showed up as shared behaviour across three or four others. That cross-participant view is where the research started to become insight.
The decision-making insights database — built from every notable statement across all seven participants — was tagged by cognitive factor, type (individual, social, contextual), and the behavioural bias in play. Reading it top to bottom, two threads kept appearing.
Insighting in progress — clustering statements and testing whether the connections held across more than one participant.
All the threads pointed to one underlying truth. It wasn't that people lacked recipes. YouTube has millions. It was that finding the right recipe for right now — given what's in the kitchen, how much time they had, and what they'd eaten the past three days — was the actual unsolved problem. And once cooking felt like a chore with no payoff, the motivation to even engage with that decision collapsed.
That was the insight we chose to design against. Not "how do we teach people to cook" — but "how do we reduce the decision cost and give cooking a reason to feel worth it."
We used a weighted decision matrix to evaluate eight candidate How Might We statements against five criteria: relevance to insight (30%), potential market (20%), revenue potential (20%), skillset alignment (15%), and execution resources (15%). The matrix forced a rigorous conversation rather than a vote on instinct.
The chosen HMW: How might we understand current cooking practices and provide tips and tricks that reduce time and offer varieties of quick and easy recipes?
From there, the same framework was applied to idea selection. The winning concept was direct: a recipe platform for Indians that surfaces recipes based on ingredients already in your kitchen.
Before moving to features, we mapped behavioural archetypes across the participant pool — not demographics, but patterns of decision-making. The archetypes distinguished the Habitual Cook (System 1 dominates: same five dishes, bought on autopilot) from the Aspirational Experimenter (high awareness of what they want to try, high friction at every step) from the Contextual Pragmatist (what I cook is determined by what's in front of me, not what I want).
These archetypes shaped what the product had to do well: for the Habitual Cook, it needed to introduce variety gently without overwhelming defaults. For the Aspirational Experimenter, it needed to lower the barrier to trying something new. For the Contextual Pragmatist, the ingredient-first search model was non-negotiable.
The feature model was built from user stories rather than from what seemed technically interesting. Five feature groups, ranked in order of how directly they addressed the core insight:
This was an early project — done during a design diploma, in two weeks, with a team of five people all new to structured research methods. What it got right was the insistence on going to behaviour first. A diary study was harder to run than a survey and harder to analyse than interviews, but it produced data that a survey never would have — the unguarded moment when someone admits they're just going to make dal again because they can't face the decision.
What I'd do differently: the behavioural archetypes were built from a small, relatively homogeneous pool. The insight that "cooking is not rewarding enough" is real, but the reward mechanism that would actually shift behaviour probably varies significantly across those archetypes. The feature model I'd build today would be archetype-specific — a different onboarding, a different reward framing, a different default recipe surface — rather than a single platform trying to serve all three.