What is the Fastest Food Logger? We Designed a System to Find Out

MacroFactor’s more efficient, more intuitive, and more unified food logger is available now. With these changes, MacroFactor now has the fastest food logger on the market. 

In this article, I’ll break down the system we created to quantify the speed of logging a food in MacroFactor, compare MacroFactor’s food logger to 20 other similar apps, and demonstrate replicable workflows and use cases that confirm MacroFactor’s best-in-class speed and efficiency. 

Before we dive in, though, I need to give you a bit of back story…

Who Are You?

My name is Cory Davis.

I've been logging my food intake on and off for over a decade, resulting in around 4,000 full days logged. I enjoy trying new apps and am always looking to find the best app for every app category. For those ~4,000 days, I wasn't locked down to one app; I tried out anything and everything out there for at least a few weeks.

I wasn't delighted with what was offered in the food logging app category a couple of years ago, which is partly why the MacroFactor app exists today. I am one of two developers for an app with comprehensive food logging functionality, and I've learned a lot about food logging as a user, designer, developer, and product manager.

At MacroFactor, we don't sit in the dark and blindly develop features. We keep up-to-date with the market by regularly performing extensive competitor analysis, and we are deeply engaged with our communities (which help influence our roadmap).

Why We Developed the FLSI

The goal of most apps is to monopolize as much of your time and attention as possible, but food loggers are a bit different. In general, users appreciate it when a food logger requires as little of their time as possible: they’re not opening their food logger to scroll through a social media feed or play a game for an hour – they’re generally opening their food logger to log a meal, and then get on with their day. Being able to log a meal in one minute is generally preferable to being able to log a meal in two minutes, and being able to log a meal in 30 seconds is better yet.

MacroFactor had been on the market for a few months. Though we were satisfied with the quality of the product and believed in the merit of many decisions we made concerning food logging, we had begun planning a massive overhaul of our food logging systems. 

Our communities are highly active, and community members are not afraid to share their ideas about what would make MacroFactor better. That’s an absolute blessing when it comes down to making product roadmap decisions. We don't have to guess what our users want; they will tell us! Early on, this was a bit overwhelming, and it seemed like we received a year's worth of feedback in a month. 

When we see a wealth of quality feedback, we don't ignore it, even if it's hard to address. We even took on the immense effort and cost to build our own database and search service in response to feedback, but that's a story for another time.

The feedback we wanted to address related to food logging required solutions that were fundamentally incompatible with what we had built. We could implement halfway solutions or do some ground-up thinking and rebuild half of our app. Naturally, we rebuilt half of our app.

When building a food logger, design systems and user experience principles provide some guard rails for how the user interface should look and how interactions should feel. Coding best practices give some hints about how you might go about building it. 

But, there were no familiar sources of wisdom to tell us how quick and convenient the actual food logging workflows we were re-designing were. For a food logger, though, this is critical. Users who diligently track what they eat may interact with some of these workflows 15+ times per day!

Our response to that problem is to introduce a new system that quantifies the speed of a food logging app. We call it the Food Logging Speed Index (or FLSI for short). 

The Oxford English Dictionary defines speed as: "the rate at which someone or something is able to move or operate." For the FLSI, someone or something is the app's user, and operation is the process by which users accurately log their daily food consumption.

But, the real-world process of food logging is not an all-out fevered sprint, and the purest possible metric for speed (time) is operator specific. The FLSI is a real-world index; its metric measures the number of discrete actions required to complete common food logging use cases.

In other words, it aims to provide an objective measure for how fast a food logger's core workflows are to use.

Aren't you extremely biased when it comes to food loggers?

Absolutely! But, counterintuitively, that's precisely why the FLSI has at least some shred of credibility. I am biased toward making MacroFactor the best product it can be – if the FLSI were designed for MacroFactor to be at the top, it would have been a complete waste of time. We still wouldn't have any basis for quantifying speed, and the excruciating process of building this index would have crushed my efficiency-minded spirit. 

As we theorized, MacroFactor didn’t start at the top of the rankings. It was silver ranked before version 1.3.5 (the revamp), and before 1.0 (the beta), it would have been bronze ranked. MacroFactor is at the top now because we tirelessly iterated on designs for months and months during our food logging systems revamp until we designed systems that would meet or exceed the best result in every use case. 

