Sabor

In this case study I explain the steps that my classmate, Jake Nachlas, and I took to create a mobile app that we would call "Sabor." Sabor in Spanish translates to "taste." This is a concept that we designed to provide users with exciting, reliable restaurant recommendations from friends, family, or those who enjoy the culinary arts enough to guide others. It is a social food application that connects like-minded people and allows them to easily recommend a restaurant, get recommendations for any cuisine, and keep track of their favorite places to eat.

Project overview

We reached out to over 130 people who made it clear that they put little faith in online recommendation and review platforms. Instead, they put far more weight on recommendations from friends or family. This can be attributed to people’s lack of trust in online reviews, frustration with online review platforms from outdated information or an overload of notifications, and the high barrier to sharing a review. People with whom we spoke also indicated problems with not knowing the most reliable sources for recommendations within their social circles, but they care for shared experiences with their peers who have similar needs. On top of that people like to be able to easily access key information like proximity convenience when receiving a recommendation from anyone.

Sabor is designed to address these problems in an actionable, efficient manner. We created an experience that gives users a place to start new discussions with their community about different cuisines in any area and quickly share recommendations with low friction and maintain a location-based wishlist. Users also have a personal stake in the application by allowing them to build their catalog of restaurants in an easy-to-navigate map view.

Another way to think about this app would be to remember all of the fun parts of Yik Yak (lest we forget that Yik Yak is back). Sabor has the proximity-based social utility of Yik Yak, but without the dark, social dangers.

‍

Our process

1. We focused a lot of effort on the discovery phase of the idea beginning with interview and survey planning by creating carefully crafted questions to be able to extract useful qualitative and quantitative insight. We constructed an affinity diagram to be able to organize people’s responses into actionable problems. We then used this insight to define the “people problems," a term introduced to us by my mentor, Zack Hargett, and how we know that they are problems based on our research
2. From these “people problems,” we defined our target audience as well as our business and product goals. Lastly in the definition phase, we determined success metrics that would be used if we decided to ship Sabor.
3. We then brainstormed over existing products and solutions that our audience uses to not create parity in our project. Out of this came a feature prioritization matrix to narrow our focus on the most impactful features for our Minimum Viable Product (MVP). And to guide our development, we created user scenarios for both of our target users showing how and why they might use our app.
4. We created an initial wireframe/low fidelity prototype by implementing the features we decided had a high impact on our users. Our goal here was to meet the goals we defined earlier for Sabor.
5. We conducted usability testing on five users to help us determine our success in the low fidelity prototype and where we can improve in the high fidelity prototype.
6. With the categorized user feedback, we created the high fidelity prototype using our UI Style Guide. Our goal was to implement as many changes as we could to accommodate the feedback without adding too many features to the MVP.

‍

Discovery

Competetive analysis

We began by asking ourselves a few questions surrounding the intended field: What services are our target users already using to accomplish their goals and why? We know that some big players dominate this space, so we decided to focus on their services: Yelp, Google Maps, The Infatuation, and Foursquare. We researched online and sifted through dozens of app store reviews and summarized them into pros and cons below:

‍

Proto-persona

For more direction, Jake and I consolidated our biases and experiences to create a potential user who would guide the early stages of Sabor's creation. This "proto-persona" would be named Daniel Crenshaw, but we call him Dan. Dan is a 27 year old from Atlanta, GA who loves being social and hanging out with friends. He doesn’t consider himself a foodie, but he enjoys being the one who recommends trending activities and places. Dan sometimes has problems finding new places to try especially when he’s not in areas he is familiar with. He sometimes looks up reviews online but they aren’t very reliable and don’t really reflect his demographic or tastes. He sees cool places on his friends’ Instagram or Snapchat stories, but doesn’t know where they are. If he does find these places, he doesn’t know what to get that he knows he’ll enjoy. His goals are to find new places to try that he will enjoy and be able to keep track of places he has been to for future reference.

‍

Research plan

