CLOSE ✕
Get in Touch
Thank you for your interest! Please fill out the form below if you would like to work together.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

A service that helps groups come to a fair decision.

FARE

FARE helps groups of people quickly decide where to eat in agreement. These decisions are made by swiping with another user to eventually match on a restaurant.
‍
(January - April 2022)
Role: Lead UX Designer

PROTOTYPE
OverviewResearchMODELINGREQUIREMENTSFRAMEWORKREFINEMENTS

OVERVIEW

‍

For the 2022 senior capstone project, my project team and I designed an IOS-based prototype that helps people quickly decide where to eat in agreement. These decisions are made by swiping with another user to eventually match on a restaurant. Users who prefer to dine alone can view recommendations on the discover page. Recommendations are personalized by using filters, current favorite restaurants, and restaurant preferences. 

This project was in progress from January to April 2022. The design team members consists of Alex Manuel (Lead UX Designer),  Diya Singh,  Sabina Siddiqui, and Conor Blankenship (UX Designers).  Together, we collaborated in implementing Goal-Directed Design (GDD) to create FARE.

‍

It is important to note that this is strictly an academic project. Due to COVID-19 restrictions, we’ve collaborated virtually via Discord, Miro, and Figma.

‍

Click to open prototype.

Introduction

Something we’ve all most likely experienced is disagreements, specifically when it comes to finding a place to eat with a party or a partner. Here’s a common scenario: Person A has an idea of the kind of food they want to eat but does not know what specific restaurant to eat at with their partner, Person B. Person B keeps suggesting places, but none of the suggestions sound good to A. They spend over 20 minutes discussing and are still not being able to decide where to eat, which only increases their frustration. 

Fare attempts to solve situations like this so that couples or groups of friends can fairly make the decision. This app also caters to those who prefer to dine alone, but still want to find places to eat based on their preferences.

FARE Solves...

  • The indecisiveness of choosing where to eat.
  • Opportunity to explore new restaurants.
  • Takes less time to decide where to eat.

Goal Directed Design

As mentioned before we tackled this project using Goal-Directed design, a design method developed by Alan Cooper. It’s crucial to the design process as it helps us understand users’ goals, needs, and motivations to produce an effective human-centered design.

Goal-Directed design has six stages: Research, Modeling, Requirements, Frameworks, Product Refinement, and Support.

‍

From About Face: The Essentials of Interaction Design by Alan Cooper.

RESEARCH

Research is always the first step that helps us better understand information regarding the realm of the app, such as the user’s goals, the environments it will be used in, and past applications that function similarly. In the research phase, we held kick-off meetings, brainstormed ideas, completed a literature review, and conducted user interviews.

Kick-Off Meeting

Our meetings were held remotely via Discord and Miro. Since we had no idea how this idea would come to fruition, we first began brainstorming ideas on sticky notes. We also listed user goals, talked about the problems our product would solve, and discussed how the product should look and behave.

Brainstorming ideas on sticky notes.

With the aid of a Kickoff meeting worksheet, we brainstormed some assumptions about who our users will be and the problems they may face regarding social media usage and creativity alike. Since we have no actual stakeholders, the worksheet helped us to think about the possible business goals and opportunities stakeholders would seek. We concluded the last meeting with a problem statement, a research question, and user goals.
‍

Problem Statement

"People often have difficulty deciding where they should eat, especially in groups. This indecisiveness usually snowballs into confusion and wasted time. Currently, there are no well-known apps that people can use to decide where to eat. Our app could help users quickly and fairly make the decision while generating more business for restaurant chains."

Research Question

What kinds of methods do social groups commonly use to agree on a decision?

User Goals

  • Quickly find places to eat
  • Come to a decision with a group
  • Discover restaurants that they would like

Literature Review

For the Literature Review, we collected internal documents, industry reports, and web searches related to existing competitors that are similar to our idea. We found both negative and positive reviews for these platforms so that we could know what aspects to avoid, and which aspects of these apps were more favorable.

We learned about the Paradox of Choice as well. This is an observation suggesting that having many options to choose from can cause people to stress and problematize decision-making, rather than making people happy and ensuring they get what they want (Source). This was important to consider as we did not aim to overwhelm users by providing too many choices.

Competitive Audit

We decided that our competitors were:

  • Yelp - A well-known restaurant locater and reviewer, the app has issues like false information, a shifting algorithm, and difficulty reading reviews.
  • OpenTable - Specializing in dining reservations, the app utilizes filters, menus, and more to find and decide where to eat. Drawbacks include the layout and the rewards.
  • DiningDecider - A simplistic restaurant swipe app, the map is prominent and has a few basic filters like price and location. The app can only view your given location.
  • Tinder - Selected for its use of swiping, people like the simplicity and ease of use. Issues include its monetization model and account wiping.

