Backstory: Once upon a time, there were three students - Vikki, Vishnu and Grace who had dietary restrictions and faced a hard time finding restaurants with options that accommodated their dietary needs.

Impact: Help students with dietary restrictions become informed about nearby restaurants that accommodate their dietary needs, and choose the best one based on a match score

My Role: UX Research, UX Design, Prototyping

Timeline: August 2017 - December 2017 as Class Project at Georgia Tech

Team Members: Ishaani | Agrim Chandra | Brianna Pritchett | Hue Watson

Impact: Help students with dietary restrictions become informed about nearby restaurants that accommodate their dietary needs, and choose the best one based on a match score

My Role: UX Research, UX Design, Prototyping

Timeline: August 2017 - December 2017

Team Members: Ishaani | Agrim Chandra | Brianna Pritchett | Hue Watson




  • Match score based on personalized dietary restriction
  • Map based search and restaurant filtering
  • Customized Menu display with substitutions possible for dishes
  • Customized reviews display

My Role

  • Performed few of the contextual inquiries and conducted interview sessions
  • Responsible for creating the survey
  • Responsible for creating sketches and then wireframes in Mockups
  • Created mid-fidelity screens in Sketch
  • Created interactive prototype in Invision
  • Created evaluation plan
  • Conducted evaluation sessions at various stages of the projects
  • Created project website

Go to top of this section


Figure: Different methods used at various stages of the project - clockwise
Following figure shows different methods used at different stages of the project. The stages are divided based on their focus. Initially, the focus was to understand what the goals of our product should be, which depended heavily on user research and analysis. Once, we determined the goals of the product, we shifted our focus on features which could accomplish those goals. This included the ideation, brainstorming and evaluation phase of the project.

Go to top of this section


What their restrictions meant to them and how they influenced their process of eating at the restaurant?

Our first aim was to understand the problems students like Vikki, Vishnu and Grace faced while deciding which dish to eat at a restaurant. But that is not how we started. Our initial goal was to understand issues students face while grocery shopping but our research led us to pivot to a more pressing need - inability to find restaurants to accommodate their dietary restrictions.
Figure: Pivoting Aim of the project

Research Questions

Initial Research Questions

At this point, the aim of the project was to Understand issues faced by students while grocery shopping.
What role does “experience” with the dietary restriction play in their process?
What is the user’s process purchasing groceries?
How do their experiences in different cities influence the current purchasing process?

Modified Research Questions

However, initial research using unstructured interviews and observations, led us to modify the aim of the project to Understand issues faced by students while eating at a restaurant.
What role does “experience” with the dietary restriction play in their process?
What is user’s process while deciding on a meal to eat out?
What kind of influence do outside factors play in their decision making process?

User Participation

Contextual Inquiries
Survey Respondents

Figure: Research artifacts - Menu, Dietary restriction Pamphlets and Stacked Racks of Food (left to right). Image of the menu shows that there are no visual cues to know if a certain food item fits the dietary restriction. The image of Pamphlets is from a Publix store however the third image shows that cues used to differentiate dietary restrictions haven't been used anywhere.

Go to top of this section


What problems did students face?

In this phase, we transformed our research into user needs, behaviors and pain points. We found user needs through affinity mapping and task analysis and identified user pain points. These needs saw a few emerging behaviors amongst users, which were represented using Personas. These behaviors were categorized into groups of Vikkis, Vishnus and Graces. We then generated storyboards and empathy maps to aid design decisions.

Identification of User Pain Points

We discovered user needs through affinity mapping and task analysis.
Issues understanding different ingredients due to unfamiliarity or scientific terms being used
Unknown nutritional values for various food items
Social stigma faced due to feeling of being looked down upon because of dietary restriction
Language barrier due to environmental factors like noise or difficulty with the language
Travel long distances because users don't have enough information about menu items of nearby restaurants

Figure: Affinity Diagram
Figure: Task Analysis

Representation of User Behavior

Through careful analysis of our research, we identified behaviorial differences between users. These differences were mainly based on age, familiarity of the area, language barriers, reasons for having dietary restrictions, time since dietary restriction and their goals.

These personas went through different emotional journey through their process of ordering food which we represented using empathy maps. Empathy maps helped us set expectations within the team and a final emotional state that we wanted to aim.

Figure: Personas

Figure: Empathy Maps

Go to top of this section


How could their problems be solved?

Once, we discovered user pain points, we conducted informed brainstorming session to come up with various ideas.

Figure: Brainstorming Session
Figure: Idea Organization Map

Ideas were organized on a 2D map and were rated based on how well these designs matched the criteria set forth in our affinity diagram and usability criteria – low cost, discreet, responsive and quick to use, and clearly able to label ingredients (and how creative we thought they were). After going through this process, we picked three ideas with the highest ratings – “QR”, “AR”, and “kiosk”.

Idea 1: QR APP

Idea 2: AR APP

