Role: Designer & UX Researcher
Team: 2 designers, 3 iOS developers
Project Duration: 5 weeks
Designing Eatery’s Map View
Eatery is an iOS app developed by the Cornell App Development project team funded by Cornell’s Computer Science Department. The app helps students easily look up on-campus dining hall and cafe menus. Prior to Eatery’s adoption, students relied on tediously visiting each campus eatery’s website for menu information.
With Eatery’s 2.0 update planned for the end of the semester, I was given the task of designing a map feature for the app.
Understanding the User — Does a Need Exist?
Before beginning the project, I organized a brief meeting with the PM to discuss the motivation behind a map feature. The PM said the CS department requested an update by the end of the semester and he felt a map was very common amongst similar apps.
This explanation, however, failed to reveal if the implementation of a map view would solve a real problem for our users. Thus, I determined user research was necessary moving forward.
Who Is Our User?
In order to design for the user, I had to first determine who our main user was. With no collected data on the class year of our users, I turned to activity trends and additional resources and determined first-year students were our primary users based on the following:
- Cornell advertised Eatery to freshmen during orientation which resulted in a huge increase in user activity (green portion).
- The level of sustained user activity post-orientation (red line) remained significantly higher than that of last semester (blue line).
- 24 of the 29 research survey responses were from first year students.
Key Research Findings
To better understand our users, another designer on Eatery, Sara, and I released a survey to Cornell students. Survey results can be found here.
We found the following:
- Most users use the Eatery app when they are hungry.
- Users went through similar thought processes when navigating the app:
3. Most users go back to the same places they eat out of convenience.
However, when prompted, students expressed they were interested in eating elsewhere but the main problem was that they were unaware of what other eateries existed along their daily commute.
The People Problem
Students want to find new places to eat, but they have a hard time doing so because it requires extra effort to go outside of their normal, comfortable habits.
Objective — Design a solution that reduces the work and effort necessary to discover new eateries that fit a user’s needs.
Exploring Map View Benefits
Conducting some market research, I looked to apps like Yelp, Foursquare, and even Google Maps to see what benefits a map view would provide.
Spacial/Directional Awareness — Research on Eatery’s user flow showed that students care about what is open and nearby before they even consider menu options. A map view of eateries has the advantage of representing this information visually which provides spacial awareness that can combine with their own knowledge about the terrain to help make better judgements.
Convenient Discoverability — A map view provides the opportunity to discover new eateries along a user’s usual route. This is significant because it promises the least inconvenience by allowing the user to deviate from their usual schedule as little as possible. This reduces the effort required to try a new eatery nearby, thus increasing the likelihood of said event.
Learning New Environments — A map not only helps freshmen learn their way around campus, but it can also help all students when classes change each semester. Changes in classes often means changes in their route that may bring users to unfamiliar areas, prompting their need for information about surrounding eateries.
Exploring User Flows via Personas
Meet Jeffery:
Exploration Notes:
- The map view is supposed to help users choose where they want to eat from eateries nearby. Flow A is flawed because users are forced to pick an eatery first before they see spatially related information.
- Getting directions should be the last step after users make their selection.
Revisiting Jeffery’s User Flow
User Flow B resolves the previous issue with Flow A by providing access to the map view from the home page. This allows users to leverage the map view without having to “commit” to an eatery first.
Meet Tina and Samantha:
[Tina] has very little time to eat and knows she wants to go to a cafe. As such, she opens the app, enters the map view, and selects a set of filters that matches her needs. After clicking an eatery pin for more info, the rest of the flow remains the same.
[Samantha] is planning to meet with a friend for lunch. Her friend tells her the name of where they’re going. Unfamiliar with the eatery’s location, she enters the name into the search bar and the map shifts to the eatery with the pin already selected. The rest of the flow remains the same.
Exploration Notes:
- Preview pop-up cards avoid tedious back-and-forth screen changes between the map and eatery menu pages.
- Filters speed up the searching process by reducing options to those that fit the user’s specific needs.
- Search bar reduces time spent navigating the map manually when users already have a planned destination in mind.
Choosing a User Flow to Pursue
Combining the insights from exploring different user flows with the general user flow derived from user research, I chose to focus on User Flow B as it represented the most logical, fundamental flow:
The Current Eatery App
Transition to a Bottom Navigation Bar
With “Sort” and “Guide” occupying the top corners and with the anticipation of new features including a Debit Balance, it became clear more real estate for navigation was needed. A tab bar seemed the most effective as it:
- Provides adequate room to reorganize the layout of current features.
- Allows room for new features in the future.
Guide vs. Map View Placement
Guide’s Tab Bar Placement — I chose to move Guide from the top right corner to the bottom tab bar because its function was significantly different and independent from other features. This was not the case for Map View.
Map View’s Corner Placement — With the tab bar reserved for independent features, I decided to place Map View on the top right corner within the Eatery tab because it offered a visual representation of the same information found in the default list view. Additionally, by placing map view in the corner, users can swap between map and list views with minimal effort.
Confirming User Flow is Sound
After exploring different user flows and changes to the current homepage layout, I sought to confirm that my decisions thus far would yield a workable user experience. Designing the mock up above of the general user flow showed that it was logically sound, but also revealed areas that needed to be worked on further.
Simplifying the Preview Card
1. Removing the Image
After consulting with other CUAppDev designers, I presumed an eatery’s interior/exterior appearance was not a top deciding factor for users. By removing the image, more attention is be drawn to more important details.
2. Keeping it Simple
Card 1b was chosen as it best served the purpose of a preview — displaying priority information. Nothing more, nothing less.
Blue buttons were dismissed as they drew too much attention towards info of equal (menu) or lesser importance (directions) relative to preview details.
3. Context Guides Intuition
Columns 2 and 3 were explored because I was initially worried that users would not realize the card was clickable. However, I quickly realized that within the app experience it’s clear these cards are something you interact with.
Eatery helps students find a place to eat. Students prioritize what is open, nearby, and has desirable menu options (in that order). With that in mind, it makes sense that a user would click the preview card as it follows a logical sequence:
- Users enter map view to see what is open and nearby.
- Finding a promising eatery, they click the pin in hopes of more info.
- Already having their focus on the card, users would presumably tap the card to try to access a menu, the next piece of information they’d want.
Finalizing the Product for Eatery 2.0 Launch
Closed Eateries Shown by Default
When considering the default map view, I contemplated whether to show or hide closed eateries. To make my decision, I referred back to the problem statement which highlights the goal of improving discoverability for users. With that in mind, I decided to display closed eateries by default to provide users with awareness of all existing eateries around them. This minimizes the chances of overlooking a favorable eatery that’s closed at the moment.
Reflections and Future Considerations
Revisiting Map Traversal
At the time of Eatery’s 2.0 release, the only ways to traverse the map view are manually dragging the map around or jumping to a specific eatery via search. It would be great to implement a way to hop between campuses quickly. Some ideas include:
- Being able to type in a campus into the search bar.
- Adding navigation buttons that behave like “Re-center” that bring you to the campus.
- Shifting the map when a user selects a campus filter. (May cause issues when a user selects multiple campuses. Requires further exploration)
Exploring Other Non-Map Solutions
Due to the time sensitivity of my situation and eagerness to push out a Map View feature by the PM, I had to deviate from my usual design process. In doing so, I was unable to invest necessary resources into ideating solutions and instead worked on supporting an assigned solution.
Fortunately, the map view had many benefits in play that supported its design. If I were to do it again, however, I would make sure I spent adequate time exploring other solutions and consider their tradeoffs before settling on any one particular idea.
