Foodai — UX/UI-Redesign einer KI-gestützten Ernährungs-App
Aus einem technisch gedachten MVP im Standard iOS-Look wurde eine App mit klarer Informationsarchitektur, eigener visueller Identität und einem Design System.
Unternehmen | Product
InfinityAppCraft | Foodai
Meine Rolle
Product Designer
Team
Product Manager
Entwickler
Entwickler
Timeline
10/2024 – 09/2025
Umfang
UX Research
Produkt Strategie
UX/UI Design
Prototyping
Testing
Design System
Überblick
End-to-end Redesign der Consumer-App Foodai. Research, Neustrukturierung der Informationsarchitektur und aller Kernflows, neues UI und Design System. Diese Case Study zeigt die drei zentralen Flows.
Struktureller Impact
Kernaktion aus dem Untermenü in die Hauptnavigation
Rezeptverwaltung von 2 Tabs auf 1 Flow
Verstreute Filter zu einer 2-Ebenen Systematik
Eigene visuelle Identität statt iOS-Standard
Der Release steht auf Auftraggeberseite noch aus, Wirkungsdaten aus realer Nutzung liegen daher nicht vor. Der gezeigte Usability-Test ist formativ.
AUSGANGSLAGE & PROBLEME
Die foodai App generiert KI-basiert personalisierte Rezepte und folgt dabei der täglich wiederkehrenden Frage: Was soll ich heute kochen?
Die Grundarchitektur des MVP stand, allerdings im iOS Standardlook.
Beauftragt war ich für ein branded UI mit eigener visueller Identität. Schon in den ersten Gesprächen zeigte sich jedoch, dass neben Look & Feel auch strukturelle Arbeit an Informationsarchitektur und Flows nötig ist.
Die zentralen Probleme
Der Tab "Chat" führte nicht direkt in die Rezeptgenerierung, sondern auf eine Zwischenansicht mit "Neuer Chat"-Button.
Generierte Rezepte lagen als unstrukturierte Chatverläufe unter "Chat" und nach aktivem Speichern als umgewandelte Rezeptkarte unter "Rezepte".
Über mehrere Menüs verteilt und dabei inhaltlich zu knapp für ein wirklich personalisiertes Erlebnis.
DAS ZIEL
Direkter Einstieg, ein Ort pro Aufgabe, Filter als System
RESEARCH
01 · Konkurrenzanalyse
Frage:
Welchen funktionellen Wert hat foodai gegenüber anderen Rezeptplanern?
Methode:
Fünf Apps im Vergleich entlang Positionierung, Personalisierung, Funktionen, Monetarisierung, Ratings und UI
Erkenntnisse:
Kuratierte Rezept Katalogen und Datenbanken erschöpfen sich nach Wochen, Nutzer*innen sehen immer dieselben Gerichte. Werbung und Upselling bevor überhaupt Mehrwert entsteht, wird in 4 von 5 Apps von Usern als häufiges Problem empfunden.
02 · Online-Umfrage, 47 Antworten (nicht repräsentativ)
Frage:
Wie sieht der Alltag rund um Planen, Einkaufen und Kochen wirklich aus?
Methode:
Quantitative und qualitative Fragen, ausgewertet in Diagrammen und per Affinity Mapping.
Erkenntnisse:
Niemand plant konsequent voraus, ca. 64 % kochen nach vorhandenen Zutaten, bei über der Hälfte verläuft der Alltag spontan. 43 % haben spezifische Ernährungsbedürfnisse, und 30 von 39 wissen nicht, wie sie entsprechende Zutaten ersetzen können.
03 · Heuristischer UX Audit nach Nielsen
Frage:
An welchen Stellen liegen Probleme im bestehenden MVP?
Methode:
Alle Kernscreens systematisch auf Reibungspunkte und Heuristik-Verletzungen geprüft.
Erkenntnisse:
Der Audit bestätigte die Hypothesen aus dem Team und machte sie konkret belegbar. Die wesentlichen Probleme waren der unklar benannte Einstieg in die Generierung, die über zwei Screens verteilte Rezeptverwaltung, fehlende Transparenz beim Tokenverbrauch und eine unausgereifte Filtersystematik.
Ausgewählte Screens des Audit ansehen:
Weitere Research Findings
Konkurrenzanalyse
Rezept Ermüdung
Konkurrenzanalyse
Monetarisierung
UX Audit
Transparenz
Die Tokenanzeige ist nicht durchgängig sichtbar, der Verbrauch bleibt intransparent.
Umfrage
Spontan statt geplant
Umfrage
Spezifische Ernährungs-bedürfnisse
Schlussfolgerung
Weil die strukturellen Probleme aus dem Audit allen weiteren Entscheidungen zugrunde lagen, begann die Umsetzung bei der Informationsarchitektur, nicht beim Visual Design, für das ich ursprünglich beauftragt war.
DEFINE
Ein Ort pro Aufgabe: die neune Navigationsstruktur
Ich habe die Informationsarchitektur des MVP als Sitemap und vereinfachten User Flow visualisiert, um Abhängigkeiten und Navigationslogik sichtbar zu machen. So ließen sich Flows verschieben, bis ein schlüssiges Bild entstand.
Jeder Kernflow bekam einen eigenen Platz in der Tabbar:
Entdecken — Inspiration und Vorschläge
Generieren — die zentrale Aktion, jetzt direkt statt hinter einem Chat-Tab
Rezepte — ein Speicherort statt zwei
Einkaufen — die neue Einkaufslisten-Funktion, auf dem ehemaligen Platz der Einstellungen
Die Profileinstellungen wanderten in den Header, näher an die Tokenanzeige, die man dadurch auch direkt über das Guthaben erreicht.
Abgebildet sind die Sitemap und der Kern User Flow des Rezept Generierens, jeweils vorher/nachher.
Filter als durchgehendes System statt verstecktes Menü
Filter habe ich neu gedacht und in zwei Ebenen getrennt:
Global — dauerhaft wirkende Filter gehören zum persönlichen Profil und sitzen in den Einstellungen
Situativ — pro Rezept optional zusätzlich zum oder anstelle des Prompts
Entscheidend ist, dass die Filter als Tag am Rezept haften und so einen durchgehenden Wiedererkennungswert schaffen. Von der Einstellung über sichtbare Merkmals-Tags auf der Rezeptkarte bis zur Suche in gespeicherten Rezepten nach Tags. Im Entdecken-Bereich entstehen aus diesen Tag-Themen zufällige Schnellstart-Vorschläge.
DESIGN
Wireframing
Auf Basis der neuen Struktur entwickelte ich baustein-basierte Wireframes. Die wichtigste Entscheidung fiel dabei am Generieren-Screen: Filter und Prompt-Eingabe lagen im MVP auf zwei getrennten Screens, beim Wechsel ins Chat-Fenster waren die gewählten Filter nicht mehr sichtbar — obwohl sie beeinflussten, welches Rezept generiert wird. Jetzt liegen beide auf einem Screen. Man sieht auf einen Blick, was man eingeben kann und welche Filter aktiv sind.
Vorher/Nachher der drei zentralen Flows:
Top Design Entscheidungen
01 Direkter Einstieg ins Generieren
02 Ein Ort pro Aufgabe
→ aus dem UX Audit: Rezepte über 2 Tabs verstreut, Rezeptkarte nur nach manuellem Speichern
03 Filter als durchgehendes System
→ UX Audit: verschachtelt in den Einstellungen, Allergien mit Diäten vermischt
→ Umfrage: 43 % mit spezifischen Ernährungsbedürfnissen (bisher nicht berücksichtigt)
04 Generierte Einkaufslisten
Neue Funktion: generierte Einkauslisten
Aus jedem Rezept lässt sich eine Einkaufsliste generieren, mehrere lassen sich bündeln. Die Idee der Funktion entstand direkt aus der Umfrage und dem Potenzial einer späteren Lieferdienst Anbindung. Die Einkaufsliste als Hilfsmittel ist also etabliert, die Planungsarbeit dahinter findet aber kaum statt, genau die nimmt die Generierung ab.
Ein visueller Charakter zwischen KI, Chat und gesundem Essen
Der visuelle Charakter sollte drei Dinge verbinden: technologische Intelligenz, die Chat-Interaktionsweise und gesundes Essen.
Frische, ernährungsbezogene Farben bilden dafür die Basis.
(Blatt-)Grün — Primärfarbe für Interaktionen
(Karotten-)Orange — Token und besondere Hinweise
Tieforange — Fehlermeldungen und Löschen-States
(Keramik-)Weiß — Weißraum
(Kohl-)Schwarz — Text
Die Farblogik setzt sich im Filter-Tag-System fort: jedes Tag trägt sein Emoji, Unverträglichkeiten sind orange hinterlegt, um als kritische Marker hervorzutreten, Diäten sind grün.
Typografie, Ikonografie und Layout folgen vertrauten Chat- und Messenger-Mustern, so bleibt die Interaktion mit KI auch für Nutzer*innen zugänglich, die noch weniger Erfahrung mit KI-Tools haben.
Farbsystem im Einsatz: Primärgrün für Aktionen, Orange für Token und Unverträglichkeiten.
Dazu entstand ein neues Markenlogo, das die Farblogik aufgreift und zugleich als Ladeanimation funktioniert.
Design System als Single Point of Truth
Parallel zum UI entstand ein komponentenbasiertes Design System. Ziel war eine nicht-destruktive Gestaltungsgrundlage. Änderungen an einer Variable oder Komponente wirken global, ohne manuellen Pflegeaufwand und ohne bestehende Screens zu zerstören.
Alle Farb- und Größenwerte sind tokenisiert. Semantische und komponentenbezogene Token entstanden gemeinsam mit den Entwicklern und liegen in Figmas Variablenbibliothek, dazu eine Dokumentation als Leitfaden für Aufbau und korrekte Verwendung.
Der Effekt zeigte sich zweifach, Screendesigns ließen sich bei Abstimmungen und Iterationen über Komponenten und Token anpassen statt manuell. Und die Übergabe an die Entwicklung lief reibungsloser, weil die Benennung der Komponenten nahezu 1:1 übernommen werden konnte.
TESTING
Test: funktioniert die neue Struktur in der Praxis?
Die neue UI ging in die Entwicklung, daraus entstand ein TestFlight-Funktionsprototyp. Damit habe ich einen moderierten, formativen Usability-Test mit 8 Aufgabenszenarien entlang der zentralen Interaktionsflows durchgeführt.
6 Teilnehmende — spontan angesprochen in der Münchner Innenstadt, auf ihrem Heimweg
8 Aufgaben — Soll-Pfade vorab definiert, Bewertung auf vierstufiger Skala
Formativ, nicht komparativ — der MVP war nie systematisch getestet worden, ein Vorher/Nachher-Vergleich war deshalb nicht möglich
Die neue Struktur hielt stand, die Probleme lagen auf visueller Ebene
Navigation sowie Rezept- und Einkaufslisten-Verwaltung funktionierten in ihrer Grundstruktur und wurden gefunden. Die Probleme lagen fast ausschließlich bei einzelnen Elementen, nicht in der Informationsarchitektur. Unter anderem falsch platzierte oder nicht eindeutig als interaktiv erkennbare Elemente.
Iterationen
Aufgabe 2 - Prompt eingeben
P2 startete im „Entdecken"-Tab,
P3 und P5 übersahen die Prompt-Eingabe wegen der aufgeklappten Filter-Dropdowns.
(3 von 6 fehlerfrei)
Die Prompt-Eingabe wurde als schwebendes, fixiertes Element über der Tabbar platziert. "Generieren" rückte in der Tabbar von Platz 3 auf Platz 2 und sitzt damit logischer im Flow.
(Siehe vorher / nachher Visualisierung)
Aufgabe 5 - Token-Guthaben aufladen
Fast niemand erkannte die Tokenanzeige im Header als interaktives Element, 5 von 6 nahmen den Umweg über die Einstellungen.
(1 von 6 fehlerfrei)
Ein Plus-Icon in der Tokenanzeige zeigt jetzt klar, dass sich Token hinzufügen lassen.
(Siehe vorher / nachher Visualisierung)
Aufgabe 7 - Einkaufsliste generieren
Der Button war zu unscheinbar, P3 und P6 durchsuchten Tabs und Header, bevor sie ihn fanden.
(3 von 6 fehlerfrei)
Neben den Test-Iterationen habe ich Token-Transparenz, Textkontraste und die Filterlogik nachgeschärft. Weitere Findings mit mittlerer bis niedriger Priorität wurden bewusst zurückgestellt, Priorität hatte zunächst ein funktionsfähiges Release.
Reflexionen & offene Fragen
Über den Auftrag hinauszudenken hat sich gelohnt
Beauftragt war ich für das Visual Design, die nicht ganz runde UX wurde im Nebensatz erwähnt, offenbar verbunden mit der Hoffnung auf eine schnelle Lösung. Der UX Audit zeigte dann strukturelle Probleme und dass der MVP nie mit Außenstehenden getestet worden war. Eigeninitiativ Problemen auf den Grund zu gehen war herausfordernd, hat aber gegenseitiges Vertrauen geschaffen.
Wenn man denkt, es ist zu früh zum Testen, ist es meistens noch nicht früh genug
Rückblickend hätte ich den MVP gern schon eingangs im Usability-Test geprüft, um echte Vergleichswerte statt Annahmen zu haben. Argumentiert hatte ich das früh, überzeugen konnte ich erst mit Ergebnissen aus Audit und Umfrage. Bei Festpreisangeboten lässt sich ein initialer Test fest einplanen, auf Stundenbasis entscheidet am Ende der Auftraggeber, wofür seine Stunden verwendet werden.
Offene Fragen
Erzeugt ein dauerhaft sichtbarer Tokenstatus subjektiven Druck und stellt damit Gewinnabsicht gegen Nutzerziele? Wie zuverlässig schätzt die KI Nährwerte und schlägt Ersatzzutaten bei Unverträglichkeiten vor? Und löst generative KI die Rezept-Ermüdung datenbankbasierter Apps wirklich, oder stellt sich nach einiger Zeit auch dort ein Wiederholungsmuster ein?