Research / Competitor Analysis / Design
Taco Hell
Tackling the accessibility challenge of dietary preferences within food ordering apps
In order to formalize some of my design education, I sought to complete courses in the Google UX Design Certificate program. The first project that students are presented with comes from a prompt generator. For me, that resulted in this prompt:
First things first, I started off with some user research. Having a lot of experience with food ordering apps (much to the chagrin of my wallet), I had an idea of where to start. As a pretty-much-vegetarian, I had an assumption that dietary preferences would rise up to be a large problem to be tackled.
First things first, I started off with some user research. Having a lot of experience with food ordering apps (much to the chagrin of my wallet), I had an idea of where to start. I first started by setting some goals and identifying target participants.
The goals of this research were:
I started off by conducting 5 interviews with participants that fit the desired characteristics:
Each interview was 10-20 minutes in length, and was guided by a set of 15 open-ended questions. Participants were recorded to allow me to focus on digging deeper into the interview, rather than being focused on note-taking.
After reviewing the transcripts of the interviews, three pain points rose above all others:
Menu items are rarely inclusive of dietary considerations, forcing the user to manually make customizations. Saving customizations for the next order is a must, but the app can also accommodate dietary restrictions up front by restricting or recreating the menu.
A major frustration lies in getting an incorrect order, especially when there shouldn’t be any miscommunication between the app and the worker. The app can recognize the potential of this problem, and provide options to give feedback on an order, and to potentially process refunds.
Obfuscated nutrition information is a common trend, which limits users abilities to make health-conscious decisions. The app must make relevant and desired nutrition info (like macros), easily accessible.
Following the structure outlined by Google, I developed a user persona focused on the interviewee that drove the first discovered pain point: someone with a dietary restriction, in this case, a preferential choice to be a vegan.
"I want everything I see to be vegan. I want more veggies. I want more peppers. I want some zucchini. This seems like a reasonable ask!"
Continuing with the outlined design process, a user journey map was developed. This describes the user’s experience of ordering, starting with selecting the restaurant and all the way through picking up the food and eating it. Task lists were developed for each main action, as were adjectives for the user’s feelings, and identified opportunities for improvements. The below chart summarizes the result of the user journey for Alice, the vegan.
As a vegetarian myself, I had an assumption that chosen dietary preferences would be a concern. This was validated during the interviews, but I failed to consider life-or-death dietary considerations such as allergies, which I now recognize as just as important. It surprises me greatly that other apps don’t have a way of eliminating menu items that contain allergens.
I expected a greater number of grievances about the food customization process inherent in most other food-ordering apps, but individuals were generally happy with the function of these apps; most of the concerns were reserved to the actual fulfillment of these customized orders. To focus the project a little bit more, I decided to design for the accessibility problem around food ordering apps not supporting different dietary restrictions.
There’s a tremendous amount of food-ordering apps out there: individual restaurants have them (certainly for most national chains) as do order and delivery apps like DoorDash. I wanted to focus on how these leading apps tackle this accessibility problem, while also absorbing their general user experience such as menu display, customization options, and paying.
I targeted 5 companies for this research, the results of which you can check out in this Google Sheet. I tried to get some variability across different competitor categories, as well as for different types of food. I followed the methodology outlined by Google, which first involved making some first impressions before diving deep into other features.
First and foremost, it’s apparent that there are a ridiculous amount of ways to do menus and customization. They all generally work pretty well, but some stand out as much better. I appreciated apps that didn’t hide customization options behind multiple clicks. It was best when they were put front-and-center. Gesture selection also worked well when used. The payment and final submission process were all pretty standard, but the best option was always making Apple/Google Pay very clear.
Desktop and mobile experiences have a tendency to be inconsistent, but for the most part, the mobile experiences are much better. This makes sense to me; I’m guessing most individuals order food while on-the-go or while sitting on the couch with their phone.
When it came to the accessibility problem of different dietary restrictions, most apps were just hot garbage: no way to eliminate options, no clear indication up-front what allergens were included, etc. Two of them, however, did try to address the issue: the two most health-focused fast-casual chains, Chipotle and CAVA.
Chipotle allows for individuals to set nutrition preferences in their profile or in the menu via a small icon in the top-right. A user is able to select a single option for the ‘Plant Based’ and ‘Lifestyle’ category, while the ‘I’m Avoiding’ allows you to select multiple options. This is all pretty clear and straightforward. These selections cause the app to display a badge when customizing food. A slightly confusing aspect of these badges is that some are affirming, and others display as an alert. It’s an interesting mix. You can still select the food even if it’s against your dietary preference.
Like Chipotle, CAVA allows individuals to set nutrition profiles in their profile or via an icon in the top-right while ordering. (I’m not sure who came up with this pattern first, but I’d bet one of them was inspired by the other). Dietary preference options are limited to ingredient allergies, and there are more than Chipotle. The app does not provide selections for lifestyle preferences. Ingredients are then flagged with a little alert badge, but a user can still select them.
When it comes to the accessibility problem, most apps do a ridiculously bad job. With some of these being billion dollar companies, I’m really surprised. If it weren’t for my customer research, I wouldn’t suspect dietary preferences as an issue, just based upon the prevalence of the solution. While both Chipotle and CAVA attempted to address the issue, I don’t know that they quite hit the mark. There are some definite limitations to both of their processes.
There’s room for more research into this subject. Do apps need to present different user profiles (e.g., parent/child) for ordering on the same app? Do apps need to restrict users from selecting options that they’re avoiding? Do apps even need to display ingredients that the user is avoiding?
I’ve walked away from this research being skeptical of how apps tackle the dietary preferences issue. Seeing the variety in menu and customization, all of which generally work pretty well, it made sense to focus all design work on tackling this accessibility problem.
I’ll be the first to admit that I suffer from the desire to jump right into high-fidelity designs. This also results in me suffering from pixel-perfection, so I’ve grown to fight my natural inclinations and force myself to slow down with some good ole wireframes. In terms of medium, I'm partial to whiteboards. I like to think on big surfaces.
In order to ground myself for deciding the information architecture, as well as focus my further work, I first wireframed the general layout of the menu, tied with navigation elements. There is a lot of inspiration to be drawn from here. But as I learned from customer research, nobody ever complained about the flow of these apps. Anything would do as long as it makes it clear where the users have to go.
While many things have acceptable solutions (tab navigation, rewards, in-person QR code scanning, etc.), the nutrition preferences input is most challenging. You want to make it crystal clear to the user that this something you can control. Obviously it makes it sense to put it in under the hierarchy of 'Account Settings', but where do you put it in the ordering experience? We know that both Chipotle and Cava make it visible on the screen via a small menu button. That's an elegant de-emphasized solution, and one I ultimately chose to go with. I did also explore using chips, which provides an easily modifiable experience. But typically you're not going to change these settings unless you hand your phone to another person to order.
One thing that isn't inherently apparent in these wireframes is the result of having your dietary preferences set. That's because this app will remove food items that don't fit your settings. There are no accidental clicks of an excluded item. There are no badges or alerts. If your preferences are set, then they're set, and we're only going to show you what exists. If you want your menu to show those items, you need to change your preferences.
Next up, what does the menu look like for controlling these dietary preferences? Should the layout break out different categories of preferences? Should the actions be selects? Should they be chips? Should they be inputs? These wireframes tried to come up with different solutions, while also exploring the navigation elements to enter and exit the menu.
I like reflecting on the results with these three categories; it provides a nice structure to work from when deciding what elements to pull in.
Next, I took my takeaways from reviewing the hand wireframes to create a cleaner, digital wireframe that was inclusive of all the things I wanted and didn't include all the things I didn't want.
On a surface level, it looks like there's a lot of explainer text; this is intentional. I feel it's important that there be detail because any confusion could result in a bad experience, or even worse, extreme bodily harm.
I decided to simplify the experience and avoid preference-specific icons. The selection text feels more than sufficient.
The end-result is a kind of hybrid of both Chipotle and CAVA's preferences menu. I think this plays to the strength of each and forms a good foundation for high-fidelity designs.
While this project is not inclusive of the entire app-experience, I thought it important to explicitly lay out the information architecture as an exercise. Food ordering apps all do this a little differently, and I wanted to try capture my vision of the cleanest experience possible. The below diagram shows the resulting structure.
When trying to build a brand for this project, I thought about food trucks present themselves. Typically, they use bold colors, catchy names, and buzzworthy taglines. Often times, their presentation is tongue-in-cheek. I brainstormed on several ideas, but I ended up on a brand that poked fun at the leading taco fast food chain. I present:
As this logo makes clear, I am not a visual designer. With no real Illustrator or Photoshop skills, I slapped this bad boy together using Figma. For the purposes of this project, I think it's adequate. If I were really to explore this as a brand, I would want a mascot of some sort, a devil, or maybe even an evil taco. I think the name does a great job at poking at Taco Bell, a competitor which barely considers dietary preferences in their app. It's also clear to the customer what this food truck serves. Nobody would expect a burger here. I'm looking at you Del Taco.
I wanted the typography to be fun, so I did a look up of fonts that were spooky, Halloween-esque, and creepy. I definitely wanted to avoid typefaces that were gore-y or gross. This is a truck that serves food after all! After my search I settled on Trattatello. This typeface is limited in its application because it doesn't have different weights available. For that reason, Trattatello would only be used for the main logo, marketing, and selective in-app headings. I considered using mixed case, but settled on uppercase as the letter-l looked horribly out-of-place, especially with two of them in the name. See below.
I needed to select another font, one that would be more versatile and easier to read. I ended up on the tried and true Roboto. Taken together, a very simple typography hierarchy was established.
I love dark mode, and I've never had an opportunity to design a dark mode app, so that's what I did here! For the colors of the elements, I knew I wanted the primary to be a shade of red. It's fiery. It's powerful. It's passionate. Red doesn't lie. Red exists to make you do something. But importantly, I wanted a red that was easy to read, but also didn't feel like an error state. The end result is three shades of red, that lean pretty close to pink. I still think it looks a little evil.
These shades of red would be used in navigation elements and calls-to-action. I tried using it as active states, but it really just felt like an error state. To compliment red, I wanted to pick another powerful color. I chose purple. I think they just look good together. Purple would be used for active states, buttons, and for descriptive elements.
So what would be used for error states? I decided on green.
Wait, but that's backwards.
Yeah, it is. 😈
Alerts are supposed to be red!
Too bad. 😈
In the world of Taco Hell, problems are indicated with an oozy, slimey green. It's a perfect indication that something is wrong, and a good representation of this being a brand that does thing differently. But, just so there isn't any confusion, errors will always be accompanied by a little icon.
The background is a lovely form of dark grey (spooky), rather than pitch black (intimidating). Text would be represented as white and lighter shades of grey.
I do all of my design work in Figma, which makes designing these screens a zippy process. I created custom components, but followed Material Design guidelines as well as my own small style guide. Small tweaks were made to typography and color usage as they were called for. I focused on three main screens: home, the full menu, and dietary preferences.
Home is the first screen the user sees when opening the app. It provides clear navigation to other elements, and allows for some marketing opportunities. Dedicated customers are given the ability to repeat a recent order or grab their favorite items. The user account, location, and cart are always visible on the screen; allowing these users to make changes on their own.
The full menu screen highlights the categories available to the user, and presents the menu items for that category. Included in every section is a "Build your own" box, allowing users to make their own custom creations. As discussed in wireframing, the button to go to the preferences screen is always visible.
The dietary preferences screen is incredibly simple and is heavily inspired by the good competitors, both in terms of verbiage and categorization. I feel this screen hits the best qualities of both Chipotle and CAVA. Selects are super visible, and there's no doubt in the user's mind what has been selected. The bottom 'Save' button means the user doesn't have to do the dreadful reach to the top-right corner of the screen to keep their preferences. It is not clear here, but this app would also accept gestures for navigation (e.g., swiping out of the preferences menu).
Wanting to capture the interactions for usability testing, I created a simple prototype in Figma. Basic animations are built in to show how the screens interact with each other. I have embedded this prototype as well as an updated one post-feedback (shhh, don't look right now).
The user first starts on the home screen, where they navigate to the menu to choose some items. Here, they see items that don't fit their dietary preferences, so they go to that menu.
The user selects 'Vegetarian' first, and returns to find the menu of items has changed. They then go back to the preferences menu and select 'Vegan'. Because these two lifestyles are mutually-exclusive, it removes the 'Vegetarian' selection. Then they decide to avoid 'Gluten', so they select. Upon returning to the menu again, they see only options that are appropriate for vegans and those avoiding gluten.
To test this prototype, I went back to some of my interviewees from the conducted research, as well as some new people who haven't been involved in this project. I wanted feedback from both so that I could see if I solved the problem, but also make sure my proposed solution did not create confusion. I ended up showing this prototype to three people in-person (where it was demoed via the Figma mirroring app), and also to two people virtually whom I just sent the prototype link.
Overall, feedback was very positive! Users appreciated the ability to outright remove items they didn't want, and thought the user interface was clear. The constant presence of the button to get to preferences was also appreciated.
I did receive some negative feedback of the Dietary Preferences menu. Users thought it was confusing that 'Lifestyle' selections did not eliminate the ingredients in 'I'm avoiding' that would surely be eliminated. For example, if they select 'Vegan', they want feedback that they're not going to be getting any meat, dairy, or eggs.
Additionally, I was told by three people that they would expect to set up these preferences in sign-up. I agree, but the sign-up flow wasn't included in the demo. I'll be sure to keep that in-scope if this project gets more developed.
One of the new people I interviewed was a parent, and a parent of a child with a specific food allergy. They said their child is advanced enough with smartphones to be able to make their own menu selections when handed the parents' smartphone. Because of this, this user wanted to be able to temporarily deactivate their preferences, so separate preferences could be entered for their child. I don't know that this is the most elegant solution; I think something like a profile swap would be better.
I decided to tackle the negative feedback in the Dietary Preferences menu, as this was the main aspect of the solution. I implemented a fix where selecting a certain 'Lifestyle' would automatically select the 'I'm avoiding' options that applied. I added a new variant to the component, which dulled the color of the text and icon, and also changed the icon to a square. These two things together provide subtle feedback to the user that these items will be avoided because of their lifestyle.
Now that an individual avoidance preference was locked, I wanted to provide feedback to the user that they couldn't remove that preference without first changing their lifestyle. You wouldn't want someone to have an accidental click that violated their lifestyle selection. To do this, I created an additional variant that darkened the background color, changed the icon and text to the green error color, and also added a stroke in the error color. This was also paired with popping an alert explaining why it was locked.
I neglected to implement other pieces of feedback for this project, but nonetheless, there are still opportunities for feedback. If you want to play around with this new Dietary Preferences menu, go ahead and revisit the embedded Figma prototype above: it is a separate flow.
This was a personally fulfilling project for me: as someone who eats vegetarian, I have often been dissatisfied by the functionality of food ordering apps. I was thrilled to see my opinions validated through legitimate customer research. It was a lot of fun getting to develop this solution and work through the formal design process at every step. I have plenty of thoughts on how to enhance the food ordering experience, and there were so many aspects of this that I didn't get to touch, such as food customization, ordering and payment, and the sign-up process. Focusing on the accessibility problem allowed me to really dig into what needed fixing.
At the end of the day, I'm pleased with this project. I truthfully find the solution better than the others researched on the market.
Sorry Chipotle and CAVA. 😈