LUC

IEN HAASE

LUC

EN

|

DE

EN

|

DE

Index

Über

Problem

Lösung

Recherche

Define

Design

Ergebnis

Reflexion

Foodai — UX/UI-Redesign einer KI-gestützten Ernährungs-App

Was soll ich heute kochen? Eine Frage, die oft mehr Energie kostet als das Kochen selbst.

Unternehmen | Product

InfinityAppCraft | Foodai

Amacoa GmbH
(Full-Service E-Commerce Agency)

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. Von Research via heuristischem UX-Audit des MVP und einer Online-Umfrage zu Verhaltensmustern rund ums Kochen und Einkaufen über die Optimierung der Informations-architektur und aller Flows (von denen in dieser Case Study im wesentlichen 3 gezeigt werden) bis zur sukzessiven Entwicklung der neuen UI inklusive Design System.

Struktureller Impact im Überblick

Rezeptverwaltung von 2 Tabs auf 1 Flow

Generierte Rezepte lagen als unstrukturierte Chatverläufe unter "Chat" und wanderten erst nach manuellem Speichern zur Übersichtskarte unter "Rezepte". Jetzt entsteht die strukturierte Rezeptkarte automatisch, an einem Ort.

Teilnehmende, spontan rekrutiert in der Münchner Innenstadt
(Guerilla Test, formativ)


Kernaktion aus dem Untermenü in die Hauptnavigation

Der Einstieg ins Rezept-Generieren lag hinter einem missverständlichen "Chat"-Tab und einem "Neuer Chat"-Button. Jetzt heißt der Tab "Generieren" und öffnet direkt das Generieren Interface mit Wunscheingabe und Filtern auf einen Blick.

Teilnehmende, spontan rekrutiert in der Münchner Innenstadt
(Guerilla Test, formativ)


Verstreute knappe Filter zu neuer
2-Ebenen Filter-& Tag-Systematik

Vorher über mehrere Menüs verteilt (Kategorien wie Allergien und Diäten vermischt). Jetzt global im Profil vs. situativ pro Rezept Generierung. Der Filter wird zum Eigenschafts-Tag, der sich über Einstellungen, Rezeptkarte bis Entdecken-Bereich durchzieht und nach dem sich gespeicherte Rezepte filtern lassen.

Teilnehmende, spontan rekrutiert in der Münchner Innenstadt
(Guerilla Test, formativ)


Neues Visual Design und Design System

Aus dem iOS Native MVP entstand ein neues Visual Design und tokenbasiertes Design System inklusive Dokumentation zur direkten Übergabe an die Entwicklung.

Teilnehmende, spontan rekrutiert in der Münchner Innenstadt
(Guerilla Test, formativ)


Wirkungsdaten aus der realen Nutzung liegen nicht vor. Weitere Testrunden waren geplant, entfielen aber durch eine Projektpause und ausstehendem Release auf Auftraggeberseite.

Warum ich mit dem Neudesign des MVP beauftragt wurde?

Ausgangslage

Die foodai App generiert KI-basiert personalisierte Rezepte. Grundarchitektur des MVP stand, allerdings im iOS Native Look, gesucht war ein branded UI mit eigener visueller Identität.

Schon in den ersten Gesprächen zeigte sich, dass neben Look & Feel auch strukturelle Arbeit an Informationsarchitektur und Flows nötig ist.

Die zentralen Usability Probleme

  • Unklare Navigation:
    Der Menü-Tab "Chat" war missverständlich benannt und führte nicht direkt zur Rezeptgenerierung, sondern auf eine Zwischenansicht mit "Neuer Chat"-Button.

  • Rezepte auf 2 Tabs verstreut:
    Generierte Rezepte lagen als unstrukturierte Chatverläufe unter "Chat", die übersichtlichen Rezeptkarten unter "Rezepte", letztere nur nach aktivem Speichern.

  • Verschachtelte Filter:
    Über mehrere Menüs verteilt und damit unübersichtlich, zugleich inhaltlich zu knapp für ein wirklich personalisiertes Erlebnis.

Vorher / Nachher der Kernprobleme

Schaffung einer eigenen Identität und klareren Struktur

Der MVP kam im iOS Native Look ohne eigenen visuellen Charakter. Die Navigation war unklar, der Einstieg in die Rezeptgenerierung versteckt, die Rezeptspeicherung verstreut und die Filteroptionen zu knapp.

Ziel war ein flüssigeres, übersichtliches Erlebnis, das Planungsarbeit im Alltag abnimmt und schnell zu Ergebnissen führt. Umgesetzt über einen direkteren Einstieg in die Rezeptgenerierung, eine Rezeptverwaltung an einem Ort, personalisiertere Filter und generierte Einkaufslisten als neue Funktion. Dazu eine neue visuelle Identität und ein Design System, das Konsistenz sichert und saubere Weiterentwicklung ermöglicht.

