Savor

The real reason people don't use what's in their fridge

Food waste is enormous. The average American household throws away nearly $1,500 worth of food per year. Most sustainability-focused apps approach this as an environmental problem — framing it around carbon footprints, landfill data, and the moral weight of waste. We had a hunch that framing wasn't working.

We ran a survey of 37 participants across different cooking habits and household types to understand how people actually thought about unused ingredients — and what, if anything, would motivate them to cook with them instead of letting them spoil.

Survey results (37 respondents): cooking frequency, recipe confusion, and how often people look up recipes.

Where people look for recipes (Google Search at 83.8%, people in real life at 51.4%) and the variety of dietary needs we'd need to accommodate.

Key findings from the survey and follow-up interviews:

Reframing sustainability as financial self-interest

This reframe shaped every design decision in Savor. Instead of a "reduce your waste" message, we leaded with cost per serving and ingredient match — making the financial benefit of cooking what you have visible at every step.

We also needed to accommodate real dietary complexity. Our survey revealed 38% of respondents had some dietary restriction: Halal, gluten-free, allergies, low-cholesterol, dairy-free. The filtering system had to be robust enough to be genuinely useful, not performative.

The core features we defined:

From icons to interface: building the Savor system

The design process started with branding — because Savor needed a personality distinct from the clinical, calorie-counter aesthetic of most food apps. We developed a warm, friendly visual language: amber and off-white, an illustrated food mascot character, and hand-drawn icon assets that felt approachable and slightly playful.

Brand system: the Savor logo, app icon variants, the mascot character, and hand-drawn food and UI icon set.

From there, wireframes established the navigation structure and core interaction patterns before moving to high-fidelity. The challenge in wireframing the home screen: how do you surface the ingredient-input feature prominently without burying discovery and community content?

Early wireframes exploring the home screen layout, filter panel, and recipe card structure.

High-fidelity screens

The login and onboarding screens established the brand tone immediately — warm, animated, and with an intake survey that captured dietary restrictions upfront so they never had to be set again.

Login screen (left) and the core home screen (right) — ingredient input, dietary restrictions, cuisines, and price range all surfaced on arrival.

Recipe results page (left) — cost per serving and cooking time shown upfront, with tag-based filtering visible on the results themselves. The Discover screen (right) — organized by meal type and category, with trending recipes below, for spontaneous browsing beyond ingredient-driven search.

The reframe that made it work

The most important design decision in Savor had nothing to do with the interface — it was the decision to lead with financial value instead of sustainability messaging. That insight came directly from the interviews, not from assumptions. Without the research, we would have built a perfectly competent app that no one actually opened twice.

The design challenge that remains: recipe recommendation relevance. Ingredient-based matching is harder than it looks — two people with the same four ingredients might want wildly different things based on their energy level, cooking skill, and what they had for lunch. The next iteration would invest in a more nuanced preference model, informed by usage patterns and explicit user feedback on recipe quality.

Before Savor, there was Cookin' Cubby

Cookin' Cubby was an earlier project exploring the same problem space — helping people cook smarter with what they have. It's worth including here not just as a "v1," but because the research conducted for Cookin' Cubby directly shaped the decisions that made Savor stronger. This is what an iterative design process actually looks like: the first version reveals what the second version needs to be.

Cookin' Cubby approached the problem from a slightly different angle: a recipe community platform with ingredient-based search, bookmarking, a community forum, and recipe upload capability. More features, broader scope — and in retrospect, less focused than it needed to be.

Survey data that drove feature priorities

The same 37-person survey that informed Savor was originally conducted for Cookin' Cubby. From the survey data, the team identified the features users most wanted in a recipe app:

• Ingredient-based recipe suggestions, price filters, bookmarking, and community features ranked highest among desired capabilities
• Inclusion/exclusion filters for dietary needs surfaced as a key requirement
• Recipe discovery and community interaction rated as high-value features
• Simple, accessible UI — including dark mode — came through as a top-five priority

The top requested features from this research:

What Cookin' Cubby taught us to do differently

Cookin' Cubby tried to do too much at once. The community forum, recipe upload, and social features added complexity without adding enough value for the primary use case — figuring out what to cook tonight. The scope made every individual feature feel underdeveloped.

Savor stripped back to the core: ingredient-first search with excellent filtering and real cost data. The community and discovery features stayed, but they were secondary — not co-equal to the core job-to-be-done.

The branding also shifted significantly. Cookin' Cubby was playful but undefined. Savor's amber-and-cream palette with the hand-drawn mascot character gave the app a consistent, ownable personality — one that could carry across marketing, onboarding, and empty states without feeling forced.

A beloved app with real UX debt

MyFitnessPal is one of the most widely used food and fitness tracking apps in the world — but its interface carries years of accumulated design debt. The redesign study began with a comprehensive UX audit: cataloging usability issues, inconsistent patterns, and structural problems in the existing app before proposing solutions.

The core issues identified:

Respecting the brand while solving real problems

The design system study established that MyFitnessPal's existing brand — blue/yellow/black, Helvetica Neue, clean and confident — was still strong. The redesign didn't need to change the brand; it needed to apply it more consistently and clear the interface of friction.

Design system study: the existing MFP color palette and type scale were sound — the redesign preserved them while addressing structural issues.

Key redesign decisions

The most significant intervention was the onboarding flow. Rather than jumping straight to calorie tracking, the redesigned onboarding asks one meaningful question up front: "When it comes to improving your health, which is most important?" The answer (weight, general health, health metrics, or becoming more active) shapes the dashboard that appears on first login — so the experience feels built for you, not just a blank calorie counter.

Redesigned login (left) — cleaner, less noisy. Redesigned onboarding goal selection (right) — one question that makes the rest of the experience feel personal.

Redesigned daily summary and community screens — decluttered navigation, removed ad banner, and a community feed with consistent card treatment.

What this study contributed

The MFP redesign was a structured exercise in designing within constraints: you can't change the business model (so the Premium upsell stays, it just moves), you can't break existing mental models (so the nav labels stay, just reorganized), and you can't start from scratch (so every decision has to justify itself against the existing design). This is closer to most real-world design work than starting from a blank canvas — and it made me a sharper critic of my own design choices.