Using Dan as our ideal user, we formed a research plan crystalize the problems people have when it comes to food recommendation apps.

1. How do people currently go about finding a new restaurant to eat at?
2. How do they choose to eat on any particular night?
3. The last time a person tried a new restaurant, how did they discover it and decide on it?
4. How do people recommend a restaurant to others? When do they give unsolicited recommendations and when are they asked for their opinions?
5. What issues exist with current food recommendation platforms?
6. What do people feel is missing from these platforms?
7. What do other platforms do that draws people to them?

• Questions 1-4 have a purpose of getting us to understand the underlying thought process that goes into deciding on a new restaurant and sharing great restaurants with others. Our goal is to be able to incorporate this thought process into the experience that we create.
• Questions 5-7 are more targeted towards the current market. Here, we want to understand what problems exist in the current, more widely used platforms, and uncover the pros and cons of them to gauge where there is space in the market to grow.

‍

Interview

With a set of thought provoking questions that would spark insightful conversation, we conducted ten (10) interviews broken down into three parts: introduction questions, thought process questions, and current market questions. Our goal was to address the above research questions and see how people currently go about finding new restaurants and what issues they have, if any.

• The introduction questions were ice breaker questions to get an understanding of who our users were. We asked about hobbies, typical week/weekend, and how they socialize with friends.
• The thought process questions are exactly as they sound-- we had a goal of understanding the steps that people take to recommend a restaurant, receive a recommendation, and decide on a restaurant. We also hoped to understand how they use current applications/other means to find restaurants, and what was missing from their current way of doing these things.
• The current market questions expounded what current apps/websites they use and why. Here, we looked for pain points that users have, why they have them, and potential ways to work around or mitigate these issues. We also gauged the interviewees’ opinions on the credibility of existing food review websites and apps and the desire for a more community-based platform.

‍

Survey

To preface this section it may be interesting to know Jake's background in data science. During this bootcamp, Jake was in his final semester at Emory, earning a B.S. in quantitative science, so we leveraged his incredibly agile mind and powerful skillset to gain valuable quantitative insight from a survey we put together, through which we recorded 122 responses.

We used the survey to gather ideas like how often people will eat out/order in as opposed to cooking, gauge interest in trying new places to eat, determine who people find to be their most credible source of food recommendations, and discover motivations for recommending to others. The last section of the survey was fourteen (14) Likert Scale questions that asked users to rate the agreeability with statements such as “I value information from online food recommendations MORE than a friend’s recommendation” and “I think that online food recommendation sites and apps are credible and trustworthy.” We were also curious about who posted reviews, and what they considered to be important factors in curating recommendations for their peers. This survey also served as a way to understand how people judged recommendations. Below is the age distribution of the 122 survey respondents. We recognize that these age groups may not be representative of a random population, because the biggest three categories are Jake's age group, my age group, and both of our parents’ age groups.

‍

Affinity diagram

The next step was creating an affinity diagram in Miro. In doing so we wrote responses from survey and interview questions onto post it notes and grouped them by relative properties. We only included eight (8) of the interviews in the affinity diagram because two of the interviews were conducted later on to collect more information. As you can see below, there are a lot of categories that we discovered from grouping the post-its and iterating. While we decided to move to the next step because of time constraints, we were able to extract six (6) overarching user insights that we framed as our “people problems.”

‍

What are the "People-Problems?"

After much discussion and sorting Jake and I defined our users's "people problems" as the following:

1. Lack of Trust. “I do not trust random online reviews. I assign a lot more weight to friends’ reviews.”
2. Recommendation Friction. “The barrier to recommending a place is high to the point where taking action seems pointless.”
3. Who knows what? “I don’t know which friends have been where, but I still want their input.”
4. Shared Experiences. “If my friend has eaten at restaurant X but not Y, all else equal, I would choose to eat at X to have that shared experience.”
5. Spatial Awareness. “I want to know where things are. At the end of the day, it really comes down to the location of a place and its convenience.”
6. Notification Overload. “I do not like receiving so many notifications. I rarely ever respond to them and they get annoying.”

