Welcome to Yummy
Problem Statement
People with dietary restrictions need more detailed food information to get rid of the confusion of the ingredient in the dishes |
Our Vision
A world in which people with dietary restrictions feel supported by their communities. |
Context
Yummy was created in Autumn 2017 over the course of about three months in HCDE 318:“Introduction to User-Centered Design”. |
User research
In order to figure out if there was a problem we wanted to solve for people with dietary restrictions, we had to conduct user research. We each completed a competitive analysis of products in this field to better understand the pros and cons of what was already on the market. Then, we interviewed one vegan, one pescatarian, and two vegetarians. Each of our interviewees were UW students, between the ages of 18 and 22. We asked them standard questions about their dietary restrictions, like how long they have had it, why they have it, and what resources they currently use to help them make decisions about what to eat based on their dietary restrictions. We also asked our interviewees how their dietary restrictions affects their social lives, and if they feel their dietary restriction is supported by the UW community.
Through this research, we learned that all of our interviewees experienced problems identifying the ingredients in their food as well as the options available for them based on their dietary restriction when they eat out. They also generally felt unaccommodated for as a result of their dietary restriction. |
|
|
|
|
Personas
Based on these interviews, we created two personas, Patrick and Leilani. Each polished persona was preceded by a provisional persona, in which we drafted out the defining characteristics of each persona along with their everyday goals, desires, experiences, and challenges. Each of these aspects of the Patrick’s and Leilani’s persona directly reflected information we gained from our interviewees. This process helped us analyze the struggles people with dietary restrictions face, and begin to pinpoint where we could potentially help them.
Creating these personas really helped us humanize and develop empathy for our user group. As we reached different stages in the development of our application, we often thought about how our designs would impact our personas. |
|
User journey map
In the creation of our personas, we were able to solidify their goals, desires, and challenges. Mapping out Patrick’s experience at a fraternity formal helped us break down his interactions at the event, along with his thoughts and feelings at each interaction, and how they relate to his dietary restriction. We constructed this in order to understand the problems our users face as a result of their dietary restriction by walking in their shoes, and identifying a problem to design a solution for.
In our project our main focus was on menu labeling at restaurants. |
Walking through an evening in the eyes of Patrick at a catered fraternity formal event allowed us to empathize with him and decide how we could improve upon his experience with the menu specifically. This map set us up for our next step: deciding how to help Patrick better understand the ingredients in his food, and find dishes that he can order at a restaurant based on his dietary restriction. Now that we had created a contextual scenario, where we could identify what our user needs at each touch point, we were able to move on to working on our design requirements where we would brainstorm what our persona needed in order to accomplish their goals.
|
|
Design requirements
Design requirements forced us to think about “what information and capabilities our personas require to accomplish their goals”(About Face, 106). When we created our user experience map, we were able to recognize, based on their emotions and thoughts at different touch points, what our users’ needs were. Through the process of solidifying our design requirements, we defined what our design must accomplish based on our users’ needs, a critical step before designing how it would be done. Our design requirements outlined the best way we could meet our personas needs before we jumped to the solution. Once we laid out our requirements, we moved on to information architecture, where we diagrammed different screens users will find themselves at as they navigate through our application.
|
Design Requirements
|
|
Storyboards
After defining our problem statement and design requirements, we all individually created two storyboards, one hand-drawn and another with photographs, to illustrate different design solutions. Storyboards are short graphical representations that communicate our envisioned scenario in terms of the designed object function, the contexts of its use in real life, and the user experience of it with the use of visualization and storytelling technique.
|
The storyboard was a turning point in the development of our design solution. At this point, we shifted our focus to the experience of people with dietary restrictions at restaurants rather than with caterers in our user journey map. The storyboards helped us form an interaction flow for our application, and also guided us while we developed the information architecture. They gave us a platform to explore and critique potential features of our application.
|
|
|
|
|
Information architecture
Our information architecture diagram is a flowchart of interactions depicting the organization of screens and information within our application. After working through our storyboards, we decided we wanted to create an application that would sort menus for users based on their dietary restriction. We created this diagram to develop the flow of interactions our users would go through while using our application. At this point in our design, we were beginning to think about what we wanted our primary functionality to be. Did we want to the main way our user generated menus to be by scanning a QR code at a restaurant, or by selecting restaurants in the restaurant catalog? Did we want to be a preventative approach, or an aid in-the-moment?
Though this analyzation left us with a lot to think about, we were able to test out different functionalities and their priorities in our paper prototypes. |
|
Paper prototypes
From the interaction flow that we created for our application with our information architecture, we chose three key paths to develop our paper prototypes. This is a low-cost and fast way to test our layout and design. Paper prototyping is sketching each application screen on paper with regard to layout of each screen and the entire navigation system. With the use of our paper prototypes, we conducted the usability test and were able to refine our design from the test feedback.
|
|
Evaluation
We tested our paper prototypes on four people with dietary restrictions and received a lot of useful feedback. Our primary motivation in doing this was to make sure that our application and its features would be beneficial for our user group. We also wanted to see how we could improve the flow of our interactions and information organization in our application. Dietary restrictions can range from allergies, to maintaining a vegan or vegetarian diet, to fasting because of religious holidays.
|
The four main findings of the evaluation were
|
We tried to solve the problems brought to light in the testing and incorporated these changes in our wireframes. We made two main changes in our design. The first one was making our home screen a restaurant catalog rather than the QR code scanner. Another change was altering the camera icon to a QR code to make the functionality of the button more transparent.
|
|
Annotated Wireframes
The evaluation brought forward several problems that needed to be addressed for our next step of the project: annotated wireframes. Before we could create high fidelity prototypes, we wanted to be able to plan out the layout, structure, and overall design so that we could build a framework we could build on for the high-fidelity prototypes.
|
Before we started wireframing we got together as a team and discussed the edits we needed to make, like how we could make creating dietary profiles scalable. Then based on our information architecture, we made wireframes for each key screen within the app. We made sure to focus less on the visual details and more on the functionality. Additionally, we added annotations to the components within each screen to make sure everything can be communicated properly to the high fidelity prototypes.
|
|
High-fidelity mockups
Our final step of building yummy was our high-fidelity mock-ups. This was finally a step to bring our learnings from these past 10 weeks to build an end product for our target users. With the design of Yummy, we wanted to be lightweight and approachable. This is why we decided to go with a look that uses soft colors and simple illustrations. Each of the high fidelity screens was based on the annotated wireframes we designed previously. We wanted it to feel like a real app that can be on the app store.
|
We used an interface design tool called Sketch to design all of the screens and illustrator to build the brand that surrounds it. One of the challenges was to keep consistency in things like type, color, and margins because there we wanted it to feel uniquely “Yummy” throughout the whole experience. At the end of it, we had 13 detailed screens that demonstrates what Yummy would be if it were an actual app.
|
|
Reflections
What we would do differently
If we could go back in time, we would change our persona Leilani. Leilani was very similar to one of our interviewees, and we were not able to solve her specific scenario - being a buddhist who is dietary restricted on certain days according to a lunar calendar. Instead, we may have used that information to create another persona based on commonalities from all of our interviews. What we would do if we had more time If we had more time, we would work out some more features for our application. We were interested in allowing users to adjust their dietary restriction if it was time-based (i.e. fasting). We also like to develop a way to allow users to easily export their profiles. This would be useful when communicating with organizers of events of a smaller scale, such as a camp counselor or a chef in a fraternity. We are also very interested in pitching our idea to local restaurants, and seeing if they would be interested in running a trial of Yummy. Our biggest challenge The biggest challenge our teams faced was being rationale of how the restaurants would comply with our vision of Yummy. We went from thinking of how we could pass “Patrick’s Law”, which would require all restaurants to surrender their whole list of ingredients and update it when needed, in the interest of satisfaction (and loyalty with) the customer. We had to recognize that some restaurants may not want to give their ingredients (it’s a secret!) or just simply don’t want to keep up with it, so we would have to give them some customer-based incentive to do so. |
Biggest surprise
An insightful moment within our project was a piece of feedback we received from our judges - the idea of incorporating metrics about gallons of water or CO2 emissions, for those who had sustainability based dietary restrictions. This could also encourage people with dietary restrictions based on other reasons to learn about food and the environment. How we performed together Team Yummy worked together very well! We all have different strengths, and brought different skills to the table. We divided up the assignments throughout the quarter based on the skills of each team member. We spent a lot of time challenging each other, and working through problems, but because of this we believe our design decisions were pretty well thought out. |