Why an app to create recipes?
Food is an interesting topic. The majority of people like eating. However, cooking is a different story. It could be a hobby for some and a nightmare for others.
The purpose of this project was to develop from scratch a native app for Android OS at a high-fidelity level in 5 days. The app provides people different recipes to cook with the ingredients they have in their fridge.
The product aims to all these people who find difficult to create original and appealing dishes after a long day of work and a few ingredients in their fridge.
Discovering the real problem
At the discovery phase of my project, I conducted user interviews in order to get a better understanding of the users and their problems. I wanted to confirm that this was a real need for people.
Although surveys are a fast way to gather information, I decided to do interviews because they give me a deeper understanding of the problem and the context. Some of my questions aimed to understand whether people prepare their weekly menus in advance or they improvise with the ingredients they have at home. I also wanted to know what was exactly the pain point, having in mind the availability of a variety of apps with recipes in the market.
I interviewed 7 people and I launched a one-question-survey on Instagram, which was answered by 91 users. The latter helped me to narrow the topic with a follow-up question.
This diagram shows some quick insights from this research phase.
Instead of planning the week in advance, in general, people prefer improvising with some basic ingredients. The main problem of this approach is the lack of variety in the menus, which can cause boredom. The reasons for people to stick in the same recipes were lack of creativity or time, tiredness, laziness, and difficulty to find new ingredients
All this information made me move from a “menu planner” to a “daily menu improviser” app.
Defining the target user and the problem
To keep the focus on the target user, I developed the following user persona which was based on my research data. “Luisa” was present during the whole design process, at the center of any design decision and, was especially useful at the end, when defining the main action of my app.
With “Luisa” in mind, I defined the problem statement as it follows:
“People need a way to create different recipes with the ingredients they have at home because it’s difficult being creative and they feel bored fast”
Helping Luisa with the daily menu improviser
Let’s imagine that Luisa has just arrived at home after a long workday. She is starving and only has eggplant and tuna in her fridge. She feels too tired to think about original recipes… what can she do?
This is the most recent prototype of «Daily Menu Improviser». It has changed a lot since the beginning of the project because it has been tested many times with real users. Their feedback is very valuable to make the product better in terms of structure, navigation and look and feel.
Challenges and iterations
I usually start the design process with low fidelity wireframes. Paper prototypes help me to ideate solutions and present my ideas to initial testers. This is the way I iterate through many design options quickly.
Users needed a way to search for recipes by ingredients, so the app had to include a live search box on its home page. Moreover, because allergies are more and more common nowadays, I considered important to add filters to the app, so the users could customize their search. To make it more agile, I also included “my favourite” and “my recipes” sections, which are very usual in other related apps.
I made seven versions of the prototype. The main difference among them can be summarized in the next challenges.
Lack of visibility of the system status.
People needed more information or feedback especially at two points of the flow: the “search” and the “filters”. To solve this, I decided to add tags in both sections and that was enough to help the users to understand what was going on.
Lack of consistency.
Specifically, in the text underneath the icons. As some icons were unusual, I decided to add a name to all the icons.
A mismatch between system and the real world.
The first mismatch was in the application of filters. People expected the process went in one direction -from left to right- and having to go back was weird for them. The second was on the tab bar. People expected “search” and “favorites” to be in the same category -common- and “recipes” and “profile” in another -personal-. To solve the former I added a confirmation button, which also alleviated the anxiety of not having a “save” button after making some decisions. To improve the latter, I rearranged the icons in the tab bar so they follow people’s mental categories.
After some iterations, my high-fidelity prototype still presented tome troubles. The most difficult ones for me were:
1-Do an inclusive design. My font-size was very small and difficult to read.
2- Play with the color palette, as it was transmitting the opposite emotions to the ones I wanted to evoke in my users. I wanted to transmit something “fresh, appealing, flexible, inspiring and time-saving” and people were feeling the template as “formal” and “old-style”.
3-Clarify the main action of my app, because I had two Call To Action buttons that were in conflict on the home page.
Road map and takeaways
One of the things I didn’t have time to explore was the inclusion of a “profile” is this app. Testing my prototype I found out that people wanted to have a profile and include things like a picture, a name, preferences, and filters, personal goals or location. This is one of the areas I’d love to expand in the future.
Developing this new app from scratch has taught me the following things:
Start the design thinking in “big sizes”, then you’ll have time to reduce it. I had some trouble with the font size and the use of the white space.
Try and test different color palettes until you reach one that transmits your “goals” for the app. I found that my color palette wasn’t right one very late in the process and that made more difficult to implement the changes.
Whenever you doubt, go back to the user persona and try to decide from her point of view. This helped me a lot when I had to decide the main action of my app because there were two conflicting CTAs.