After creating the first use case, there were already some fascinating results, and we knew that we might be interested in publishing the index online. And so, I used an exceptionally high level of scrutiny when constructing and finalizing the FLSI to make it robust and more worthy of public trust.

Methodology

The FLSI has four use cases designed to cover some of the most common food logging workflows:

1. Logging Through Search

Searching a database and selecting a relevant result is the most common logging use case for most users.

2. Logging With Multi-Add

When you have logged a food before or the search result already has the correct serving and serving quantity, multi-add/fast-logging shortcuts are a powerful utility.

3. Logging By Scanning

Directly scanning the barcode on branded product packaging can be a fast way to log food.

4. Quick Add Calories

When you know the calorie and/or macronutrient numbers you want to log, but you don’t care about associating those numbers with particular food(s), this is the way to go. Handy for many circumstances.

Individual components of food logging workflows, like selecting the serving and quantity of food, are not tested directly in their own use cases, as they are covered within the process of the use cases above.

A use case is complete when all of the objectives within the use case are met. There are only one to two unambiguous and easy-to-understand objectives in each use case.

The score for a use case is the number of discrete actions required to meet the objectives given a fixed start and end page. A lower score (fewer actions) is better.

If the app being tested cannot satisfy a use case, the score for that use case will be set to the worst score in the testing group.

A use case score is considered strong if it's lower than the average of the lowest and highest scores. When this results in a decimal value, it's rounded up to the nearest whole number.

Assumptions

• The settings that enable the fastest workflow for any individual use case will be used for that use case, even if the settings are incompatible across various use cases. A common example is when an app has a setting that enables/disables multi-add capabilities.
• The shortest list of actions to accomplish the use case will be used, even if it's not the most intuitive.
• An action must be reasonable–e.g., a custom gesture where you draw a summoning circle to launch the food logger isn't going to be used in the shortest list of actions, even if the option is available and has a cool flame-heavy spawning animation.
• The premium version will be used if the app being tested uses a freemium model. 

Freebies

1. If the app requires settings that are incompatible across use cases to get the best score for one use case, there will be no penalty applied.
2. If scrolling is required to get to the best launch point for workflow, the FLSI will ignore that, even though you could credibly count that as a discrete action.
3. If the app's search uses autocomplete suggestions (or nothing) instead of searching as you type, the FLSI will not count the extra tap needed to select a suggestion or submit the query.

I debated whether to quantify the number of actions associated with each of these freebies, as they do all make the process of logging slower. However, I opted to give apps a free pass when these considerations arise, because there’s not always an objective, clear-cut way to quantify these actions in the FLSI. None of these “free” actions would impact MacroFactor’s score, so this provides other apps with a bit of a handicap: these freebies improve the scores of other apps, but have no impact on MacroFactor’s scores.

Here's an example:

Let's pretend you are a new MyFitnessPal user logging their first food, which happens to be a taco. After typing "taco" in the search bar, you won't see any results. Instead, you will see a small banner indicating that you can search for online results. That means there's an extra tap involved to get results.

By default, as you type, MyFitnessPal will only search foods you have logged in the past. If you had logged a taco before, it would have become present as you typed “taco.”

Based on this information alone, one could argue that the FLSI should establish that only the new user experience is relevant. There's a certain purity to working from a clean slate. 

But, I believe an equally valid argument would be that the FLSI should only consider the long-term experience, as tracking is not often a short engagement. Additionally, the cost associated with enduring low-efficiency food logging workflows is compounded over time.

Either way, you're left with ambiguity about whether the example food was logged before or is entirely new to the user. If you wanted to open up a boutique shop that sells some of the world's most exotic slippery slopes, you could easily assume that all use cases involve foods that have never been logged before. 

You'd need to add that context to the relevant use case objectives, and that's the end of the story.

Except, actually, no, it turns out that if you use the keyboard submit key, MyFitnessPal will execute the online search. Do keyboard inputs that aren't part of the search term count? Does the guaranteed late execution of the search result in a penalty compared to a search-as-you-type implementation that is sure to surface results sooner due to a carefully crafted debounce rate? Do androids dream of electric sheep?

