Type: Conceptual project
Duration: March 2022 - August 2022; visual update December 2023
My role: Product Designer, UX/UI Designer
Performed work:
At the time of starting this project, my experience with designing apps specifically for mobile was relatively small, so I wanted to design an app from the ground up. I figured that working on something familiar to me might not benefit my growth as a designer as much as working on a topic I previously held no interests in. Because of that, I decided on designing an app for ordering healthy food. Eating and living healthily has become a very popular topic, yet many people struggle with it. I was sure there was a problem for me to find and solve.
Even though most of us would like to eat healthy (93% according to the L.E.K. Consulting 2018 food and beverage survey), relatively few people actually do so, rather than just declaring it (20% according to NDP Group). Why is it difficult to eat healthily? I knew that finding the answer to this question would be key to designing a useful app.
The answer I found was not simple. We struggle with healthy eating because of its difficulty. I identified seven obstacles that contribute to this:
By understanding the problem, I came to the conclusion that the best solution should primarily address the first six obstacles (we can't do much about biology yet). Potential users will gladly use this application if they feel it makes healthy eating easier for them.
But what about those who already eat healthily? They will also appreciate an application that supports their lifestyle. The results of surveys available online indicate four main motivations that drive them:
I prepared three personas that represent the data I collected:
As part of the preliminary research, I needed to determine who could potentially be responsible for such an application. The most probable option was a small restaurant chain that could try to fill this niche.
For the audit, I selected both platforms (Uber Eats and Pyszne aka Grubhub) as well as popular fast-food chains. During the comparison, I was primarily interested in solutions that facilitate the identification of healthy meals and the ordering process. Interestingly, not every chain has a dedicated application (e.g., Subway); they often choose not to handle deliveries themselves but to entrust this aspect to a platform (similar to what McDonald's does by offering to complete the ordering process using services like Glovo).
Restaurant platforms do not require restaurants to provide nutritional values, categorize meals accurately, or even list the ingredients. This situation makes it difficult to find a healthy or suitable meal. It is likely that this is because if the composition of meals, especially fast food options, were clearly stated, some people might be discouraged from making a purchase, which would reduce profit. Applications of various restaurant chains offer little more. Although they often promote vegan dishes, they are not always willing to disclose their exact composition. I found nutritional value tables for their meals in just two cases:
North Fish presents them in the form of an expandable list for each product. The values are written in small font and placed close together, making them not easily readable. Additionally, a noticeable number of meals lack nutritional value info.
The second application that displays this data is McDonald's. The way it presents them clearly indicates its reluctance to do so. The application employs several tactics to effectively discourage users from accessing the information. If you want to see it, you are first redirected to another screen where you have to confirm your interest once again. Once you do that, your browser opens, loading a large table filled with practically all the products available at McDonald's. It is impossible to view the necessary information simultaneously; you have to constantly scroll through the table, making sure not to lose track of the column for the desired product. This is a highly inconvenient for the user.
The ordering process did not differ significantly between the applications, as most of them utilized familiar and proven patterns. However, there were noticeable differences in the app's speed and performance. In particular, the slow-downs in Uber Eats were irritating, as the app would "think" without providing any indication to the user.
Once I had all the necessary information, I could focus on overcoming the obstacles I identified. I made sure that the solutions were simple to implement and didn't require high costs.
With goals in mind, I proceeded to create a low-fidelity prototype in Figma. It was intended to conduct a quick usability test that would tell me if users could easily complete the main flow of the application. The methodology I used for creating the prototype and conducting the test is employed and promoted by Google, hence the decision to use lorem ipsum text, limited color palette, black bars instead of real text, and a "block" structure.
Later on, I realized that this approach was suboptimal because in just a slightly longer time, I could have prepared a much higher-quality prototype that not only wouldn't confuse the testers but also provide more useful data. Removing the really low-fidelity prototype testing phase would reduce the costs associated with multiple rounds of testing and the amount of time required to achieve a functional product. Additionally, NN/g's research has revealed that testers may have difficulty understanding the concept of black lines and placeholder text. Since working on Macrolicious, I have familiarized myself with alternative methodologies and strive to precisely tailor them to the project's scale.
The tests I conducted confirmed that users were able to flawlessly complete the main flow. However, when I asked for their comments, they drew my attention to a particular element, expressing their opinions:
"It feels empty, so it's hard for me to evaluate anything."
"Will it be possible to search for low-calorie options and such?"
"The calorie count doesn't change even when I select all the additional ingredients."
"I would like to see some indication or filter for meatless options right away."
Some of these observations were influenced by the nature of the low-fidelity prototype and the way prototypes work in Figma. However, I their feedback made me realize that the item card and its related data could be more useful. I revisited my previous research and realized that the key might lie in doing things differently. Since Macrolicious' advantage is offering healthy meals with well-balanced nutritional values, why not emphasize and clearly showcase that?
If the application displayed nutritional information directly alongside images, it would make it easier and quicker for users to find the most suitable options for their needs. However, this solution had a drawback - changing the familiar user schema could create a feeling of confusion, potentially causing users to leave the app if it appeared too complex. If I wanted to present the item card in a slightly different way than the standard approach, I had to ensure it would be as intuitive as possible. It was the biggest challenge I encountered while working on Macrolicious. I wanted the item card to include the name, dietary type indication (vegetarian, vegan), price, and macronutrient information. Its size also had to be appropriately small to ensure comfortable card scrolling on a phone screen. Since I aimed to facilitate the quick identification of suitable meals, it would be best to present this information graphically, which humans "get" much faster than text, although it may not be as precise. Therefore, the optimal solution would be to combine both methods of data presentation. With these considerations in mind, I began the design process:
Some of these proposed solutions had potential, but they wouldn't work in edge cases, such as when a dish had multiple three-digit figures in its nutritional information. The final design also had to be easy to understand. Despite the current popularity of onboarding screens, new research shows that it is not necessarily a good practice, as users often skip or "click through" them without attempting to absorb the information they contain. Therefore, I wanted users to immediately grasp the meaning of the numbers and colors presented by Macrolicious, so they wouldn't have to worry about forgetting their significance even if they didn't use the app for an extended period.
The final design allows users to quickly find, for example, a high-protein meal containing less than 400 kcal. However, I did not anticipate that the card may be a bit too large for small and medium-sized phone screens, and resizing it would make the numbers too small or too cramped to read comfortably. Therefore, I created an alternative version tailored for smaller screens. The "large" version will be used in the "daily deals" section, where it can attract more attention. When designing, I made sure that my design utilized an 4-point grid and a logical auto-layout, which would facilitate the implementation of the application by developers on any phone size.
I used 32 points of distance to space out the most categorically different elements like list of ingredients, macros or action buttons.
24p spacing is used here to space out navigation elements like bottom navbar and back arrow. On other screens, without back arrow, there is 24p of space between status bar and the first text element. There are two reasons for 24p space between the item image and its name.
1) It provides visual match between a large image and title (that is also 24p in size).
2) It prevents an issue of a longer name going too close to the fav button.
Also, a quick word about the fav button - by placing it halfway on the image, the design grants more visual interests without obscuring the image too much and thus sacrificing another visually interesting element.
When two parts of the design serve similar meaning, I used 16p of spacing like between the name and its description. This number is also used for margins to let the design “breathe”.
Finally, 8p of spacing is used to create a distance between objects that have the same meaning. Like the icons for tabs and their names.
I used similar rules throughout the whole concept of this app. I have to point out that because each screen serves a different purpose in guiding the user, I reevaluated what spacings made the most sense for each screen individually. For example in the cart section, I used spacing as big as 64p to divide the price section, nutritional value and delivery time as they are even more different in this context.
I would also like to highlight the bottom navbar - this trendy solution improves the experience of browsing through the app. Its placement makes it easy to tap using your thumb, and the option to quickly switch tabs allows users to effortlessly go back and forth. The user could for example look at the total nutritional value of items in their cart and instantly return to Lunch section to add another item.
Other feature I would like to showcase is how I designed the Search tab.
Starting from the top, there is a search field where users could input ingredients or a name of the meal they are searching for. By leaving it empty, users can browse through all meals that fit their diet (all types, vegetarian or vegan). One user I spoke with was vegetarian and pointed out, that she has issues finding vegetarian options in food delivery apps, as they are often not marked in a different way. This was surprising to me, but I could confirm that there is an issue when I conducted competitor analysis. What's more, surveys show that more people worldwide describe themselves as vegetarians than vegans. Because of that I made sure that vegetarian options are easily distinguishable.
For users with advanced needs, I made easily accessible range sliders that can be used to find a meal with the exact nutritional values. Users also have an option to switch between using grams and percentages. These features would be handy for people that have strict dietary plans and are looking for a very specific meal.
Once the screens were ready, I added transitions animations, aiming not only to be visually appealing but also to reinforce the brand image. In the case of Macrolicious, slim animations that evoke energy seemed most fitting.
The Macrolicious prototype can be viewed here.
Although I designed Macrolicious with the intention of meeting WCAG standards, I decided to verify it after completing the project. The results of the analysis confirmed that the colors used have appropriate contrast for both large and small fonts. The Manrope font used throughout the application, except for the title screen, is considered legible and suitable for web use. The labels of nutritional values (kcal, Fat, Carbs, and Protein) have a font size of 10px instead of the suggested 12px, but they are not essential information. The consistent colors and layout of the nutritional values eliminate the need to read them every time, so their size should not be really problematic for visually impaired users.
I presented the completed prototype to 5 individuals from the target group, giving them a few minutes to test it independently, after which I asked them the question, "Would you use Macrolicious for ordering healthy food instead of another application?" 4 out of 5 people responded - Yes. Testers were also able to provide more detailed feedback in their comments. The aspect that attracted the most attention was the information about macronutrients, which is well summarized by the comment:
"Why don't other apps show this info?"
If it weren't just a conceptual project, I wouldn't limit myself to just a mobile application because the features utilized by Macrolicious do not require dedicated solutions and would also work well on a responsive website. Working on Macrolicious was particularly enriching for me. It improved my ability to interpret feedback and allowed me to discover an interest in optimizing UX work for business and interaction design.
