Eric Hart Design

Asken Diet: Food logging feature redesign

Summary - Redesigned food logging feature for a weight loss and nutrition advice app called Asken Diet.

What it is - Asken Diet is an app that helps its users better understand their diet & nutritional intake and get advice on how to hit their nutritional goals. I was tasked with redesigning the food logging flow to: A) increase the number of food items logged per user per week and B) make the food logging flow more flexible and easier for users to log both single items & full meals.

How it works - The user must complete five main actions when logging food in Asken Diet: 1) Choosing which meal-of-the-day they’d like to log. 2) Searching for food. 3) Adding food to their Plate. 4) Adjusting serving sizes on their Plate. And 5) Logging the food that’s on their Plate.

My role - Research, strategy, wireframing, UI/UX, prototyping, design, bug testing.

Where to get it - Download Asken Diet here


-Increase the average number of food items logged per user per week


-Average number of food items logged per user per week


Avg. number of food items logged per user per week (iOS)

67.9% increase

Avg. number of food items logged per user per week (Android)

38.7% increase


Introducing a metaphor

The lack of metaphor usage in Asken Diet’s old food logging flow felt like a missed opportunity for clarity and was causing confusion. Previously, after searching for food, a tap on a food item would immediately log that food and trigger a congratulatory message pop-up with a notification badge appearing on the utensil icon in the header. This process was good for logging one food item quickly but, what if a user wanted to log more than one food item at once? When the user taps the utensil icon, why does it allow them to change serving sizes after logging, but not before? Getting a congratulatory message with each food item logged seems excessive; is it really needed? I needed to completely rethink the flow.

In the real world, people use plates to collect food items before eating. I took this common real world behavior and used it as a metaphor in the redesigned food logging process. Now, a user searches for a food item and adds it to their Plate. They can: remove food from their Plate, search for new food to add to the Plate, create a custom meal from the Plate and edit serving sizes of food on their Plate before logging. It makes for a much smoother, more familiar and flexible process and reduces the number of distracting pop-ups.

Old version without metaphor

Redesigned with Plate metaphor


Observe the humans.

Humans using plates as a vessel to carry food they plan on eating was the inspiration for the new UX pattern I used for food logging. I believe finding ways to incorporate patterns into a digital product that allow commonly observed human behaviors to continue can increase usability. If I can empathize with users and leverage familiar patterns and behaviors I can deliver a much more successful product.

Organizing a product backlog is tough.

This was a beast of a project. After many critiques and iterations this project was ready to be folded into our scrum product backlog and separated into phases. We needed to break it up into smaller tasks for our sprints. First, we chose to set the priority starting from easy-to-develop tasks to more difficult, time-consuming tasks. This didn’t last long. Things deemed easy at the top of the list were ending up unable to be developed because some difficult things at the bottom of the list needed developing first. Rearranging each of the 50-60 tasks while asking, “how does this effect the others?” was daunting but enlightening.

A/B testing a non-standard UX pattern would’ve been nice.

In the food logging flow there’s one non-standard UX pattern that I couldn’t avoid using because it was demanded by stakeholders.

In the flow, a user is able to textually search for multiple food at the same time. We called this “multi-keyword search”. An example of this would be: “bread, steak, and eggs” in one search field. The search result given for this example would consist of three “most likely to be chosen” results; one for bread, one for steak, and one for eggs. If our algorithm has given the user an incorrect result for “bread” out of the hundreds of possible results, the user needs to be able to search for the correct “bread” item and replace the incorrect result. This is the non-standard pattern. It all stems from wanting to have multi-keyword search input.

The goal of the food logging redesign was to increase the average number of food items logged per user per week. I really wanted to A/B test the effectiveness of multi-keyword search and it’s accompanying non-standard UX pattern against a typical single keyword search in achieving that goal. Although multi-keyword search allowed the user to quickly find more foods, I had a hypothesis I wanted to test. My hypothesis was that single keyword search would be easier and faster for users because there would be a decreased risk of our algorithm choosing incorrect food items. These incorrect results force the user to waste time in a non-standard UX pattern trying to reconcile the search error. An error that isn’t even their fault. It would’ve been great to be able to test this.