Wie ich die Probleme angegangen bin. (Lösungsweg)

Als alleiniger Designer im Team konnte ich die Grundlagen des Designprozesses schaffen. Die Ressourcen waren begrenzt, also startete ich mit niedrigschwelligen Analysemethoden.


Eigene Annahmen zu hinterfragen bleibt entscheidend, deshalb gehört User Research so früh wie möglich dazu, auch mit wenig Mitteln.
Nur so basieren Produktentscheidungen auf Daten von Menschen, die das Produkt nutzen würden, idealerweise aus Interviews oder Tests mit echten Nutzer*innen.

Genau das fehlte bisher. Vor meinem Einstieg war der MVP nicht systematisch mit echten Nutzer*innen getestet worden. Geprüft hatten ihn vor allem Teammitglieder, die die App selbst mitentwickelt hatten, dazu einzelne Personen aus dem Umfeld, ohne strukturiertes Vorgehen. Inhaber und Team berichteten, dass Personen im Test vor allem bei der grundsätzlichen Navigation und der Rezeptverwaltung hängen blieben, durch Beobachtung aber nicht messbar belegt.

Ich behandelte diese Hinweise als Hypothesen und glich sie mit einem UX Audit der bestehenden Flows ab. Beauftragt war ich initial für das Visual Redesign. Die dabei sichtbaren strukturellen Probleme dokumentierte ich und leitete daraus zusammen mit den übrigen Research Ergebnissen die Überarbeitung der Informationsarchitektur ab.

Als alleiniger Designer im Team konnte ich die Grundlagen des Designprozesses schaffen. Die Ressourcen waren begrenzt, also startete ich mit niedrigschwelligen Analysemethoden.


Eigene Annahmen zu hinterfragen bleibt entscheidend, deshalb gehört User Research so früh wie möglich dazu, auch mit wenig Mitteln.
Nur so basieren Produktentscheidungen auf Daten von Menschen, die das Produkt nutzen würden, idealerweise aus Interviews oder Tests mit echten Nutzer*innen.

Genau das fehlte bisher. Vor meinem Einstieg war der MVP nicht systematisch mit echten Nutzer*innen getestet worden. Geprüft hatten ihn vor allem Teammitglieder, die die App selbst mitentwickelt hatten, dazu einzelne Personen aus dem Umfeld, ohne strukturiertes Vorgehen. Inhaber und Team berichteten, dass Personen im Test vor allem bei der grundsätzlichen Navigation und der Rezeptverwaltung hängen blieben, durch Beobachtung aber nicht messbar belegt.

Ich behandelte diese Hinweise als Hypothesen und glich sie mit einem UX Audit der bestehenden Flows ab. Beauftragt war ich initial für das Visual Redesign. Die dabei sichtbaren strukturellen Probleme dokumentierte ich und leitete daraus zusammen mit den übrigen Research Ergebnissen die Überarbeitung der Informationsarchitektur ab.

Als alleiniger Designer im Team konnte ich die Grundlagen des Designprozesses schaffen. Die Ressourcen waren begrenzt, also startete ich mit niedrigschwelligen Analysemethoden.


Eigene Annahmen zu hinterfragen bleibt entscheidend, deshalb gehört User Research so früh wie möglich dazu, auch mit wenig Mitteln.
Nur so basieren Produktentscheidungen auf Daten von Menschen, die das Produkt nutzen würden, idealerweise aus Interviews oder Tests mit echten Nutzer*innen.

Genau das fehlte bisher. Vor meinem Einstieg war der MVP nicht systematisch mit echten Nutzer*innen getestet worden. Geprüft hatten ihn vor allem Teammitglieder, die die App selbst mitentwickelt hatten, dazu einzelne Personen aus dem Umfeld, ohne strukturiertes Vorgehen. Inhaber und Team berichteten, dass Personen im Test vor allem bei der grundsätzlichen Navigation und der Rezeptverwaltung hängen blieben, durch Beobachtung aber nicht messbar belegt.

Ich behandelte diese Hinweise als Hypothesen und glich sie mit einem UX Audit der bestehenden Flows ab. Beauftragt war ich initial für das Visual Redesign. Die dabei sichtbaren strukturellen Probleme dokumentierte ich und leitete daraus zusammen mit den übrigen Research Ergebnissen die Überarbeitung der Informationsarchitektur ab.

1. Schritt: Konkurrenzanalyse

Zuerst wollte ich verstehen, welchen funktionellen Wert foodai gegenüber anderen Rezeptplanern am Markt hat. Eine Online-Befragung sollte zeigen, wie der Alltag rund ums Planen, Einkaufen und Kochen aussieht.