Make it stop! No problem, we have the easy button: freebies.

Again, none of these considerations apply to MacroFactor. These freebies only provide leeway that strengthens the competition and creates higher comparative standards for MacroFactor. 

Competitors

Listed in alphabetical order:

• 1st Phorm
• Avatar Nutrition
• Carb Manager 
• Carbon Diet Coach
• Cronometer
• FatSecret
• Fitatu
• FitGenie
• Food Noms
• Foodvisor
• LifeSum
• LoseIt
• MacroFactor
• MyDietCoach
• MyFitnessPal
• MyMacros+
• MyNetDiary
• MyPlate
• Noom
• Yazio

How were these apps chosen?

I looked at the top charts on the Apple App Store and the Google Play Store. Additionally, I brought in any apps that users of the MacroFactor communities mentioned in passing. A notable exclusion is the RP Diet App; ostensibly, it is a food logger that meets these criteria. But, in reality, the aspect of forced meal planning, and non-traditional macronutrient accounting, make this app's workflows non-representative for FLSI comparison.

Logging Through Search (Use Case 1)

Start Page → End Page

Search Page | Food Log Home Page

Objective 1

Log Greek yogurt through search using a non-default serving and non-default three-digit quantity.

Objective 2

Log honey through search using a non-default serving and non-default three-digit quantity.

Strong Score

Less than 16

Rationale

We used a non-default serving and quantity to eliminate the edge case that would otherwise be present. If the use case were to log 170g of Greek yogurt and 10g of honey, some apps would default to 170g for Greek yogurt (representing a single-serving container), and some would not. Having reasonable defaults is interesting to test for, but we’re looking for an unambiguous evaluation of quantity selection speed.

We used a three-digit quantity to test for adequate flexibility and ensure that logging food by weight is convenient. Given the total amount of food required to support an average diet, logging food by weight will result in more three- and four-digit quantities than one- and two-digit quantities.

Two foods are logged instead of one, as meals often do not consist of a single food, but logging three or more foods needlessly penalizes slower selection methods over and over.

Results

Listed strongest to weakest:

Strong

1. MacroFactor - 10
2. MyNetDiary - 11
3. FitGenie - 13
4. LoseIt - 13
5. Noom - 14
6. Food Noms - 15

Weak

7. MyPlate
8. Yazio
9. Avatar Nutrition
10. Carbon Diet Coach
11. Cronometer
12. FatSecret
13. Fitatu
14. LifeSum
15. MyDietCoach
16. MyFitnessPal
17. Foodvisor
18. Carb Manager
19. 1st Phorm
20. MyMacros+

Logging With Multi-Add (Use Case 2)

Start Page → End Page

Food Log Home Page | Food Log Home Page

Objective 1

Log banana through search using a default serving and quantity.

Objective 2

Log peanut butter through search using a default serving and quantity.

Strong Score

Less than 9

Rationale

When a food entry in search has the correct serving and quantity for what you're logging, that is the only time multi-add provides a time-saving benefit.

Most people aren't logging exclusively new foods and meals every day, so if an app saves the last used serving and quantity for historically logged foods, the opportunity to use multi-add occurs more and more over time.

Opportunities to use multi-add will be available on day one, too, but it's more circumstantial.

Two foods are logged instead of one, as meals often do not consist of a single food, but logging three or more foods needlessly penalizes slower multi-add methods over and over.

Results

Listed strongest to weakest:

Strong

1. MacroFactor  - 6
2. FitGenie  - 6
3. LoseIt  - 7
4. Carbon Diet Coach  - 8
5. LifeSum  - 8
6. FatSecret  - 8
7. Foodvisor  - 8

Weak

8. MyNetDiary - 9
9. Fitatu - 9
10. MyFitnessPal - 9
11. Cronometer - 9
12. Yazio - 9
13. Noom - 9
14. MyDietCoach - 9
15. Food Noms - 10
16. MyPlate - 10
17. Avatar Nutrition - 10
18. Carb Manager - 10
19. MyMacros+ - 10
20. 1st Phorm - 11

