Metromatch
Fostering connections on the subway in a fun, yet safe, way
Task
To create an experience enabling New Yorkers to make connections on the subway while discouraging misuse and undesired behavior
Overview
Metromatch is a concept for a mobile dating app that enables New York City metro riders to connect with people they’ve crossed paths with on the subway.
With over 5 million riders per day, the NYC subway should be a great place to meet someone new, but in reality, it can be awkward or creepy to approach complete strangers. Metromatch provides a safe, fun, and easy-to use platform for riders to make connections with fellow passengers who have caught their eye if both parties are interested. If a rider sees someone on the subway that they would like to get to know, they can try to make that connection through the app instead of missing out on the opportunity altogether.
As the sole product designer, I brought this concept closer to reality by working out exactly how users can find and connect with each other using the app. Following an iterative design process, I created and gathered feedback on storyboards, wireframes, and mockups to deliver a high-fidelity prototype for mobile and a basic design system.
Client
A native New Yorker and frequent subway rider herself, my client is a young legal professional who came up with the idea for Metromatch several years ago. As a busy single mother with no background in app design or development, my client has struggled to get her app idea off the ground. She hoped that I could help bring the idea in her mind closer to an attainable reality.
Problem
How Can Users Find Each Other?
In order for riders to make connections on Metromatch, there must be a way to find a specific person’s profile without knowing anything about them other than what they look like. My main goal for this project was to create a feasible and simple way for users to find each other on the app despite not knowing any personal information about them, such as their name or contact information. The scope includes the flow starting from when users search for the person they saw on the subway, by providing details such as the date, time, and person’s appearance, until when the other person receives their request to connect and chooses to either accept or decline.
Safety Concerns & Uncomfortable Situations
Unlike most dating apps, Metromatch involves a real-life component where users try to connect with strangers they’ve seen around before and could potentially run into again. This distinction inevitably has added implications for potential misuse and uncomfortable situations. To tackle this issue, it was immensely important that I prioritize user safety and discourage undesired behavior, while also ensuring that users can still effectively use the app as intended.
Design Process
Design Brief
After conducting several interviews with actual NYC subway riders to learn about their experience meeting and flirting with people on the subway, I created a design brief outlining my objective for this project, the intended users of the app, the key scenario I would design for, and key principles I would follow in my design.
Storyboards
Based on initial discussions with potential users and fellow designers, I created storyboards to illustrate three key scenarios in which the app could be used. Doing so helped me to think through how the app might work and what type of features would be most useful in each situation. The storyboards were also useful for getting feedback from test users and my client.
Scenario 1: Thanks, but No Thanks
While on the subway, a rider sees someone they would like to get to know, finds them on the app by entering details about them, and sends a request to connect, but ultimately the other person is not interested.
This storyboard includes my ideas for how the app could utilize Bluetooth and location tracking to limit the search scope to nearby users, function when there’s no signal on the subway, and circumvent uncomfortable situations brought up in user interviews, such as feeling pressured to respond immediately or being contacted by someone you would never consider dating.
Scenario 2: Both Interested
In this scenario, it’s clear from the start that both riders are interested as they are already smiling at each other and making eye contact on the subway. In this case, it might be especially cumbersome to go through the whole process of searching by the person’s appearance, and therefore, a slightly more direct approach might be appropriate.
This storyboard shows another way that users can connect with each other – by using a discovery feature powered by Bluetooth. If two nearby users make themselves discoverable at the same time, they’ll appear on each other’s phones with the option to connect.
Scenario 3: Bad Intentions
To explore ways to thwart misuse, I considered scenarios in which a user has bad intentions such as stalking, harassment, or retaliation.
These storyboards depict safeguards that utilize features like verified accounts, hidden personal info, and user preferences to deter bad actors and secure user privacy.
Wireframes
The feedback I received on the storyboards seemed to support having two methods of connecting via the app, each for different scenarios. By sketching wireframes, I further fleshed out the flow for each of the two ways users could connect with each other, the layout of the screens in low-fidelity, and the information architecture of the app. The wireframes were used to conduct user testing, the results of which helped guide the design of the high-fidelity mock-ups.
Method 1: Search by Appearance
The primary way that users can find a specific person’s profile is by providing information about the person’s appearance as well as the time and place they saw the person.
The wireframes include the following search options for appearance: skin color, hair color, and clothing/accessories. As for the time and place, this design prompts users to provide the date, the train line, and the stops where the person got on or off the subway, if known. Although included here, I later decided against including the subway stops in the high-fidelity design based on feedback I received expressing discomfort and concern that this could promote stalking and other undesirable behavior.
Once users enter these search details, they are shown a list of photos of matching users, and if they see the person they’re looking for, they can send them a request to connect.
Method 2: Go on the Radar
The second way that users can connect is by going “on the radar” or making themselves discoverable via Bluetooth to nearby users. By doing so, users can connect instantly with another nearby user who has simultaneously set themselves as discoverable.
In order to prevent abuse of this feature and maintain user safety/privacy, users can only remain discoverable for a very short time – less than a minute. In fact, through user research, I found that although people tended to agree that this feature would be convenient and useful, they were initially a bit wary about using it due to potential safety implications. However, this concern seemed to subside once they understood that the duration was extremely short and that this feature was intended for situations where both people have already made some kind of mutual contact, such as smiling or flirting.
Due to time constraints for this project, this method of connecting was not built out further in the high-fidelity mock-ups.
High-Fidelity Prototype
Based on feedback I received on my wireframes, I created a high fidelity prototype detailing the primary way that users can connect with a fellow rider who’s caught their eye — searching by appearance.
Home (Profile)
If another rider has sent the user a request to connect, the Home screen shows the profile of that rider with options accept or decline the request. Otherwise, the Home screen shows the profile, with name and age hidden, of a random rider that the user may have crossed paths with in the past.
Safety Measures
- Verified accounts: If riders have verified their account, there is a note shown on their profile. These people have taken steps to prove they are actually the person shown in their pictures, so users can feel more secure interacting and connecting with them. In settings, users can also choose to only allow requests from people with verified accounts.
- Ability to block or report users
- No notification if request is declined or unanswered: If the user declines the request or never responds, the other person does not receive any kind of notification saying so. This is to avoid retaliation or awkwardness should the two happen to cross paths again.
- No personal info: To protect user privacy and prevent misuse, no personal info is included in user profiles, which only show images and a short tagline. Name and age are only shown if the person has sent a request to connect with the user viewing their profile.
User Wants to Connect
Random User
Search by Appearance
To search for a rider by appearance, users must first indicate when they saw the person. The app uses this timing information to limit the search results to people who were nearby at the specified time based on data collected from location tracking and Bluetooth.
Next, users are prompted to enter at least three details about the person’s appearance, such as skin tone, hair color, or hair style. Based on the feedback I received on the wireframes, I added a visualization that changes based on the user’s selections for appearance in order to give users a quick, easy, and engaging way to check the options they’ve entered.
Test users also explained that specifying the person’s clothing could be time-consuming and cumbersome, especially since they were not confident that they would remember what the person was wearing. For this reason, entering clothing is not required and the inputs for doing so are on a completely different screen so that users can simply skip past it if they would prefer.
View Matching Riders and Send Request
After providing the search criteria, users can view the profiles, with names and ages hidden, of a short list of matching riders. The results list would be limited to the top 10 closest matches to avoid abusing this as a way to freely browse user profiles.
If users find the person they are looking for, they can send a request to connect. Since test users felt that receiving a message with the request would be more personable, the app encourages users to include a message.
Safety Measures
- Only see users if you match their preferences: Even if the app finds people who match the description provided by the user, those people will only show up in the results if the user doing the search matches those people’s pre-set preferences for things like age, gender, and verified account. This to prevent the discomfort of receiving a request from someone users would never consider dating, especially if it’s someone they might cross paths with again.
- Time delay before sending notification: The request to connect is not sent immediately to avoid uncomfortable situations such as knowing someone is watching you or feeling pressured to answer right away. The person will receive the request within the next 10-15 hours, but the exact time would be purposely varied to make it hard for users to predict.