Dafür stellte ich foodai etablierten Apps zur Ernährungsplanung gegenüber, die in Funktion, User Experience und Visual Design nahe an dem liegen, was wir für foodai anvisieren.
Ich untersuchte Funktionen, Positionierung und häufige Bewertungen und leitete daraus Design Implikationen für die Weiterentwicklung von foodai ab.

Zuerst wollte ich verstehen, welchen funktionellen Wert foodai gegenüber anderen Rezeptplanern am Markt hat. Eine Online-Befragung sollte zeigen, wie der Alltag rund ums Planen, Einkaufen und Kochen aussieht.


Dafür stellte ich foodai etablierten Apps zur Ernährungsplanung gegenüber, die in Funktion, User Experience und Visual Design nahe an dem liegen, was wir für foodai anvisieren.
Ich untersuchte Funktionen, Positionierung und häufige Bewertungen und leitete daraus Design Implikationen für die Weiterentwicklung von foodai ab.

Zuerst wollte ich verstehen, welchen funktionellen Wert foodai gegenüber anderen Rezeptplanern am Markt hat. Eine Online-Befragung sollte zeigen, wie der Alltag rund ums Planen, Einkaufen und Kochen aussieht.


Dafür stellte ich foodai etablierten Apps zur Ernährungsplanung gegenüber, die in Funktion, User Experience und Visual Design nahe an dem liegen, was wir für foodai anvisieren.
Ich untersuchte Funktionen, Positionierung und häufige Bewertungen und leitete daraus Design Implikationen für die Weiterentwicklung von foodai ab.

Konkurrenzanalyse

2. Schritt: nicht repräsentative Online-Umfrage zu Planungs- & Kochgewohnheiten

Die Umfrage kombinierte quantitative und qualitative Fragen. So konnten wir explorativ erkunden, wie Verhalten, Frustrationen, Routinen, Reibungspunkte und Wahrnehmung rund ums Planen und Kochen aussehen.

Zum Beispiel:

  • Stimmt die Annahme, dass wir vor allem Erwachsene und junge Erwachsene zwischen 20-40 erreichen werden, die ins eigenständige Leben starten oder mittendrin sind und gerade gesunde Ernährungsroutinen etablieren?

  • Welche Herausforderungen bringt der Alltag als Studierende oder Berufstätige beim Planen und Kochen mit sich?

  • Wo liegen die häufigsten Reibungspunkte bei bestehenden digitalen Tools zur Ernährungsplanung?


Die Antworten habe ich quantitativ in Diagrammen visualiert und qualitativ per Affinity Mapping in thematische Gruppen sortiert. Daraus leitete ich Hypothesen für die Weiterentwicklung ab.

Die Umfrage kombinierte quantitative und qualitative Fragen. So konnten wir explorativ erkunden, wie Verhalten, Frustrationen, Routinen, Reibungspunkte und Wahrnehmung rund ums Planen und Kochen aussehen.

Zum Beispiel:

  • Stimmt die Annahme, dass wir vor allem Erwachsene und junge Erwachsene zwischen 20-40 erreichen werden, die ins eigenständige Leben starten oder mittendrin sind und gerade gesunde Ernährungsroutinen etablieren?

  • Welche Herausforderungen bringt der Alltag als Studierende oder Berufstätige beim Planen und Kochen mit sich?

  • Wo liegen die häufigsten Reibungspunkte bei bestehenden digitalen Tools zur Ernährungsplanung?


Die Antworten habe ich quantitativ in Diagrammen visualiert und qualitativ per Affinity Mapping in thematische Gruppen sortiert. Daraus leitete ich Hypothesen für die Weiterentwicklung ab.

Die Umfrage kombinierte quantitative und qualitative Fragen. So konnten wir explorativ erkunden, wie Verhalten, Frustrationen, Routinen, Reibungspunkte und Wahrnehmung rund ums Planen und Kochen aussehen.

Zum Beispiel:

  • Stimmt die Annahme, dass wir vor allem Erwachsene und junge Erwachsene zwischen 20-40 erreichen werden, die ins eigenständige Leben starten oder mittendrin sind und gerade gesunde Ernährungsroutinen etablieren?

  • Welche Herausforderungen bringt der Alltag als Studierende oder Berufstätige beim Planen und Kochen mit sich?

  • Wo liegen die häufigsten Reibungspunkte bei bestehenden digitalen Tools zur Ernährungsplanung?


Die Antworten habe ich quantitativ in Diagrammen visualiert und qualitativ per Affinity Mapping in thematische Gruppen sortiert. Daraus leitete ich Hypothesen für die Weiterentwicklung ab.

Umfrage Auswertung