‍

How do we know that they are "People-Problems?"

Lack of Trust

1. Only 10% of survey respondents value online reviews and opinions more than friend or family recommendations.
2. Only 41% of survey respondents said that online reviews are credible or trustworthy.
3. Interviewees mentioned they want to veer away from bigger platforms because they are often fake (businesses pay people to leave positive reviews) or extremely polar--often from one bad experience.
4. Interviewees do not believe just anyone should be able to share their opinions online because they aren’t food critics. They also do not like these reviews because they come from people who more likely than not have different tastes.

Recommendation Friction

1. 80% of survey respondents will not review a restaurant online unless the experience was really bad or really good.
2. Interviewees in general said they did not post reviews because it felt too out of their way and they are lazy. Also, they felt as if their reviews “just get lost in a sea of reviews” and don’t matter.
3. People often lack a good incentive to post a review for a restaurant unless they had a really bad or really good experience.

‍

Here, you can see that for every sizable age group except for 45-64 (and 35-44, but we had far fewer data points here), more respondents have never posted a review than have. We will come back to this point when we create our two user personas.

Who knows what?

1. 96% of survey respondents said they would recommend a restaurant to a friend.
2. 98% of survey respondents said they will try a restaurant based friend or family recommendations.
3. Interviewees revealed that they were unable to triangulate their knowledge of who in their peer group has been where. Overall our participants were unsure of from whom they could get decent recommendations. There was a certain paralysis in this point in the journey.
4. The majority of survey respondents said their preferred way of finding new restaurants is through word of mouth. Keep in mind this data was pulled from a checkbox question, so that is why the total tally of responses exceeds 122.

Shared Experiences

1. People prefer recommendations from friends and family over a random person because they know their friends and family have similar tastes.
2. People like to go to places that they know other people with similar demographics and tastes will also go to.
3. People like to be able to get recommendations from people in their social circle. This allows them to relate more to the experience someone is sharing with them and trust that it might be something they will enjoy.
4. Below, you see that when people were asked about their most credible sources for recommendations over 80% said friends or family. We interpreted this as participants agreeing that experiences are more relatable when the referral is coming from someone closer in your community. Shared experiences are meant to be personal.

Spatial Awareness

1. People mentioned that location is an essential factor in deciding where to go.
2. People also want to be able to keep track of the places they go to.
3. Respondents mentioned they like to have access to a map, general price, and friends’ opinions on any particular restaurant.
4. People want to be able to compare recommended places to ones they’ve been to.

Notification Overload

1. People mentioned they do not like receiving the “did you just eat here?” or “remember to leave a review” notifications.
2. They want to be able to have a functioning app without relying on notifications. They need another incentive to engage with the app.

‍

Additional insight

The following points were not as closely related to the above, but are worth mentioning as we kept them in mind during development:

1. The first decision people often make is deciding on a cuisine. For example, “I’m craving Chinese food, where should I get it?”
2. People mentioned they would like a peer-to-peer system where they can easily and effortlessly recommend and keep track of restaurants.
3. People want to be able to organize and find restaurants by cuisine.
4. Many places are often indistinguishable from one another. People want a way to get information on the unique aspects of each to make a decision. They can do this through more personal recommendations.

‍

Definition

Target audience 1: The Trendy Millennial

The first target user is Percy Robbins, a 25 year old millennial who loves to stay up to date on the latest trends and technology.

• He likes finding new places to eat with friends using minimal effort.
• He wants to make quick decisions based on key information presented clearly to him.
• He wants to go to places that he knows similar people enjoy. “Similar” means similar tastes and age and maybe even socioeconomic status.
• A problem he has is that he doesn’t think anyone online cares about his opinions.
• Another problem he has is a hard time finding trendy places instead of just touristy spots.

Target audience 2: The Social Boomer

