Cherry app
UX Research
UX Design
Digital Prototyping
↑Rakan Alabadi, Rita Moreira & Antonella Pastore
This project was part of a 6 weeks long hands-on class taught by Sketchin, one of the biggest and fastest-growing design studios in Europe. Through this class, we experienced a full design app process, starting from problem identification, passing through solution design and eventually user testing. Based on an initial brief and a specific persona, we had to develop an interactive prototype that would suit our persona's needs.
Design a food delivery app capable to answer the new and rising needs of consumers, while truly standing out in an already crowded and competitive market.
This brief seeks to connect the food delivery market, a market that has been exploding since the covid, with people's growing consciousness of how they live and what they eat. Indeed, nowadays food delivery has become a global market worth more than $150 billion, having more than tripled since 2017. On the other end, people are becoming more and more aware that their lifestyle impacts their health and that of the planet. As a result, they have increasing standards and specific needs.
From this context, we received a persona for which we had to base our research and solution :
For this project, we were 3 students and we worked together on all the design phases. We used Figjam to collect, synthesize our findings, brainstorm and create experience maps. Figma was used to build the prototype and the design system.
Starting with our Personas Akash, we first selected the important elements that were relevant to the project :
After that, we tried to define what the objectives of Akash could be when it comes to food delivery. We were aware that these objectives were based on our interpretation of our personas and therefore made of assumptions. We should have interviewed someone who matched the personas, but due to lack of time in the course, we didn't have the possibility to do it.
In a nutshell, our solution should :
With a better vision of what Akash is looking for in food delivery, each team member made an "as-is" experience map of a competitor that we then put in common to create a main one representing the As-Is Experience of Akash with current food delivery apps. We decided to do it this way because since we could not conduct a survey or interviews in the time allotted for this phase, we thought that having all three of us try to build Akash's experience and then bring it together might be a way to highlight recurring pain points and key elements, making the experience map more valuable.
With this experience map, we were able to find the biggest pain points in Akash's journey to order food. These pain points were then transformed into opportunities that were then turned into How Might We questions.
Having defined the areas to focus on in our solution, we started the ideation phase by doing a Round Robin for each HMW we came up with. We opted for this technique because it allows us to elaborate a bit on each idea rather than having many different ideas without thought.
In total we conducted 5 round robin that gave us 3 ideas per HMW, so a total of 15 ideas. We clustered similar ideas together and took a vote to define which ideas would be retained.
All our voted ideas were then developed into solution cards so that it could be presented in a real context. For each solution card we have highlighted the advantages for the user but also for the company. We also used the card to propose a MVP defined by a user tasks list. This definition of the MVP saved us time in the design of the to-be experience map.
Below is one example of the solution card we came up with along with an overview of its to-be experience map.
The to-be map helped us to better identify the precise moments when certain features should appear. It also allowed us to align our different visions into a common one across the team and it acted as a compass for the prototyping phase. With the to-be map, we also could think of alternative flows such as skipping questions or the whole chat.
Before starting the prototype, we did a definition of the various screens of our solution, then we went into low-fidelity wireframes. Also, from the start we tried to build components in order to be able to easily re-use them for the final prototype. In parallel we started defining the style guide of the app and its identity.
To define the identity of the app, we first looked at the meaning of colors, especially those that were most commonly used to represent food and dining. We saw that red was associated with strong emotions such as passion and excitement. We felt that this description suited Akash well: he is passionate about his work, his values, but also about his family and friends with whom he likes to spend authentic moments.
That's why red was chosen as the primary color.
The rest of the palette was thought to be sober in order to focus on the icons and the products' images.
After that, for the logo, we looked at what foods were red and we found the cherry. It symbolizes luck and future happiness, positive elements that correspond to what we wanted the app to be for Akash: a new experience that will make him happy!
In order to make the app more friendly, we came up with the idea of having a mascot that would help the user in deciding what to eat. Thus, a mascot in the shape of a cherry was created. It reminds the name of the application and the logo.
For the font, we used Lexend, which is a clear and clean font that was shown to significantly improve reading-proficiency.
Finally when the prototype was ready, we were able to conduct quick user testing within the class. For that we came up with 4 user scenarios for the participants to perform. From this user testing, we discovered problems that we tried to transform into insights while considering Jakob's 10 Usability heuristics. We were able to implement some fixes (the post-it with a star on it). This short testing has allowed us to see that participants managed to navigate easily and intuitively throughout the prototype. The questions in the chat and survey seemed clear and the option to login as a guest was appreciated.
Here are overviews of Cherry for each of the solutions we have implemented. Enjoy! 😁
At regristration, we ask a few questions around the user's lifestyle to later suggest restaurants that are popular amongst people with the same lifestyle
Pain point solved: Registration is a boring and annoying step for users.
By offering a true "guest" experience, without requiring to register, occasional or busy users can order food without friction. Only after ordering, the user is invited to sign-up.
Pain point solved: Although the user has chosen to browse as a guest, he is asked to register just before finalizing the order.
When opening the app, the user has a chat with a friendly guide that would ask him what kind of food he wants to eat today. Based on the answer, the app will highlight all the restaurants *and* meals that fit his wishes.
Pain point solved: The filter system is not efficient enough for picky eaters or specific diets.
Each meal has an “ingredients” section that list all its ingredients. Each ingredient that can be removed would be clickable. The user has to click on an ingredient to remove it from his dish.
Pain point solved: The option to remove ingredients appears too late in the experience and is error-prone.
After chosing a restaurant, the user can create a group order session and invite people to pick their food. Everyone can pick their dish at the same time, reducing waiting time.
Pain point solved: The user wastes too much time while other family members choose what to eat
After receiving a link for the group order, the invited user will be able to either login or go as a guest to pick his/her meal.
Pain point solved: The user wastes too much time while other family members choose what to eat
Overall, this project would need more user testing and development. With the time constraints, we had to focus on a few phases of the ordering process which means that for example for the guest experience, we did not develop the screen that invites to register after paying for the order. And ultimately we preferred to focus on a few phases, but with careful thought, rather than designing several things that don't make much sense together.
The functionality of making group orders could be further developed by including a chat or voting system for shared appetizers or drinks for example. We also think that Cherry should be a web app available on desktop to make it accessible to invited group users who don't have the app.
Beyond all that, this project was a real opportunity to go through the different stages of design thinking in a team environnement with all that it includes: the different agendas, experiences and opinions. The mentorship and use cases that Sketchin shared with us throughout the process were very inspiring. I think one of the great strengths of our prototype is that it is consistent and smooth thanks to the constant team work and reflection.
From a personal point of view, I'm happy I was able to apply my UML skills in the creation of the to-be map and also to share my knowledge about Figma components with my team. I also helped with the general management of the project and its various weekly deliveries.
If you are interested in working together or have a question about my work, leave me a message and I'll be happy to answer you as soon as possible.
