Infograin
Helping students with dietary restrictions make more informed meal decisions
Project overview
Team: Brianna Pritchett, Ishaani, Hue Watson, Agrim Chandra
Honors: Finalist, Convergence Innovation Competition
Challenge: Our goal was to build a cheap, flexible, and subtle solution for people with dietary restrictions, to simplify their experience at a restaurant.
Project video
My roles
I was the go-to researcher, ensuring that research was being conducted well, particularly during needs analysis and evaluation. More specifically, I:
-
Conducted and wrote up competitive analysis
-
Conducted 2 open-ended interviews during needs-analysis and 2 feedback sessions during ideation
-
Reviewed and edited questions for each questionnaire, interview, and survey
-
Coded open-ended responses to online survey and final evaluation
-
Wrote 2 of the 4 project milestones, both of which received 100% from the TA
-
Created screen sketches during ideation
-
Created screen mockups in Sketch during prototyping
-
Contributed to all group discussions and activities throughout project
Wants & Needs
The question that we started with was: how can we improve the grocery shopping experience for people with dietary restrictions? We were inspired by friends, particularly those who were new to their dietary restriction or new to America, who were having difficulty reading labels in the grocery store and finding what worked for them. However, our initial findings led us to something interesting: after an initial discovery period, people often fall into a routine at the grocery store. What we thought was the main problem was actually secondary to another problem our interviewees brought up.
For me the issue is not so much in the grocery store, but when I’m eating out/away from home. Vending machines? Fast food? Most restaurants? (On campus food?) I have to be really careful with all of those.
At this point we generalized our research to include restaurants, in the interest of finding the biggest need. For the rest of the needs-gathering process, we generalized the question to: how can we help people with dietary restrictions make more informed meal decisions? To find this, we performed a few different research methods.
Observations
Observed people in the gluten-free section of a grocery store
Paper questionnaires
Sent out 7 paper questionnaires with open-ended questions about shopping habits.
Contextual inquiries
Performed contextual inquiries with 4 students - 3 while grocery shopping, 1 while at a restaurant
Interviews
Conducted 3 in-person semi-structured interviews on shopping habits
Competitive analysis
Analyzed existing shopping and restaurant apps for people with dietary restrictions
Online survey
Received 40 responses to Qualtrics survey on food choices
Icons made by Freepik from www.flaticon.com, licensed by CC 3.0 BY
Analysis
With this data, we moved on to analysis, focusing on finding user wants and needs (not thinking of solutions quite yet). Here, we created an affinity diagram and conducted task analyses. From this, we formulated five usability criteria to keep in mind during design and evaluation. Finally, we decided to focus on the restaurant context.
Cost of system
Should be low-cost to not strain student resources
Simplicity of language
For those unfamiliar with food labels
Responsive-ness
To aid quick and unobtrusive information gathering
Simplicity
To match the simplicity of the task
Substitutivity
For different dietary restrictions (vegetarian, GF, vegan)
Based on our findings, we came up with 3 personas and matching user journeys. We made sure the personas captured the variation we saw in our users, particularly in the areas of sociability, technical skills, familiarity with their restriction, and English mastery. The user journeys were based on the pain points identified during the research phase.
Ideation
Equipped with this extensive knowledge of our users, we dove in to potential solutions. We first conducted a brainstorming session to characterize the space of possible ideas, pushing beyond the obvious solutions to get as creative as possible. Then we organized these ideas along axes of feasibility and creativity to narrow our options to 3, described below.
Our three favorite options after this process were a QR app, an AR app, and a kiosk. For each idea, we worked out the basic functionality as a group, then split up and independently sketched out mockups for the app (example sketch of mine shown to the right). Then we came together and picked the best elements of each sketch, converging on one "Frankenstein" mockup for each idea. We additionally created storyboards to show use cases for these ideas. These mockups and storyboards are shown below.
From here, we conducted 6 within-subjects feedback sessions with members of our user group to figure out the good, bad, and the ugly of each design. Newly equipped with this information, we sat down as a group to decide on what features we would want the final product to have (again creating a "Frankenstein" version of our previous ideas, plus a couple features mentioned by users). The table to the left are the features we considered and whether we decided to keep them.
AR | Users (and the team) didn't see the added benefit of this feature | |
Customer reviews | Users expected this feature due to the app's similarity to Yelp | |
Filtering | Allowing people to filter by restriction serves the same basic purpose as a profile | |
Fine-grained restriction definition | People indicated that they liked defining their restriction exactly (e.g. lacto- vs. ovo-vegetarian) | |
Map | Allow users to select nearby restaurants | |
Menu with categories | Users mentioned that they'd like to be able to skim the menu based on what they're in the mood for | |
Profile | Users felt neutral-to-negative with making one | |
QR | Users and experts indicated lack of interest | |
Rating per dish | While the granularity would be nice, we didn't think it likely that people would take the time to rate each dish they ordered | |
Restaurant score | Our users loved the idea of one score that indicated how compatible a restaurant is with their restriction |
Design
As a group, we sketched out each screen, then split up to make wireframes for these screens using Sketch. We decided to have 5 basic screens (excluding dialogues): dietary restriction selection, profile (later removed), map of nearby restaurants, menu, and reviews. The sketch + wireframe for the menu is shown below.
After creating a very basic mockup, we had an expert walk through our prototype. We had them simply give their impression of what they understood from each screen. This led us to make two main changes. We expanded the top menu category by default (left), because the expert indicated that they didn't understand the legend in the absence of a visible menu item. Additionally, we removed the subcategories in the dietary restriction selection screen (right), opting instead for one row per type of vegetarianism. This made it clearer for the expert and allowed for brief descriptions of each restriction.
Below is a gallery of all of the screens that we had mocked up for the app, as they were going into evaluation.
Evaluation
Before starting evaluation, we made a few improvements to the app. First, we added restaurants and menus to accommodate any dietary restrictions our users may have. We also added restaurant sorting capabilities, because we were interested in what people look for in picking a restaurant. For the same reason, we also added review sorting capabilities. Going into evaluation, we had 117 screens, shown below.
We conducted 8 usability sessions, asking participants to use our app pick a restaurant where they'd like to eat, and separately pick a menu item from a pre-selected restaurant. All the restaurants in our app were made-up, to eliminate external factors, and they had to imagine they were additionally picking food for a friend with no restriction, because many of our users automatically imagined themselves using this app as part of a group. Below are our primary findings.
Restriction definition
-
25% of users were confused by the different definitions of vegetarianism.
-
To fix this, we can replace "do/do not" with x and check marks to clarify what makes up each restriction
Restaurant sort
-
62.5% of users resorted the restaurant list, mostly based on price.
-
Many users picked cheaper restaurants even if they weren't very compatible with their restriction
Reviews
-
Only 37.5% of users looked at reviews, wanting them instead when picking the restaurant.
-
We plan to make it clearer that reviews are tied into a restaurant's compatibility score.
Map
-
Only 50% of users found the visual map useful in picking a restaurant
-
Those who do use it would like to interact with it (panning, zooming)
Legend
-
Only 37.5% of users understood the meaning of the green and yellow dots in the menu.
-
We plan to include a red dot for items they can't eat, making clearer the traffic-light metaphor.
SUS
We received a SUS score of 80, in the 85th percentile of SUS scores
Next steps
We presented this app at the Convergence Innovation Competition and received many good suggestions for how to move forward. At this time, we do not plan on implementing this app, although if we did we would like to collaborate with an existing app (such as Yelp) to tie our new functionality into an already widely used app. Mostly, we'd like to allow people with dietary restrictions access to our restaurant score to ease their experience. I'm so grateful for the opportunity to work in such an amazing team and make such a helpful app.