The second target user is Sarah Gardener, a 49 year old social boomer who enjoys patronizing local businesses and sharing great experiences with friends and family.

• She wants to be able to make informed decisions.
• She likes to know where places are for reference.
• She is not as tech-savvy as Percy, so she needs an easy-to-use interface.
• She loves sharing with her friends.
• She gets frustrated with fake online reviews and outdated information.
• She never wants to waste time or money on a bad decision.

‍

Goals

From here we devised three (3) business goals and five (5) product goals to guide us through creating an experience tailored to Percy and Sarah

Business Goals:

1. To foster a 100% peer-to-peer food recommendation app where there is no room for fake reviews or sponsored content.
2. To provide users with trustworthy and effortless reviews by connecting people with similar tastes and demographics.
3. To create an experience that is not another messaging app

Product Goals:

1. To quickly ask friends for restaurant recommendations.
2. To provide a low friction way for users to recommend a restaurant.
3. To present key information such as location, general price, favorite dishes, and ambience in an easily interpretable manner.
4. To catalog recommendations by cuisine and add restaurants and recommendations to a .
5. To incentivize users to use the app with minimal push notifications.

Measures of success

Ideally our MVP will address each of our "people problems" in the appropriate way, but our measures of success go as follows:

• An upward trend in the number of users
• An upward trend in new interactions
• An upward trends of new restaurants cataloged by users

Value proposition

Sabor gives you quick restaurant recommendations from the people you know and trust, and helps you keep track of your favorite places. Make sponsored content and fake reviews a thing of the past. Start finding places that’ll make your taste buds happy.

‍

Ideation

At this point in the project, Jake and I had a clear vision of how the app would work, so we continued to prototype the concept. Now we could determine the most valuable features for our MVP.

‍

"I like, I want, What if..."

We started with a simple brainstorming activity to see the goal through the lens of the user. The concept was to think of what "I like, what I want, and what if blank existed. This also helped in seeing the broader ideas we could implement.

‍

Feature prioritization

Now we can separate feature ideas through thoughtful grouping in a feature prioritization matrix. Referring to the image below, the x-axis represents the impact on the users as it relates to our goals and target users, and the y-axis is the priority of a particular feature for our MVP.

Some of the other features we decided to include are:

• Having key information presented clearly when looking for a restaurant
• Being able to visualize where restaurants are in relation to me
• Being able to easily ask for recommendations and get them instantly
• Tagging restaurants by cuisine type
• Seeing which friends have favorited and/or reviewed which restaurants
• Being able to easily navigate through restaurants and cuisines
• Having a short-hand way of recommending and receiving recommendations for restaurants

‍

User scenarios

(Illustrated by Jake Nachlas)

‍

Low fidelity

Our first iteration of Sabor was designed to have the following top level tabs: a map to catalog restaurants a user has been to as well as restaurants on their wishlist, an inquiry tab to ask questions and get quick recommendations, and a profile tab to manage settings, friends, and to logout.

• Map Tab: Users can find restaurants they like and add them to their wishlist. This feature gave users a more personal impact in the community, which we hoped would incentivize users to return to the app without dumping push notifications on the user. Building their map would help users become more invested in the community (similar to Untappd’s model). The data for the map can be drawn from using the Google Maps API as we just need name and location; the rest is user input.
• A future addition in this stage of the journey would be to gamify the map and have achievements/badges such as “reviewing a restaurant in ten (10) different states” or becoming a global eater by “trying fifteen (15) different cuisines,” etc.
• Inquiry Tab: If they want to find something new, they can go to the second tab to ask their friends or browse other inquiries that have been posted. Then, if they like anything they see there, they can favorite it and try it out. This user flow does not include responding to an inquiry, but that would just appear as a response button when a user taps on a specific inquiry.
• Profile Tab: The last tab we have is the profile tab, but we don’t focus our usability testing tasks on the profile for the sake of the project’s scope--for now. The profile is where you can add/view friends as well as update settings and logout. For our MVP, we do not have a major focus on friend’s profiles.