Konkurrenzanalyse und Umfrage zeigten unter anderem, dass knappe Zeit, fehlende Inspiration, Zutatenverfügbarkeit und unterschiedliche Ernährungsbedürfnisse die Alltagsplanung prägen. Bei mehr als der Hälfte der Befragten verläuft sie schwierig oder spontan .

Deshalb rückten die konkreten Handlungsebenen in den Fokus, also Einkaufen, Kochen und individuelle Bedürfnisse. Klarer strukturierte Funktionen, stärker personalisierte Filteroptionen und die neue Funktion generierter Einkaufslisten nehmen nach dem initialem Setup möglichst viel manuelle Planungs- und Denkarbeit ab.
Idealerweise kommt man so schnell und ortsunabhängig in wenigen Schritten zur Rezeptidee inklusive Einkaufsliste, ohne lange Planung und Suche.

3. Schritt: heuristischer UX Audit, Analyse auf Basis von Jacob Nielsens Heuristken

Den bestehenden MVP habe ich per heuristischer UX Analyse durchgearbeitet und dabei alle auffälligen Reibungspunkte, Unklarheiten und möglichen UX-Probleme systematisch geprüft.
(ausgewählte Screens - siehe unten)

In Figma sehen

In Figma sehen

Die vollständige vorher / nachher Präsentation des UX Audit kann in Figma geöffnet werden.

Wie die Recherche Erkenntnisse priorisiert und in die neue Struktur eingegliedert wurden.

Die Recherche zeigte, dass der MVP eher technisch als von Nutzer*innen her gedacht war. Ich zog die wesentlichen Erkenntnisse aus den gesammelt Daten, stellte sie dem Team vor stimmten gemeinsam das weitere Vorgehen ab.

Der UX Audit hatte gezeigt, dass der Einstieg in die Rezeptgenerierung unklar benannt und versteckt war, sich die Rezeptverwaltung über mehrere Screens verteilte und die Filtersystematik unausgereift war. Weil diese strukturellen Probleme allen weiteren Entscheidungen zugrunde lagen, war hier der Ausgangspunkt.

Top Research Findings

Konkurrenzanalyse

Immer gleiche Rezepte ist ein großer Kritikpunkt

Kuratierte Rezept-Kataloge erschöpfen sich nach Wochen, Nutzer*innen sehen immer dieselben Gerichte.





Kuratierte Rezept-Kataloge erschöpfen sich nach Wochen, Nutzer*innen sehen immer dieselben Gerichte.

Konkurrenzanalyse

Werbung, Upselling, Scores als störend empfunden

Werbung wird wiederkehrend kritisiert, ebenso Upselling Zwang, bevor überhaupt Mehrwert entsteht.





Werbung wird wiederkehrend kritisiert, ebenso Upselling Zwang, bevor überhaupt Mehrwert entsteht.

UX Audit

Unklare Navigation & verstreute Filter

Menü-Tabs sind unklar benannt, der Einstieg in die Rezept-generierung versteckt.
Filter verteilen sich über mehrere Screens, man muss sich merken, was wo gesetzt ist. (Allergien und Diäten vermischt).


UX Audit

Rezepte unstrukturiert, Tokens intransparent

Generierte Rezepte erscheinen als ungeordnete Chats und müssen manuell gespeichert werden, um zu Übersichtskarten zu werden.
Die Tokenanzeige ist nicht durchgängig sichtbar, der Verbrauch bleibt intransparent.

Umfrage

Spontan statt geplant

Niemand plant konsequent voraus. Ca. 64% der Befragten kochen nach vorhanden Zutaten, 40 von 47 nennen Verfügbarkeit als Kriterium bei der Rezeptwahl.





Niemand plant konsequent voraus. Ca. 64% der Befragten kochen nach vorhanden Zutaten, 40 von 47 nennen Verfügbarkeit als Kriterium bei der Rezeptwahl.

Umfrage

Spezifische Ernährungs-bedürfnisse

Ca. 43% der Befragten haben spezifische Bedürfnisse (Laktose, Gluten, Histamin u.a.). Von 39 Befragten mit spezifischen Ernährungs-bedürfnissen, wissen 30 oft nicht, wie sie Zutaten ersetzen können.

Ca. 43% der Befragten haben spezifische Bedürfnisse (Laktose, Gluten, Histamin u.a.), doch 38 von 47 wissen oft nicht, wie sie Zutaten ersetzen können.





Die Restrukturierung der Informationsarchitektur

Für einen besseren Überblick über Flows, Abhängigkeiten und Navigationslogik habe ich die Informationsarchitektur des MVP als Sitemap und als vereinfachtes User Flowchart visualisiert.
Abgebildet sind die Kernaktionsflows aus Tabbar und Header sowie Token Verwaltung und Profil Filter Verwaltung. Einzelne Nebenflows wie Rating, Hilfe oder der detaillierte Zahlungsflow blieben außen vor.

