AS
AS
Building an intelligent recipe tool built to personalize cooking
AI Exploration: Designing Trust in AI-Generated Recipes
AI Exploration: Designing Trust in AI-Generated Recipes
Sabor, a live mobile app, adapts recipes in real time based on ingredients, preferences, and skill level
Balancing personalization and safety through visible and invisible design
Role + Team
Sole Product Designer and Developer
Timeline
Initial Exploration: Summer 2023 (8 weeks)
Production Build: Winter 2025 (4 weeks)
Total development: 12 weeks across 18 months
Tools Used
Designed in Figma, Built with Next.js + Tailwind + Supabase, Powered by Gemini API, Deployed on Vercel
Essential Goal
Design and build cooking tool that adapts to each cook’s creativity, taste, and culture while protecting user trust, control, and safety
AI Exploration: Designing trust in
AI-generated recipes
Role + Team
Sole Product Designer and Developer
Sole Product Designer and Developer
Timeline
Initial Exploration: 8 weeks
Production Build: 4 weeks
Tools Used
Designed in Figma, Built with Next.js + Tailwind + Supabase, Claude Code, Powered by Gemini.
Project Goal
Design and build a personalized AI recipe tool that protects user trust, control, and safety
Overview
Overview
SABOR is a cooking tool that tailors recipes to fit a cook's needs, born out of the challenge of navigating allergies, portion sizes, and preferences when cooking the dishes we love.
SABOR is a cooking tool that tailors recipes to fit a cook's needs, born out of the challenge of navigating allergies, portion sizes, and preferences when cooking the dishes we love.
SABOR's design is two-fold, consisting of the visible and the invisible
SABOR's design is two-fold, consisting of the visible and the invisible
The visible: AI UI
The visible: AI UI
How do we earn the trust of the user?
How do we earn the trust of the user?
The invisible: Prompt Design
The invisible: Prompt Design
How do we design a trust-worthy algorithm?
How do we design a trust-worthy algorithm?
YOUR PURPOSE: You are a trustworthy recipe assistant. Your job is to help people connect with recipes they want to make. You are honest, grounded, and never pretend to know something you don't. YOUR PERSONALITY: - Friendly and encouraging, like a helpful cooking buddy - Warm but professional, people trust you with food safety - Enthusiastic about food without being preachy - Never condescending; supportive of all skill levels - Culturally respectful when discussing cuisines from other regions USER REQUEST RESPECT - The user has requested a SPECIFIC recipe. You MUST generate EXACTLY that recipe, not a substitute. - Do NOT reinterpret or suggest alternatives unless explicitly asked. - If user says "taco chicken hoagie", the recipe MUST BE a taco chicken hoagie. - If user says "chocolate cake", the recipe MUST BE a chocolate cake. - Match the user's request as literally and faithfully as
Sabor has five key features that support the human-AI co-creation of a safe, delicious recipe.
Sabor has five key features that support the human-AI co-creation of a safe, delicious recipe.
Sabor's Key Features
1
Recipe Sourcing + Social Proof
Earning the user's trust in the generated recipes through source citations showing how the recipe was created
2
In-Context Recipe Editing
A novel interaction for workshopping a recipe, users may:
adjust serving size
adjust ingredient quantities
remove ingredients
ask for ingredient suggestions
3
Version History
Making recipe changes transparent for trust and confidence
4
Sabor Onboarding + Profile Creation
Constantly learning from the user's preferences
Sabor's Key Features
1
Recipe Sourcing
+ Social Proof
Earning the user's trust in the generated recipes through source citations showing how the recipe was created
2
In-Context
Recipe Editing
A novel interaction for editing and workshopping a recipe,
users may:
-adjust serving size
-adjust ingredient quantities
-remove ingredients
-ask for ingredient suggestions
3
Version History
Making recipe changes transparent for trust and confidence
4
Sabor Onboarding + Profile Creation
Constantly learning from the user's preferences
Overview
SABOR is a cooking tool that tailors recipes to fit a cook's needs, born out of the challenge of navigating allergies, portion sizes, and preferences when cooking the dishes we love.
SABOR's design is two-fold, consisting of the visible and the invisible
The visible: AI UI
How do we earn the trust of the user?
The invisible: Prompt Design
How do we design a trust-worthy algorithm?
YOUR PURPOSE: You are a trustworthy recipe assistant. Your job is to help people connect with recipes they want to make. You are honest, grounded, and never pretend to know something you don't. YOUR PERSONALITY: - Friendly and encouraging, like a helpful cooking buddy - Warm but professional, people trust you with food safety - Enthusiastic about food without being preachy - Never condescending; supportive of all skill levels - Culturally respectful when discussing cuisines from other regions USER REQUEST RESPECT - The user has requested a SPECIFIC recipe. You MUST generate EXACTLY that recipe, not a substitute. - Do NOT reinterpret or suggest alternatives unless explicitly asked. - If user says "taco chicken hoagie", the recipe MUST BE a taco chicken hoagie. - If user says "chocolate cake", the recipe MUST BE a chocolate cake. - Match the user's request as literally and faithfully as
Sabor has five key features that support the human-AI co-creation of a safe, delicious recipe.
Sabor's Key Features
1
Recipe Sourcing + Social Proof
Earning the user's trust in the generated recipes through source citations showing how the recipe was created
2
In-Context Recipe Editing
A novel interaction for workshopping a recipe, users may:
adjust serving size
adjust ingredient quantities
remove ingredients
ask for ingredient suggestions
3
Version History
Making recipe changes transparent for trust and confidence
4
Sabor Onboarding + Profile Creation
Constantly learning from the user's preferences
Sabor's Key Features
1
Recipe Sourcing
+ Social Proof
Earning the user's trust in the generated recipes through source citations showing how the recipe was created
2
In-Context
Recipe Editing
A novel interaction for editing and workshopping a recipe,
users may:
-adjust serving size
-adjust ingredient quantities
-remove ingredients
-ask for ingredient suggestions
3
Version History
Making recipe changes transparent for trust and confidence
4
Sabor Onboarding + Profile Creation
Constantly learning from the user's preferences
Problem + Research
Problem + Research
Sabor's foundational strategy is based off of three rounds of generative and evaluative research with 15 cooks, which informed the value-add and AI interaction patterns I needed to design for.
Sabor's foundational strategy is based off of three rounds of generative and evaluative research with 15 cooks, which informed the value-add and AI interaction patterns I needed to design for.
Sabor's foundational strategy is based off of three rounds of generative and evaluative research with 15 cooks, which informed the value-add and AI interaction patterns I needed to design for.
Generative Research
Generative Research
Generative Research
Understanding the biggest pain points of modern cooking through 5 user interviews, and leverage a JTBD framework to synthesize.
Understanding the biggest pain points of modern cooking through 5 user interviews, and leverage a JTBD framework to synthesize.
Understanding the biggest pain points of modern cooking through 5 user interviews, and leverage a JTBD framework to synthesize.
1
1
Cultural recipes are difficult to replicate in taste.
Cultural recipes are difficult to replicate in taste.
Cultural recipes are difficult to replicate in taste.
2
2
Cultural recipes don’t fit into my lifestyle, such as my dietary preferences and resources.
Cultural recipes don’t fit into my lifestyle, such as my dietary preferences and resources.
Cultural recipes don’t fit into my lifestyle, such as my dietary preferences and resources.
3
3
Cultural recipes are often inaccessible; whether in resources and or ingredient preparation.
Cultural recipes are often inaccessible; whether in resources and or ingredient preparation.
Cultural recipes are often inaccessible; whether in resources and or ingredient preparation.
user JTBD
As a user.....
As a user.....
I want to save recipes and workshop them later
I want to save recipes and workshop them later
I want to edit a recipe without the fear of making mistakes
I want to edit a recipe without the fear of making mistakes
I want to customize a recipe to my dietary needs without lengthy research
I want to customize a recipe to my dietary needs without lengthy research
I want to modify a recipe’s nutrition to achieve my goals without lengthy research
I want to modify a recipe’s nutrition to achieve my goals without lengthy research
I want straightforward, ingredients and instructions that I can reference on the go
I want straightforward, ingredients and instructions that I can reference on the go
I want tips that I might not know to ask for
I want tips that I might not know to ask for
user JTBD
While Sabor began as a solution for cooking cultural meals, it evolved to all type of home-cooked meals as the pain points discovered were consistent across all types of cooking.
While Sabor began as a solution for cooking cultural meals, it evolved to all type of home-cooked meals as the pain points discovered were consistent across all types of cooking.
Evaluative Research
Evaluative Research
Evaluative Research
Understanding how to design key interaction patterns through 2 rounds of 45-minute contextual inquiries and usability tests, for a total of 10 testers.
Understanding how to design key interaction patterns through 2 rounds of 45-minute contextual inquiries and usability tests, for a total of 10 testers.
Understanding how to design key interaction patterns through 2 rounds of 45-minute contextual inquiries and usability tests, for a total of 10 testers.
Some of the first insights that guided the UI of the app
Some of the first insights that guided the UI of the app
Design Iterations
Design Iterations
Sabor's interface went through four major iterations. The key novel interaction, in-recipe editing, evolved through research insights and implementation constraints.
Sabor's interface went through four major iterations. The key novel interaction, in-recipe editing, evolved through research insights and implementation constraints.
Sabor's interface went through four major iterations. The key novel interaction, in-recipe editing, evolved through research insights and implementation constraints.
Four Iterations of Feature 2: In-Context Recipe Editing
Four Iterations of Feature 2: In-Context Recipe Editing
Four Iterations of Feature 2: In-Context Recipe Editing
Version 0:
Very Early Wireframing
(No testing, only foundational interviews)
Version 0:
Very Early Wireframing
(No testing, only foundational interviews)
Version 3~ :
Post Heuristics Analysis +
Initial Usability Testing
Version 3~ :
Post Heuristics Analysis +
Initial Usability Testing
Version 30~ :
Post Initial Development +
2nd Round of Usability Testing
Version 30~ :
Post Initial Development +
2nd Round of Usability Testing
Live MVP (Version 35~ )
Post Development Constraints +
Initial Contextual Inqueries
Live MVP (Version 35~ )
Post Development Constraints +
Initial Contextual Inqueries
Four key decisions informing Sabor's visible and invisible design
Four key decisions informing Sabor's visible and invisible design
Decision One: Designing for Trust
Recipe Generation is the first interaction users have with Sabor, so it needs to earn their trust that Sabor is reliable.
The Tension
When a user asks for a recipe, should Sabor prioritize honoring the user's request as closely as possible or returning a recipe with speed?
Specifically, should Sabor return a fully personalized, potentially inaccurate (slower) AI-generated recipe result OR a potentially less personalized, accurate stored (faster) recipe?
Option
Pro
Con
Always AI-generated
Very personalized
Latency and room for error
Always matched from database
No latency and tested accuracy
Possibly less personalized
The Decision
Prioritize personalization and generate a new recipe unless we are 90%> confident a stored recipe is a match.
Visible AI UI
Invisible Prompt Design
User searches a recipe
Sabor searches the saved recipes database for a match with 90% confidence
Finds a match?
YES
NO
Return stored recipe
(potentially less personalized, instant)
Generate new recipe
(personalized, slower)
Decision Two: Designing for Control
Sabor's primary value-add is recipe customization. Users can customize almost all parts of a recipe on the recipe itself: servings can be adjusted and ingredients can substituted, removed, or adjusted.
The Tension
When a user is editing a recipe, should we prioritize user control over the recipe or system control over the recipe's integrity?
Option
Pro
Con
Full freedom
(edit all parts of a recipe)
Maximum personalization
Users could break the recipe or create unsafe combinations
Limited editing
(edit only certain fields)
Protects users from mistakes
Might feel restrictive and decrease the value of the app
The Decision
Protecting user cognitive load and safety is tablestakes. Limit what a user can edit in a recipe, to prioritize robust edit parameters and decrease the likelihood of hallucinations.
Visible AI UI
Invisible Prompt Design
A code snippet from the 'adjust ingredient quantity' backend:
When adjusting ingredient quantities, ensure: - Spice levels remain safe (don't make it dangerously spicy) - Cooking times remain accurate for the adjusted portions - Ingredient ratios don't create unsafe combinations - Allergen warnings are preserved
Decision Three: Designing for Latency
When generating and editing a recipe, the user will face latency, but with too much Sabor might lose its convenience value-add.
The Tension
How do we balance providing a seamless UX and minimal latency?
Specifically, should Sabor minimize the number of steps or minimize perceived latency?
Option
Pro
Con
Minimize steps
Less steps
Longer latency and more risk of time-outs
Minimize latency
Shorter latency
More steps
Scenario: The user removes a critical ingredient from the recipe
Option A: Less steps, longer latency
User chooses to remove ingredient
Sabor processes removal impact AND generates substitution options
(10 second wait time)
(SABOR BLOCKS)
(SABOR BLOCKS)
Sabor shows substitutes
User cancels,
keeps original recipe
User chooses substitute
Sabor substitutes ingredient,
returns New Recipe
(5 second wait time)
Option B: More steps, shorter latency
User chooses to remove ingredient
Sabor processes removal impact
(5 second wait time)
User previews impact
(SABOR BLOCKS)
(SABOR BLOCKS)
User confirms substitutes
User cancels,
keeps original recipe
Sabor gets
substitutes, shows
(5 second wait time)
User chooses substitute
Sabor substitutes ingredient,
returns New Recipe
(5 second wait time)
The Decision
Minimize latency at the cost of more steps. Three shorter steps with feedback feels faster than one long wait. This also gives users more control on when they will see latency and why.
Visible AI UI
When a user tries to remove a critical ingredient, a task that requires multiple steps to evaluate, include pauses into the process for the user to confirm the action
Invisible Prompt Design
A code snippet of the AI evaluating whether an ingredient is safe to be removed:
Warn user if removing a critical safety ingredient (e.g., salt in preservation recipes, leavening agents in baked goods) NEVER allow removal of ingredients if it would create unsafe food If removal compromises food safety, explain and suggest alternatives Preserve allergen warnings even if main ingredient is removed
Decision Four: Ensuring Safety through Architecture
Sabor is a recipe app, making mistakes especially dangerous. As such, I built safety checks at two levels - code validation and prompt guardrails - so the AI alone isn't responsible for user safety.
How Safety is Layered in the System
User searches a recipe
Sabor validates search with hard-coded filters
FAILS FILTERS
PASSES FILTERS
Sabor blocks recipe
AI + Prompt Guardrails
IF UNSAFE
Gemini blocks recipe, redirects
Visible AI UI
Redirect the user when an unsafe choice is made, whether it be an unsafe explicit query or an unsafe implicit one (ie search for something they may be allergic to)
Invisible Prompt Design
Implement safety architecture inside of every API call
Layer One: Hardcoded Input Validation
// Hardcoded safety validation for Sabor //- no AI required // These filters run BEFORE any API //call to protect users // Dangerous raw/undercooked preparations const UNSAFE_RAW = [ "raw chicken", "raw pork", "undercooked pork", "raw ground beef"];
Layer Two: Prompt behavior for nuanced safety decisions
1. NEVER suggest poisonous, toxic, or harmful ingredients as substitutes 2. NEVER create unsafe ingredient combinations 3. Only suggest substitutes that maintain food safety standards 4. Preserve cooking methods - don't suggest raw substitutes for cooked ingredients
Takeaways
Takeaways
If I could build Sabor again, I would think more rigorously about design for observability from day one.
I designed Sabor to personalize and workshop recipes while maintaining food safety. While Sabor's UX fills the intended function, testing it's outputs revealed a gap in safety. I realized that I could not safely validate recipes because I could not guarantee the algorithm would not hallucinate.
If I were to build Sabor again, I would intentionally build in more safety mechanisms and metrics. I would start off with two questions.
Metric 1
Metric 1
When and how often are recipes hallucinating?
I would measure hallucination rates through constant accuracy tests on recipe ingredients, substitutions, and sources. I would also track user feedback: specifically, adding in the option for users to report mistakes.
To mitigate these, I would implement a RAG system, consisting of a database of what food edits are permissible and safe.
This is important because minimizing hallucination rates is critical to maintain user safety and trust.
Metric 2
Metric 2
Does the 90% routing threshold serve user needs?
I built in a 90% threshold when the algorithm is deciding whether to make a brand new API call or show a recipe from the database.
I would measure the behavioral cue of how often a user re-does the search and downvotes a recipe. I would build in a feature to let the user report an inaccurate generation, specifically.
This matters because if our recipes do not feel personalized or convenient, Sabor loses its value proposition.
Thank you for reading!
Thank you for reading!
Thank you for reading!
I am currently working on sharing more of my experience building SABOR and will update this case study soon. In the meantime, feel free to explore Sabor here:
Thanks for stopping by!
Thanks for stopping by!
Let's connect?
Thanks for stopping by!
Let's connect?