‍

Onboarding

‍

Usability testing on lo-fi prototype

The prototype above may not look like much, but it was enough to begin user testing to improve the user interface (UI). We came up with seven (7) scenarios for the usability testing that covered the main functionalities of the app. We asked five (5) people who fit one of the two target audiences to complete the following tasks to the best of their ability.

Testing scenarios

Task 1: You want to know of a good Chinese place to go to. Ask your friends for a good new chinese place!

Purpose: This aligns with our goal of easily asking for recommendations from friends. It also aligns with the problem of not knowing which friends know what, so one place to easily ask all of them would be useful.

Task 2: You see a new recommendation on your map. You want to know how far it is and how expensive it is. Can you find that information?

Purpose: This task focuses on our goal of providing general information about a place. It also focuses on solving the problem of being able to see where new places are in relation to you. As we mentioned earlier, it can often come down to the proximity of a place as well as what’s around a place.

Task 3: Respond to my inquiry.

Purpose: This task also aligns with our goal of having friends be able to interact with one another and provide recommendations easily and in fewer than 15-20 seconds. Also, it allows a person to easily provide a recommendation to their friend.

Task 4: Add The Nook on Piedmont Park to your map and leave a review for it.

Purpose: The barrier for recommending a place is high. This task aligns with being able to very easily and effortlessly add a personal recommendation to a place they enjoy, and add it to a map catalog for future reference.

Task 5:  Filter the places on your map by cuisine. You only want to see Chinese restaurants.

Purpose: People often first choose a cuisine they are in the mood for. This feature enables them to view restaurants of the cuisine they are in the mood for, so it aligns with the goal of finding their restaurants by cuisine. It also aligns with the goal of being able to easily access past recommended places.

Task 6: Someone responded to your inquiry saying to try Eclipse di Luna, and you want to try it. Add it to your wishlist.

Purpose: This aligns with the goal of cataloging restaurants you’d like to try for later and being able to easily access it.

Task 7: The Nook on Piedmont Park is on your wishlist but you can’t remember what was said about it from friends. Find out what your friends said about that particular place on your wishlist.

Purpose:

This goal aligns with being able to see what friends say about a particular restaurant. They can do it for places on their wishlist and also places on their personal map.

Feedback

General

• Switch the map and the discussion page. The discussion page is really the primary function of the app as seen earlier in the user scenarios. Having the map as the primary page was our way of incorporating new recommendations easily, but we will have to find a better way to do that.
• We are now calling it the “Discussion” page instead of the “Inquiry” page, per user suggestion. This made sense, we want to be as clear as possible when paving the user's path.
• A couple of buttons that we important to the journey were difficult to reach at the top of the screen, so we will be moving important buttons to be within thumb’s reach.
• We will be getting rid of the hashtag in front of tags as they added little value.

Map Screen

• The map should include the name of the restaurants under their pin.
• We will add an “X” button to the cards when they are expanded to have a more clear way to close out of them.
• Also, we will make the expanded restaurant info pages take up the full screen and not half of the screen.
• We should add the number of favorites a particular restaurant has.
• Leaving a review should not be optional because they are so short and will improve the experience of the app.
• We should make the cuisine filter easier to reach.
• The wishlist button is currently a heart, but that was confusing to some. Maybe change it to a bookmark or star.

Discussion Page

• When responding to an inquiry, users wanted to be able to access their catalog to just tap something they’ve already written a review for. This will make recommending a place to friends even faster.
• Like the map page, the add to wishlist/favorites button should include how many users have favorited a place.
• We will change button text from “Share Inquiry” to “Ask Question” for clarity.
• We will change “Friends Inquiries” and “My Inquiries”
• A user wants to be able to filter by cuisine on this page

‍

UI Styleguide