Das erleichterte die Neustrukturierung enorm, weil sich Flow Kacheln und Verbindungen ohne großen Gestaltungsaufwand verschieben ließen, bis ein schlüssiges Bild entstand.


Ziel war ein direkterer Einstieg in die Rezeptgenerierung, die dadurch in den Mittelpunkt rückt. Die zuvor über zwei Tabs verstreute Rezeptverwaltung wird zu einem zusammenhängenden Flow. Die Token Verwaltung erreicht man neben den Einstellungen auch direkt über die Token Anzeige, deren Einstellungen in den Header wandern. Dazu kommen eine optimierte Filterstruktur und die neue Einkaufslisten Generierung.

Die Navigationslogik ist so aufgeteilt, dass jeder Kernflow seinen eigenen Platz in der unteren Navigationsleiste (Tabbar) hat. Die Profileinstellungen wurden in Einstellungen umbenannt und sitzen dagegen näher an der Tokenanzeige und sind zusammen mit sonstigen Interaktionen über den Header zugänglich.

Es besteht also eine klare Trennung zwischen "Entdecken" für Inspiration und Vorschläge, „Generieren" als zentraler Aktion, „Rezepte" als Speicherort und „Einkaufen" als neuer Einkaufslisten-Funktion, die den ehemaligen Platz der Einstellungen in der Tabbar einnimmt.

Auch die Filtersystematik habe ich neu gedacht und in zwei Ebenen getrennt.

  • Global dauerhaft wirkende Filter gehören zum persönlichen Profil und sitzen im Einstellungsmenü.

  • Situative Filter lassen sich je Rezept optional zusätzlich zum oder anstelle des Prompts setzen.

Die Filter haften als "Tag" Marker jedem Rezept an und schaffen so einen durchgehenden Wiedererkennungswert.

Von der Einstellung der Profil- oder Rezept-Filter-Tags über sichtbare Filter-Merkmal-Tags an der Rezeptkarte bis zur Suche in gespeicherten Rezepten nach Tags.

Im Entdecken Bereich generiert man aus den Kategorien zufällige Schnellstart Rezeptvorschläge auf Basis dieser Tag-Themen. Filter nehmen so strukturell einen deutlich wesentlicheren Stellenwert ein als zuvor.

Der Perspektivwechsel, der uns zur neuen (Produkt-)Vision geführt hat.

Der Perspektivwechsel, der uns zur neuen (Produkt-)Vision geführt hat.

Der Perspektivwechsel, der uns zur neuen (Produkt-)Vision geführt hat.

  1. Wireframing: Mit der neuen foodai Struktur kamen neue Ideen für die Interaktionen

Jetzt wurde es konkreter. Um die neue Informationsarchitektur, die Erkenntnisse aus der Recherche und unsere Ideen greifbar zusammenzubringen, entwickelte ich rudimentäre Baustein basierte Wireframes. So konnte es in die Platzierung und Visualisierung der Ideen gehen.

In Figma sehen

In Figma sehen

Die vollständige vorher / nachher Präsentation des Wireframings kann in Figma geöffnet werden.

Top Design Entscheidungen

01 Ein Ort pro Aufgabe

Die Tabbar hebt die zentrale Aktion „Generieren" klar hervor. Generierte Rezepte werden automatisch als strukturierte Karte unter „Rezepte" gespeichert. Jede Kernfunktion hat so ihren eindeutigen Ort.

02 Direkter Einstieg ins Generieren

Der Einstieg erfolgt sofort über den Generieren-Tab, statt hinter einem „Neuer Chat"-Button im Tab versteckt. Filter und Prompt liegen dort auf einen Blick sichtbar im Screen.

Der Einstieg erfolgt sofort über den Generieren-Tab, statt hinter einem „Neuer Chat"-Button versteckt. Filter und Prompt liegen dort auf einen Blick auf einem Screen.

03 Filter als durchgängiges System

Globale Profilfilter und situative Rezeptfilter werden getrennt verwaltet, greifen bei der Suche aber als ein kombinierter Filter. Die Profilfilter gelten für alle Generierungen, die Rezeptfilter werden je Generierung neu gesetzt. Ein Teil der Profilfilter erscheint vorausgewählt auch in den Rezeptfiltern und lässt sich situativ anpassen, ohne die globale Auswahl zu verändern.

04 Generierte Einkaufslisten

Aus jedem Rezept lässt sich auf Wunsch eine Einkaufsliste generieren, mehrere davon zu einer einzigen bündeln. So fällt manuelle Planungsarbeit weg.