Idea 3: Kiosk


We created storyboards to fit these three ideas in different context as per our personas. This helped us validate that our ideas were relevant to the personas and helped us communicate our ideas across to the users to get feedback on these three ideas.

Figure: Storyboards - Grace, Vishnu, Vikki from left to right


To decide on which idea to go by, we conducted feedback sessions to understand
  • Pros and cons of each idea to explore the opportunity to get feature-level feedback to combine ideas later on
  • Willingness of the user to create a profile on the app and provide personal information
  • Any scenario in which user's naturally thought of using this app to cover use cases, the team might have missed

In-Person Moderated Users
Remote Moderated Users


Users wanted fine-grained distinction about their dietary restriction as being a vegetarian meant different things to different users
Neutral to negative about creating profile. Users didn't want to share their personal details in order to use the app
People bring a lot of expectations from Yelp. Users wanted reviews to be on our app and said they would visit Yelp to look at reviews since our app didn't have any

Negative feelings towards using QR. Users felt that it was an overhead to use QR code
Hesitant about using AR. Users said that they weren't comfortable using AR functionality in public
Users imagine using it in a group setting. Users spoke about scenarios where they would use the app while going out in a group


After the feedback session, we decided to take feature level decision as we didn't want to discard features just because people did not like how the way feature was presented.

Rating notification
Refining Restrictions
Score include reviews
Score include no. of dishes
Menu Toggle
Menu Category
Menu Legends
Multiple people with restriction
Reviews for user's restriction and more
Score per menu dish item


We created mid-fidelity prototype without adding colors and asked an expert to review our system. We got two main takeaways from this session.

TAKEAWAY 1: The expert had issue understanding what the restrictions meant in the previous version. They didn't understand the sub-categories provided in the mockup on the left of the image. Hence, we decided to remove sub-levels and show the restrictions at all same heirarchial level.

TAKEAWAY 2: The expert didn't understand what the legends meant. When they opened one of the collapsed categories, they understood what the legends meant. Hence, we decided to provide more instructions to make the legend clear and have one menu category open by default.


Go to top of this section


How well does Infograin resolve their problems?

In-Person Moderated Users
Remote Moderated Users
SUS Score


"Pick a restaurant in this area where you would like to eat, keeping your dietary restriction in mind."
Scenario: You only have the maps view available to you and you cannot drill down and click on the restaurant to view their menu.
Why? We chose this task because we wanted to see what users considered when choosing a restaurant when they only had the option to look at the maps view. We were interested in how people made the decision of what restaurant to go to, independent of what was on the menu.
"Pick a dish from a given restaurant."
Scenario: You are going with a friend who does not have any dietary restriction and you need to pick a dish for them as well.
Why? In evaluating our low-fidelity prototypes for this system, we found that most users naturally envisioned using our app in situations where they were out with other people who had different dietary needs than themselves. Thus, we wanted to be sure that our app was usable in this context.


Simplify explanation accompanying the name of the dietary restriction by making use of icons and symbols
Add three legends to differentiate between compatible and incompatible dishes
Add filters within the sorting options to specify a range for sorting parameters setting

Add legend in front of menu items which do not fit dietary restriction.
Make the sort option a bit more noticeable

Go to top of this section


What were my reflections from this project?

As a UX practitioner, one cannot satisfy each and every user
During the whole design process, sometimes it can get overwhelming to cater to each and every user. It is important to keep in mind that design is always made such that it caters to the majority of the population and unless a pattern in user responses emerge, we must not obsess over user comments. Yes, we should think about the possibility of including their suggestions/responses but if those scenarios have already been backed up by data and a reason that certain features weren't included or done a certain way, then we must stick to them and revisit later if need be.
Follow up on leads found in user interviews
When we first started our research, our aim was to help students with dietary restriction find food at grocery stores. However, while interviewing few users during the initial stage, users said that they had more issues finding meals at a restaurant. As we saw a pattern emerge, we wanted to explore this area more and modified our interview questions to fit a broader scope. As it turns out, many more users had issues finding meals at restaurant which led us to pivot from our aim. This helped me remain relevant and actually solve a problem that users faced.
Sometimes an App is the best solution
When we started ideation phase, we really wanted to push more than a digital solution because but during our brainstorming sessions, it started becoming clear that given the problem space, an app ticks all the check boxes for solving various pain points. An app was the most feasible and creative solution given the technology constraint. This was even verified during the feedback session, as the one element of physical interaction that our solutions had - using QR or AR camera was also rejected by users and deemed unnecessary.
When in doubt, always refer back to the data
This was particularly helpful when we were deciding on features for the app and helped resolve a lot of conflicts before they turned ugly. Turning back to the data was also helpful as it showed us at times, that we didn't have enough data to make a claim or that we didn't cover that aspect in our feedback sessions. In these cases, we went back to the users and asked them more questions before deciding on the final features.

Go to top of this section