All of this feedback was synthesized as carefully as possible, and we could then focus on the high fidelity version. First, we had to create a style guide to keep us in check and make UI creation easier across screens. We wanted to have a clean and modern interface that would be easy to navigate, so the majority of the app is white with blue to create a silver background and a calming feeling when using the app.

For the font, we decided to go with the default iOS font, SF Pro Display, and tried to follow the iOS guidelines for text sizes, though we adjusted the sizes when necessary. We thought using the default iOS font would help us achieve the clean and modern look that we are going for. The buttons all have a slight monochromatic gradient to also provide a modern aesthetic.

High fidelity prototype

Now we can use all feedback from the Lo-fi prototype to fill in and shape a more usable product. Some changes that need be made would also affect the user flow as represented in the image below. They were thrown off-guard when the map was presented as the first screen (understandably so); with a new product, hitting the user with a map and a load of decisions to make was an abrasive start. We added a "Welcome Back" screen as an introduction/greeting to the app. This screen will also present new suggestions and examples of how users can operate the app and see what they've missed.

‍

Login

For the login process, we made a few changes:

• We changed the layout to be less cluttered.
• We separated the login process into separate email and password pages.
• We added the “Welcome Back” page to show new recommendations since a user last visited the app.

‍

Onboarding

How we tackle onboarding will be critical to taking on new users.

• We rearranged onboarding screens to reflect the new user flow
• We added high fidelity mockups to onboarding screens
• We also added a blank state for the discussion page if you do not have any friends yet

‍

Start new discussion

Since discussions would be more of a primary focus, it was important to simplify the process.

• We moved the “+” button to be within thumb’s reach
• We changed “Share Inquiry” to “Ask Question” for more clarity.
• You can now select your current location instead of having to search for a current city. This saves some time for the user.

‍

Save a restaurant

To favorite a restaurant and add it to your wishlist, we made the following changes:

• Users were confused about the heart ❤️  icon, so to clarify the function we changed the icon to a bookmark to signify saving capability.
• We now display the number of users who have favorited a recommendation and therefore have added it to their wishlist.

‍

Respond to a discussion

A few changes here would take off time to learn the app.

• Changed “Recommend a Restaurant” button text to “Respond” for more clarity. Users believed that "recommending" was completely separate from responding to inquiries, hence the change to both "Discussions" and "Responding."
• We made it so you can now recommend a restaurant you’ve been to with three taps. One to tap “Respond,” one to tap “Choose a restaurant from your catalog,” and one to tap the restaurant you’d like to recommend.

‍

Filtering cuisine & wishlist

To simplify the organizational process, we changed the following:

• Made the “+” and bookmark wishlist button a Floating Action Button (FAB) the bottom right of the screen to be within thumbs reach, making the action easier to perform. Straight out of Google's playbook.
• We also moved the cuisine filters down to the bottom of the screen just above the tab bar so you can easily scroll through it with your thumb and select the cuisines you’d like.
• We added the names of restaurants under the pins for a smoother map experience

‍

Adding a restaurant to your map

For adding a new restaurant to your map, these are the changes we made:

• Again, we made the “+” button a FAB at the bottom right of the screen for tap efficiency.
• You can now select a restaurant within a user-specified radius to reduce the time of adding a place to map. It autofills the restaurant and cuisine entries when you select a restaurant.
• Reviews are now required, but limited to 100 characters. The gains from doing so outweigh the cost of time, per the users we tested. It will make a more seamless flow throughout the entire app and provide more information. Users suggested they would be fine doing it because it will be useful for them when they are building their map catalog as well.

‍

Peer reviews

Then we wanted to improve the information presentation of restaurant reviews.

• You can now see how many others have added a restaurant to their map or wishlist.
• We changed “What your friends say” to “What my friends say” for a more personal feel and clarity.
• We made the restaurant information screen be full-page instead of half of a page as it was in the low fidelity prototype. This made things feel less cluttered.
• We added a “x” button to more clearly close the full-screen page since dragging up/down was not intuitive to some users.

‍