Aus jedem Rezept lässt sich auf Wunsch eine Einkaufsliste generieren, mehrere davon zu einer einzigen bündeln. So fällt manuelle Planungsarbeit weg.

  1. Visual Design: Wie den Wireframes Leben eingehaucht wurde.

Als Screen-Strukturen und Interaktionsdesign als Wireframes standen, folgte der visuelle Charakter. Er sollte technologische Intelligenz (KI), Chat-Interface (Interaktionsweise) und gesundes Essen verbinden.


Frische, ernährungsbezogene Farben bilden ein klares, modernes UI. (Blatt-)Grün ist Primärfarbe für Interaktionen, (Karotten-)Orange markiert Token und besondere Hinweise, Tieforange steht für Fehlermeldungen und Löschen-States, (Keramik-)Weiß schafft Weißraum, (Kohl-)Schwarz trägt die Texte.


Jedes Filter-Tag trägt das ihm zugeordnete Emoji, Tags für Unverträglichkeiten sind orange hinterlegt, um als kritische Marker deutlicher hervorzutreten, die für Diäten grün. Auf den generierten Rezept-Karten zeigen sie die Eigenschaften eines Rezepts auf einen Blick.


Typografie, Ikonografie, Formsprache und Layout folgen vertrauten Chat- und Messenger-Mustern, ergänzt durch Emojis. So bleibt die Interaktion mit KI auch für Nutzer*innen zugänglich und intuitiv, die wenig Erfahrung mit KI-Tools haben.

Filter Tag Systematik (Screens: Einstellungen, Profil Filter, Entdecken Tab, Zufalls Rezept, Generieren Nachrichtenverlauf, Generiertes Rezept, generierte Einkaufsliste)

Dazu habe ich ein neues Markenlogo für foodai entwickelt, das die Farblogik aufgreift und zugleich als Ladeanimation funktioniert.

  1. Design System als Single Point of Truth

Parallel zum UI- und Visual Design entstand ein komponentenbasiertes Design System. Ziel war eine konsistente, nicht-destruktive Gestaltungsgrundlage. Änderungen an einer Variable oder Komponente wirken global, ohne manuellen Pflegeaufwand und ohne bestehende Screens zu zerstören.

Dafür habe ich alle nötigen Farb- und Größenwerte tokenisiert. Semantische und komponentenbezogene Token entstanden gemeinsam mit den Entwicklern und liegen in Figmas Variablenbibliothek. Dazu kam eine Dokumentation als Leitfaden und Referenz für Aufbau und korrekte Verwendung der Elemente. Sie sichert langfristig ein konsistentes Look & Feel.

Das steigerte die Effizienz schon im Gestaltungsprozess spürbar, weil sich Screendesigns bei Abstimmungen, Testing und Iterationen leichter über Komponenten und Variablen/Token anpassen ließen. Auch die Übergabe an die Entwicklung lief reibungsloser, da die Benennung der Komponenten nahezu 1:1 übernommen werden konnte.

Konnte die neue Produktvision dem Test standhalten?

  1. Jetzt waren alle Grundlagen gelegt um einen neuen Test-Prototypen zu entwickeln.

Die neue UI ging direkt in die Entwicklung. Aus ihr entstand ein TestFlight Funktionsprototyp, um die User Experience erlebbar zu machen und zu prüfen, ob alle Flows wie geplant funktionieren.
(Übergabe des UX/UI Designs an Entwickler, siehe unten)

Design-to-Dev Handover

  1. Guerilla Testing (Formativ)

Für die Redesign Version habe ich einen moderierten, formativen Usability-Test mit 8 Aufgabenszenarien entlang der zentralen App Interaktionsflows entwickelt. Die Soll-Pfade habe ich vorab definiert, um Abweichungen sauber gegen die Zielerwartungen abzugleichen.

Jeder Durchlauf wurde auf einer vierstufigen Skala bewertet:

  • Kompletter Erfolg

  • Erfolg mit kleinem Fehler (Ziel erreicht, aber Umweg / Zögern / falsches Tippen)

  • Erfolg mit großem Fehler (Ziel erreicht, aber Abweichung vom Ziel Weg / Zurückspringen)

  • Kein Erfolg (Falsches Ziel erreicht / Abbruch)


Zusätzlich habe ich Handlungen und spontanen Äußerungen aufgezeichnet, um nicht nur zu erfassen ob, sondern auch wie Teilnehmende ans Ziel kamen.
Den Testplan habe ich vorab selbst und mit einer weiteren Person aus dem Team durchgespielt und auf Verständlichkeit geprüft.

Da der MVP nicht systematisch getestet, war ein Vorher/Nachher Vergleich nicht möglich. Der Test evaluierte deshalb formativ statt komparativ, ob die neu strukturierten Flows in der Praxis funktionieren und wo nicht.