‍

For each competitor, we looked at both positive and negative reviews from real users. We also found strengths, weaknesses, and opportunities within each competitor. This allowed us to get an idea about the current state of capabilities and constraints in regard to our domain.

User Interviews

As part of the research, we reached out to four potential users of our app and interviewed them by asking questions based on their personal experiences with deciding where to eat with a partner or a group of friends. We asked questions related to what features they would like to see if they were to use this app and whether they see themselves using the Fare app frequently. 

Five interviewees participated; Neva, Nikki, Adam, Sophie, and Mesha. Most were ages 19-25 years, with one participant standing out as an older interviewee. These people have all experienced some form of disagreement when it comes to finding a place to eat.

Using the feedback and notes we took during the interviews, we each took time to note important patterns or points that were made by each person. Then, we created an affinity map where we grouped similar themes we discovered.

Discord interview, Neva.
Affinity mapping data from interviews. Click to expand.

Listed below are the common patterns we found in the affinity map:

  • Eat out once or twice a week.
  • Don't out by themselves.
  • Some prefer affordable dining options. 
  • Some don't mind spending extra on fine dining.
  • Spend almost 20 – 30 minutes deciding where to eat.

‍

Overall, the affinity mapping set us up for our transition into the Modeling Phase to build our Primary Persona.

MODELING

Personas help us, as designers, to make sure that we’re accommodating our users’ goals and needs during the Frameworks Phase. ‍Based on research results and affinity mapping, we were able to create a primary and secondary persona.

Kevin Bell

Primary Persona
Kevin Bell is a 42-year-old married man from Jacksonville, Florida. He has been working as a pilot with Frontier Airlines for 7+ years. He's also a travel enthusiast outside of work. Whenever he's on vacation, Kevin is most likely traveling somewhere with his wife. Together, they love to explore unfamiliar foods and restaurants in new areas Sometimes they have trouble agreeing on where to eat, especially at family gatherings. Kevin usually solves these disagreements by giving into his wife's choice.

Sarah Paige

Secondary Persona
Sarah Paige is a 23-year-old business student and she recently transferred to San Antonio, Texas for school. Although she’s new to the area, she has already found her own friend group. They hang out at cafes and restaurants every other weekend and Sarah always lets them pick where to eat. Sarah loves to hike as a hobby and she usually likes to find a place to eat after her hikes. With Sarah being new to the area and quite indecisive, she often spends over 20 min. to find somewhere to eat.

REQUIREMENTS

A Requirement is what's needed to exist on the app so that personas can achieve their goals. It connects the gap between research and design by using personas to create stories that express user satisfaction. We do this by putting the Persona into a Context Scenario, which is essentially a story that explains how a product fits into the Persona’s life and how it helps them achieve their goals.

Using the Context Scenario (written by Sabina), we made a list of Requirements that FARE needed to allow users to successfully meet their goals. 

Click to expand context scenario.
Click to expand requirements.

FRAMEWORK

This next stage allows us to prioritize elements and think about what content is most relevant to users before jumping straight into the final prototype. Referencing our user flows, we each divided up screens and created low-fidelity wireframes of a possible layout for our final prototype. This task was done using the wireframing tools that are provided on Miro.

Next, we moved to Figma to begin building the prototype. Since this is a low-fidelity prototype, a lot of content (information, styles, colors, branding) is not included. For example, most screens will have filler text or image placeholders. The low fidelity prototype is still accessible in Figma.

Click to expand user flow.
Click to expand wireframe.

‍


Low Fidelity Prototype

Next, we moved to Figma to begin building the prototype. Since this is a low-fidelity prototype, a lot of content (information, styles, colors, branding) is not included. For example, most screens will have filler text or image placeholders. The low fidelity prototype is still accessible in Figma.

‍

‍

REFINEMENTS

Usability Tests

After finishing our low-fidelity prototype, we began usability testing. Using Google Forms, we included a set of 6 tasks for navigating the prototype, and 19 (primarily) open-ended questions.

We recruited four participants of the same demographic.

‍

Positive Takeaways

  • They appreciated the simplicity of the app
  • The group/friends feature is highly valued.
  • The level of information on the restaurant tab is a big plus.

‍

Negative Takeaways

  • Certain back buttons were non-functional.
  • The home button was initially confusing to a user.
  • One participant disliked that the edit friends option was in the settings section.

‍

High Fidelity Prototype

After receiving feedback, we began constructing the high-fidelity prototype. We fixed issues with the prototype flow, made each screen transition consistent, and removed “Edit Friends” from the settings. We also created a brand style, logo, and app name.

‍

email mePortfolioAboutHome