Logging By Scanning (Use Case 3)

Start Page → End Page

Food Log Home Page | Food Log Home Page

Objective 1

Log branded item through barcode using a non-default serving and non-default three-digit quantity.

Strong Score

Less than 10

Rationale

The rationale here is largely the same as in the first use case. However, adding multiple foods for a given meal isn’t always the case; sometimes, it is only one, and we wanted to offer a use case that tests for that. Barcode scanning is a perfect opportunity, as that’s when logging a single food is more common; branded products are more likely to be a complete meal or snack.

Results

Listed strongest to weakest:

Strong

1. MacroFactor - 6
2. LoseIt - 7
3. MyNetDiary - 7
4. FatSecret - 8
5. Yazio - 8
6. Fitatu - 8
7. Cronometer - 8
8. MyFitnessPal - 8
9. Food Noms - 8
10. FitGenie - 9
11. Carbon Diet Coach - 9
12. LifeSum - 9
13. MyDietCoach - 9
14. MyPlate - 9
15. Avatar Nutrition - 9

Weak

16. Carb Manager - 10
17. Foodvisor - 11
18. Noom - 11
19. MyMacros+ - 12
20. 1st Phorm - 12

Quick-Add Calories (Use Case 4)

Start Page → End Page

Food Log Home Page | Food Log Home Page

Objective 1

Quick-add an arbitrary calorie value.

Strong Score

Less Than 7

Rationale

The intention here is solely to test the speed of quick-add functionality, which is a typical food logging workflow.

Results

Listed strongest to weakest:

Strong

1. MacroFactor - 4
2. LoseIt - 5
3. MyNetDiary - 5
4. Fitatu - 5
5. MyFitnessPal - 5
6. Carbon Diet Coach - 5
7. MyMacros+ - 6
8. 1st Phorm - 6

Weak

9. Cronometer - 7
10. Food Noms - 7
11. LifeSum - 7
12. Yazio - 8
13. FitGenie - 8
14. Carb Manager - 8
15. FatSecret - 9
16. MyDietCoach - 9
17. MyPlate - 9
18. Avatar Nutrition - 9
19. Foodvisor - 9
20. Noom - 9

Final Scores: The Fastest Food Logger

Listed top to bottom:

Gold (1st Place)

1. MacroFactor - 26

Silver (2nd Place)

2. LoseIt - 32
3. MyNetDiary - 32

Bronze (Below 1/3 Percentile)

4. FitGenie - 36
5. Fitatu - 39
6. Carbon Diet Coach - 39
7. MyFitnessPal - 40
8. Food Noms - 40

Above 1/3 Percentile

9. Cronometer
10. LifeSum
11. Yazio
12. FatSecret
13. Noom
14. MyPlate
15. MyDietCoach
16. Avatar Nutrition
17. Foodvisor
18. Carb Manager
19. MyMacros+
20. 1st Phorm

Not to take too big of a victory lap, but the gap between MacroFactor and “the field” as across the four most common food logging flows even surprised us. And remember, if anything, the FLSI may undersell MacroFactor’s edge in speed, since some of our competitors’ scores were aided by freebies that don’t apply to MacroFactor. 

Is 26 the best possible score for the current FLSI? One feature that we're actively designing includes a practical one-point reduction. And if you get a bit experimental, you can take it even further. So, no, it’s not.

The FLSI is likely to see updates over time, not just to re-score competitors but also to improve the index itself. It has already gone through a few revisions before publishing. Something that may be interesting for the future is being able to account for non-standard workflows.

Most competitors have been tested at least four times over the last three months. However, I am not an expert at using every app and may have missed the fastest way to accomplish some of these use cases for one or more apps. I will make a reasonable effort to clean up errored results in-between FSLI versions.

The original scoring sheet, which includes the individual action count for each app, is available here.

Closing Remarks

We didn't optimize MacroFactor exclusively for speed. The goal was to create an intuitive and comfortable experience that's feature-rich and FAST. We believe that we accomplished just that! MacroFactor is quantifiably the most efficient and fastest food logger on the market. 

Learn more about what MacroFactor has to offer.