Durchführung

Getestet habe ich in der Münchner Innenstadt mit 6 spontan angesprochenen Passant*innen auf ihrem Heimweg, also genau in der Situation, in der man foodai für die Rezeptsuche nutzen würde. Die Zielgruppenzugehörigkeit (20-40 Jahre, kocht im Alltag) habe ich per Nachfrage erhoben.

Usability Test Ergebnisse

Grenzen des Tests

Kocherfahrung und Vorerfahrung mit KI-Tools wurden nicht erhoben und sollte in der nächsten Testrunde berücksichtigt werden. Ein zeitliches Limit bei den Aufgaben würde zudem die die Vergleichbarkeit von Tests helfen.

Durch die feste Aufgabenreihenfolge enthalten spätere Aufgaben Lerneffekte, etwa war das Filter-Tag System aus Aufgabe 2 in Aufgabe 3 bereits bekannt. Die Aufgaben sind deshalb keine voneinander unabhängigen Messungen.

Mit 6 Teilnehmenden lassen sich häufige Probleme identifizieren. Weitere Tests sind jedoch nötig, um zu prüfen, ob die eingangs benannten Kern Usability-Probleme behoben wurden, um seltenere Probleme zu finden und um Iterationen zu vergelichen.

  1. Iterationen: Was beim Test heraus kam und optimiert werden musste.

Iterationen in direkter Ableitung aus Testergebnissen

Aufgabe 2 - Rezept "Generieren-Tab" öffnen & Prompt eingeben

P2 startete die Generierung erst im „Entdecken"-Tab über einen Prompt-Vorschlag, kommentierte die fehlende Auswahlmöglichkeit und wechselte dann zu "Generieren".
P3 und P5 übersahen die Prompt Eingabe wegen der aufge-klappten Filter-Dropdowns. P3 fand sie durch Scrollen, P5 tippte zunächst auf den "Generieren" Tab, was zum Reset führte und sah das Prompt-Feld dann.


(6 von 6 erreichen das Ziel, 3 von 6 fehlerfrei, 1 mit kleinem Fehler, 2 mit großen Fehler.)

Iteration

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)








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 - Aufladen des Token-Guthabens

Fast niemand erkannte die Tokenanzeige im Header als interaktives Element. 5 von 6 Personen nahmen den Umweg über die Einstellungen.


(6 von 6 erreichen das Ziel, 1 von 6 fehlerfrei, 5 von 6 mit großen Fehler )

Iteration

Ein Button mit Plus Icon in der Tokenanzeige zeigt jetzt klar, dass hier neue Token hinzugefügt werden können.


(Siehe vorher / nachher Visualisierung)

Aufgabe 7 - Einkaufsliste aus Rezept generieren

Der Button zur Generierung der Einkaufsliste war zu unscheinbar und wurde vielfach übersehen.
P3 suchte im "Einkaufen" Tab, P5 durchsuchte die Rezeptkarte-Tabs "Zutaten" und "Schritte" und fand ihn schließlich im Header. P6 sprang durch alle Tabs der Tabbar bis sie ihn fand.


(6 von 6 erreichen das Ziel, 3 von 6 fehlerfrei, 1 mit kleinem Fehler, 2 mit großen Fehler)

Iteration

Der Button erhielt zusätzlich zum Icon ein Textlabel, wurde in Primärfarbe hervorgehoben und vom Header in die Rezeptkarte verlegt.


(Siehe vorher / nachher Visualisierung)





Der Button erhielt zusätzlich zum Icon ein Textlabel, wurde in Primärfarbe hervorgehoben und vom Header in die Rezeptkarte verlegt.


(Siehe vorher / nachher Visualisierung)

Weitere Optimierungen (nicht aus dem Test abgeleitet)

Token Verbrauch vor der Generierung

Token-verbrauchende Aktionen sind jetzt durch einen Verbrauch-Marker am jeweiligen Aktions-Button eindeutig markiert.


(Siehe vorher / nachher Visualisierung)

Höhere Textkontraste

Die Textkontrastverhältnisse wurden insgesamt erhöht.
Zudem liegt der Fokus auf der Rezeptkarte jetzt gezielt auf den Zahlenwerten von Nährwerten und Zutaten, auf der Einkaufsliste auf den Zutatennamen. Beim Kochen und Sichten des Rezepts zählen vor allem die Mengenangaben, beim Einkaufen die Zutatennamen.

Portionen als Filter entfernt

Portionen wurden als eigenständiger Rezeptfilter entfernt.
Die Einstellung erfolgt, wie ursprünglich im MVP ausschließlich über den Stepper in der Rezeptkarte.
Das spart Ressourcen bei der Rezeptgenerierung, da sich die Menge nach der Generierung errechnen lässt.

