Eatery 2.0 (Pt. 1) — Enabling Users to Discover Eateries
Eatery is a mobile app developed by CUAppDev, a project team that makes iOS apps. The app enables students to easily find information about various eateries on Cornell’s campus. The first version was designed and released the previous year. Prior to Eatery, students had to tediously click through each campus eatery’s website for information. You can view Eatery on the app store here.
How can the current Eatery app be improved to meet user needs?
Who Are We Designing For?
In order to design for our users, we had to first figure out who they were. Because we initially had no data collected on our users, we turned to activity trends and other resources. We determined that our primary users were first-year students with the following:
- Cornell advertised Eatery to incoming freshmen, resulting in the spike in user activity during orientation.
- 82% of user surveys were first year students.
Understanding the User
In order to understand how our users currently use the app and what problems exist, me and the other designer, Jon, surveyed Cornell students.
→ You can view the questions here and the results here.
Key Findings
- Students usually use the app when they are ready to eat. They seldom care about payment type. (BRBs, swipes, cash) We determined the current flow to be:
- Eatery was mainly being used to look up a menu for an eatery they have in mind. They rarely browse through or use sort, search, or favorites — many just keep scrolling until they find what they want instead.
- Many tend to go to the same places out of convenience. However, students were interested in going to new eateries but are unaware of where other eateries existed.
With our findings, we identified a few personas we would be designing for:
- Main: Freshmen who are new to Cornell and do not yet know campus or what eateries exist where.
- Secondary: Busy students who want to find a close place to grab food when they are ready to eat.
- Secondary: Students who know the campus, but always eat at the same eateries and want to go to new ones / narrow down their choices.
The Overarching Problem
After getting to know our users and analyzing the current Eatery screens, we realized that people were having difficulty quickly finding eateries that are convenient and match their specifications. I narrowed our problem to:
How can we improve Eatery so that people can discover eateries that match their criteria and quickly narrow down their choices?
Identifying Problems and Exploring Features
With what we found out about our users, we needed to determine what features to keep, create, or get rid of as well as rework the flow and navigation.
I started by printing out the existing existing flow to identify shortcomings.
Addition of the balance feature
Currently, checking how much you have left in your meal plan is hassle. Enabling users to easily check their meal plan balance would give Eatery the potential to expand user activity and engagement.
Keeping the Guide feature
We debated over the need for the Guide feature. Its main purpose was to look at menus of only dining halls in one place for the week, when users can look at all campus eatery menus on the Eateries page. However, I ultimately decided to keep it because it enabled users to quickly compare different dining hall menus, We changed “Guide” to say “Menu” instead to be more clear.
The need to improve cells, sort, search, eatery pages, and map
User research and analysis of current screens indicated that there was much opportunity to improve existing pages and features.
→ Each feature is explained in-depth in separate sections below.
Additionally, I discovered that the current Eatery user flow pushed users to already have an eatery in mind, and was mainly used to look up menus / check if an eatery was open or not. For 2.o we wanted to improve existing features and promote discovery.
Redesigning Sort
Exploring wording, symbols, and sort pages
Before we did our research, I had started some quick explorations on different ways to improve the existing sort feature and ways users could tell if their feed was sorted or not.
This included changing the wording, putting symbols for indication, and making the sort options visible at all times. In all three options, users could see how their feed was currently sorted.
Then, I tried making each page look different according to each sort option. This included different pill buttons to reduce scrolling and putting the map at the top to visualize proximity. I wanted users to be able to get to the information they want faster be able to tell how the feed was sorted
The problem
After we conducted our user research, we found that sort had the following problems:
- Most users were just scrolling until they reached the eatery they were looking for.
- Few were utilizing sort to find eateries that fit what they were looking for more easily.
- Users reported once they sorted, they didn’t know what they had sorted by or if their feed was already sorted.
How can we enable users to find eateries that fit their criteria?
With the user research, I realized that I had initially taken the wrong approach. However, two of the quick explorations I had done led me to realize that replacing sort entirely with filters would be a better alternative.
Both explorations enabled the user to quickly see all available options and select the one option they want. However, since our ultimate goal is to enable users to discover eateries that match their criteria, it would be useful to let users select the criteria they want and see what shows up.
I also noticed the current sort options were not very helpful because:
- Users don’t care about payment type and this sort option was seldom used.
- “Alphabetical” would only be useful if the user had a particular eatery in mind, and all the other sort options beside nearest were sorted alphabetically anyway.
- “Nearest” was also divided by whether it was open and closed, making “Open & Closed” repetitive.
Converting sort into filters
Before converting the sort function into filters, I first looked to apps such as Yelp and NYT Cooking to see how they used filters. In both apps, filters made it easy to discover restaurants and recipes with the criteria I had in mind.
Then I broke down the existing sort options of “alphabetical, campus, nearest, open now, and payment type” into filters consisting of “open now, nearest, north, west, central, swipes, cash, BRBs”.
I debated showing all filters, so users can see all options at once but knew all filter options were not equally as important. I chose to make the filters fit on one line and scrollable, and ordered them from most important to least (Is it open? → proximity / location, → payment type).
I also decided not to put the “filter by” text, as we found that users knew the options were filters from user testing and feedback.
Getting rid of unnecessary filters
- Alphabetical —Alphabetical order was not necessary, as it would only be used if the user had an eatery in mind.
- Open now — Because users usually look for eateries when they are ready to eat, the feed would already be divided into open and closed — making this filter unnecessary.
- Nearest — The feed would be ordered by proximity since users look for eateries near them, eliminating the need for this filter. Additionally, this would not make sense when switching to the map view.
This leaves “north, west, central, swipes, and BRBs”.
Refining filter appearance
I wanted to make it clear to the users that the filters were tappable and which filters were selected.
Feedback from users and other designers showed that option A looked the most tappable.
Scrolling behavior
When users scroll down, I chose to have the filters slide up and instead show text saying “filtered by filter, filter, filter”. I wanted to put more emphasis on the content when browsing, and users would still be able to see how their feed was filtered.
Once users start scrolling up again, the filters would reappear. Even if users assumed the filters were at the very top and started scrolling to the top, the filters would quickly appear again.
Final sort/filter design
The “sort” function was replaced with filters so users can discover eateries that fit their parameters.
Filters made the function more visible, and instead of sorting the order the eateries appeared in (alphabetically, by campus, etc.), users can look for eateries that fit their criteria appear. Additionally, users can clearly see how their feed is filtered.
Current User Activity
