Foodai — UX/UI Redesign of an AI-Powered Nutrition App
What started as a technically oriented MVP with the standard iOS look evolved into an app with a clear information architecture, its own visual identity, and a design system.
Company | Product
InfinityAppCraft | Foodai
My Role
Product Designer
Team
Product Manager
Developer
Developer
Timeline
10/2024 – 09/2025
Scope
UX Research
Product Strategy
UX/UI Design
Prototyping
Testing
Design System
Overview
End-to-end redesign of the Foodai consumer app. Research, restructuring of the information architecture and all core flows, new UI and design system. This case study highlights the three main flows.
Structural Impact
Moved the core action from the submenu to the main navigation
Recipe Management from 2 Tabs to 1 Flow
Scattered Filters restructured into a Two-Level System
A Custom Visual Identity Instead of the Standard iOS Design
The release has not yet been approved by the client, so there are no performance data from actual use. The usability test shown here is formative.
BACKGROUND & PROBLEMS
The foodai app uses AI to generate personalized recipes, addressing the question we all ask ourselves every day: What should I cook today?
The basic architecture of the MVP was already in place, though it featured the standard iOS look.
I was commissioned to create a branded UI with its own visual identity. However, it became clear early on in our discussions that, in addition to the look and feel, structural work on the information architecture and user flows would also be necessary.
The Key Issues
Confusing navigation:
The “Chat” tab did not lead directly to the recipe generation screen, but rather to an intermediate screen with a “New Chat” button.
Generated recipes were stored as unstructured chat histories under “Chat” and, after being saved, as converted recipe cards under “Recipes.”
Spread across several menus, and with content that's too limited to provide a truly personalized experience.
THE OBJECTIVE
Direct access, one location per task, filters as a system
RESEARCH
01 · Competitive Analysis
Question:
What functional advantages does foodai offer compared to other recipe planners?
Method:
A Comparison of Five Apps Based on Positioning, Personalization, Features, Monetization, Ratings, and UI
Findings:
Curated recipe catalogs and databases become repetitive after just a few weeks, and users see the same dishes over and over again. Users in 4 out of 5 apps report that ads and upselling, before any real value is even created, are a common problem.
02 · Online survey, 47 responses (not representative)
Question:
What is everyday life really like when it comes to planning, shopping, and cooking?
Method:
Quantitative and qualitative questions, analyzed using charts and affinity mapping.
Findings:
No one consistently plans ahead; about 64% cook based on the ingredients they have on hand, and for more than half, daily life is spontaneous. 43% have specific dietary needs, and 30 out of 39 don't know how to substitute the necessary ingredients.
03 · Heuristic UX Audit According to Nielsen
Question:
Where are the problems in the current MVP?
Method:
All core screens were systematically checked for friction points and heuristic violations.
Findings:
The audit confirmed the team's hypotheses and provided concrete evidence to support them. The main issues were the unclear process for initiating data generation, recipe management spread across two screens, a lack of transparency regarding token usage, and an underdeveloped filtering system.
View selected screenshots from the audit:
Additional Research Findings
Competitive Analysis
Recipe fatigue
Competitive Analysis
Monetization
UX Audit
Transparency
The token counter isn't visible throughout, so consumption stays opaque.
Survey
Spontaneous, not planned
Survey
Specific dietary needs
Conclusion
Since the structural problems surfaced in the audit underpinned every decision that followed, the work started with the information architecture rather than the visual design I had originally been briefed for.
DEFINE
One location per task: the new navigation structure
I visualized the MVP’s information architecture as a sitemap and a simplified user flow to highlight dependencies and navigation logic. This allowed me to reorder the flows until a coherent picture emerged.
Each core flow was given its own spot in the tab bar:
Discovery — Inspiration and Suggestions
Generate — the central action, now directly accessible instead of hidden behind a chat tab
Recipes — one storage location instead of two
Shopping — the new shopping list feature, in the former location of the settings
The profile settings were moved to the header, closer to the token display, which can now also be accessed directly from the balance.
The image shows the sitemap and the core user flow for generating recipes, each with a “before” and “after” view.
Filters as a continuous system instead of a hidden menu
I've rethought filters and divided them into two levels:
Global — filters that are always active are part of the personal profile and are located in the settings
Situational — optional filters for each recipe, in addition to or instead of the prompt
The key is that the filters are attached to the recipe as tags, creating consistent brand recognition. This ranges from setting visible feature tags on the recipe card to searching saved recipes by tag. In the “Discover” section, these tag themes generate random quick-start suggestions.
DESIGN
Wireframing
Based on the new structure, I developed module-based wireframes.
The most important decision was made regarding the generation screen. In the MVP, the filter and prompt input were on two separate screens, and when switching to the chat window, the selected filters were no longer visible, even though they influenced which recipe was generated. Now both are on a single screen. You can see at a glance what you can enter and which filters are active.
Before and after the three main workflows:
Top Design Decisions
01 Straight into generating
02 One place per task
03 Filters as a system throughout
→ UX audit: nested inside the settings, allergies mixed in with diets → Survey: 43% with specific dietary needs (not accounted for so far)
04 Generated shopping lists
New feature: generated shopping lists
Every recipe can be turned into a shopping list, and several can be bundled together. The idea came straight out of the survey, and out of the potential to connect a delivery service later on. The shopping list is already an established tool, but the planning work behind it barely happens, and that's exactly what generating takes off people's hands.
A visual language between AI, chat and healthy food
The visual language had to bring together three things: technological intelligence, the chat-based way of interacting, and healthy food. Fresh, food-related colors form the basis for that.
(Leaf) green — primary color for interactions
(Carrot) orange — tokens and special notices
Deep orange — error messages and delete states
(Ceramic) white — whitespace
(Charcoal) black — text
The same color logic carries through into the filter tag system: every tag carries its own emoji, intolerances sit on an orange background so they stand out as critical markers, and diets are green. Typography, iconography and layout follow familiar chat and messenger patterns, which keeps interacting with AI accessible even for users who have little experience with AI tools.
Color scheme used: Primary green for actions, orange for tokens and incompatibilities.
To that end, I developed a new brand logo for foodai that incorporates the color scheme and also functions as a loading animation.
Design System as Single Point of Truth
A component-based design system was developed in parallel with the UI. The goal was to create a non-destructive design foundation. Changes to a variable or component take effect globally, without requiring manual maintenance and without breaking existing screens.
All color and size values are tokenized. Semantic and component-related tokens were developed in collaboration with the developers and are stored in Figma’s variable library, along with documentation serving as a guide for their structure and correct usage.
This approach yielded two key benefits: screen designs could be adapted via components and tokens during reviews and iterations, rather than manually. And the handoff to the development team went more smoothly because the component names could be adopted almost exactly as-is.
TESTING
Test: Does the new structure work in practice?
Development of the new UI began, resulting in a TestFlight functional prototype. I used this to conduct a moderated, formative usability test with 8 task scenarios aligned with the core interaction flows.
6 participants — approached spontaneously in downtown Munich on their way home
8 tasks — target paths defined in advance, evaluated on a four-point scale
Formative, not comparative — the MVP had never been systematically tested, so a before-and-after comparison was not possible
The new structure held up; the problems were visual in nature
Navigation, as well as recipe and shopping list management, functioned in their basic structure and were easy to find. The problems lay almost exclusively with individual elements, not with the information architecture. These included, among other things, elements that were misplaced or not clearly recognizable as interactive.
Iterations
Task 2 - Enter Prompt
P2 started in the “Discover” tab,
P3 and P5 missed the prompt entry because the filter drop-down menus were open.
(3 out of 6 correct)
The prompt input was placed as a floating, fixed element above the tab bar. “Generate” moved from position 3 to position 2 in the tab bar, making it fit more logically into the flow.
(See before-and-after visualization)
Task 5 - Top Up Token Balance
Almost no one recognized the token display in the header as an interactive element; 5 out of 6 took the detour through the settings.
(1 out of 6 correct)
A plus icon in the token display now clearly indicates that tokens can be added.
(See before-and-after visualization)
Task 7 - Generate Shopping List
The button was too inconspicuous; P3 and P6 searched through tabs and headers before they found it.
(3 out of 6 correct)
Additional Optimizations (Not Derived from the Test)
Token Usage Before Generation
Actions that consume tokens are now clearly marked with a usage indicator on the respective action button.
(See before/after visualization)
Higher text contrasts
Text contrast ratios have been increased overall.
In addition, the focus on the recipe card is now specifically on the numerical values for nutritional information and ingredients, and on the shopping list, on the ingredient names. When cooking and reviewing the recipe, the quantities are most important; when shopping, the ingredient names are most important.
Servings Removed as a Filter
Servings have been removed as a standalone recipe filter.
As was originally the case in the MVP, this setting is configured exclusively via the stepper on the recipe card.
This saves resources during recipe generation, since the quantity can be calculated after the recipe is generated.
Deferred Optimizations
The following findings were intentionally set aside as having medium to low priority and will be optimized based on further test runs.
Global vs. Situational Filters
This distinction should be explained during onboarding and, if necessary, given a different name.
“Bundle” Shopping Lists Promotion
The placement and explanation may need improvement; the solution should be determined after further testing.
Mixed Diets
Further testing should determine whether detailed combinations are necessary or whether the categories Omnivore / Vegetarian / Vegan / Pescatarian / Flexitarian / Keto cover most cases.
For first-time users, a note may be needed explaining which foods are included in each category and which are not.
Kitchen Appliances and Cooking Methods
In addition, the idea arose to include appliances as a separate filter category in order to find recipes for specific appliances, such as air fryers, or to exclude appliances like the oven.
The priority for now is a fully functional release.
Only real-world usage data will reveal which of these points should be given higher priority.
In addition to the test iterations, I refined token transparency, text contrast, and the filter logic. I deliberately set aside other findings with medium to low priority; the priority at first was to deliver a functional release.
Reflections & Open Questions
Thinking beyond the scope of the project paid off
I was hired for the visual design; the less-than-perfect UX was mentioned in passing, apparently with the hope of a quick fix. The UX audit then revealed structural issues and showed that the MVP had never been tested with external users. Taking the initiative to get to the bottom of the problems was challenging, but it built mutual trust.
If you think it’s too early to test, it’s usually not early enough
In hindsight, I would have liked to have tested the MVP right at the start with a usability test to have real data points instead of assumptions. I had argued for this early on, but I wasn’t able to convince them until I had results from the audit and survey. With fixed-price quotes, an initial test can be firmly scheduled; with hourly billing, the client ultimately decides how their hours are used.
Open Questions
Does a permanently visible token status create subjective pressure, thereby pitting profit motives against user goals? How reliably does the AI estimate nutritional values and suggest substitute ingredients for food intolerances? And does generative AI truly solve the recipe fatigue problem in database-driven apps, or does a pattern of repetition eventually set in there as well?