Zurückgestellte Optimierungen

Folgende Findings wurden mit mittlerer bis niedriger Priorität bewusst zurückgestellt und sollen auf Basis weiterer Testläufe optimiert werden.

Globale vs. sitautive Filter

Die Unterscheidung sollte im Onboarding erklärt und ggf. anders benannt werden.

Einkaufslisten "Bündeln" Aktion

Platzierung und Erläuterung sind ggf. verbesserungswürdig, Lösung nach weiteren Test zu eruieren.

Gemischte Ernährungsformen

Weitere Tests sollten zeigen, ob detaillierte Kombinationen nötig sind oder ob die Kategorien Omnivor / Vegetarisch / Vegan / Pescetarisch / Flexitarisch / Keto die meisten Fälle abdecken.
Für die Erstnutzung ist ggf. ein Hinweis nötig, welche Lebensmittel jede Form umfasst und welche nicht.

Küchengeräte und Zubereitungsarten

Zudem wurde ist die Idee aufgekommen, Geräte als eigene Filterebene aufzunehmen, um Rezepte für spezifisches Zubehör wie Heißluftfritöse zu erhalten oder Geräte wie den Ofen auszuschließen.

Priorität hat zunächst ein funktionsfähiger Release.
Erst Nutzungsdaten aus dem realen Alltag zeigen, welche dieser Punkte höhere Priorität haben.

Test Fazit

Der Test bestätigt, dass Navigation sowie Rezept- und Einkaufslisten-verwaltung in ihrer Grundstruktur funktionieren und gefunden werden.
Die Probleme lagen fast ausschließlich bei einzelnen Elementen, etwa falsch platzierten oder nicht eindeutig als interaktiv erkennbaren, nicht in der Informationsarchitektur.
Das strukturelle Redesign funktioniert also, nachgeschärft werden sollte auf visueller Ebene.

Relevanteste Optimierungen

Neue Filter-Systematik und Einkaufslisten

Die Filter-Systematik ist neu strukturiert. Dazu kam eine Funktion zur Generierung und Verwaltung von Einkaufslisten.

Neu strukturierte Informationsarchitektur

Ein klarer Flow führt Navigation, Einstieg in die Generierung und die zuvor über zwei Tabs verstreute Rezeptverwaltung zusammen.

Filter-Tags als roter Faden

Die farbigen Tags ziehen sich als Wiedererkennungszeichen durch Auswahlmenüs, Rezeptkarten und Suchfilter, also durch die ganze App.

Eigene visuelle Identität

Aus dem iOS-Native-Prototyp entstand eine eigenständige visuelle Identität, samt Design System als Single Point of Truth.

Reflexionen, Learnings, offene Fragen

  • Das Redesign wurde vollständig umgesetzt und als TestFlight-Build (v2.0) ausgeliefert. Weitere Testrunden waren zwar geplant, konnten vor der Projektpause auf Auftraggeberseite aber nicht mehr stattfinden. Die Auswirkungen der Änderungen sind damit leider nicht vollständig belegt.

  • Ursprünglich war ich nur für das Visual Design beauftragt, die nicht ganz runde UX wurde im Nebensatz erwähnt, offenbar verbunden mit der Hoffnung auf eine schnelle Lösung.
    Darüber hinaus zu denken, hat sich aber gelohnt, Der UX Audit zeigte strukturelle Probleme und dass der MVP nie mit Aussenstehenden getstet worden war. Eigeninitiativ Problemen auf den Grund zu gehen, war herausfordernd, aber gerade daran wächst man und lernt dazu und es hat letztlich unser gegenseitiges Vertrauen gestärkt. (Das muss man sich leider immer erst erarbeiten)

  • Wenn man denkt man ist zu früh dran mit Test, 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 schon früh, konnte jedoch erst später mit Ergebnissen aus UX Audit und Umfrage überzeugen. Das schaffte Raum für den Usability Test am neuen Testflight Build.
    Bei Festpreisangeboten lässt sich ein initialer Test fest einplanen, auf Stundenbasis entscheidet am Ende der Auftraggeber, wofür seine Stunden verwendet werden. Damit muss man leben.

  • Einige Annahmen und Fragen bleiben offen und müssen sich erst im echten Gebrauch zeigen. Erzeugt ein dauerhaft transparenter Tokenstatus nicht subjektiven Druck und stellt er damit Gewinnabsicht gegen Nutzerziele? Wie zuverlässig schätzt KI Nährwerte und schlägt Ersatzzutaten bei Unverträglichkeiten vor? Und löst die KI in Kombination mit den Filtern wirklich die Rezept-Ermüdung datenbankbasierter Apps, oder stellt sich nach einer Zeit auch ein gewisses Wiederholungsmuster ein?