Hinge
Designing a post-unmatch report feature for a dating app
May 2021



Defining the problem
Hinge is a dating app whose mission statement is “designed to be deleted.” The app is known for having users who are searching for serious relationships. Having only been founded in 2012, Hinge’s popularity has skyrocketed in recent years and its remarkable growth in a competitive market did not go unnoticed.
In 2018, Match Group announced it had purchased a 51% stake in Hinge and had the option to buy the remaining shares within the year. This happened by February of 2019 when Match Group announced that they now had acquired 100% of Hinge. Most recently, in 2020, the app was valued at over $2 billion dollars.
However, Hinge is conscious of the critical need to ensure the safety of its users. In an effort to add an extra layer of security, I set about researching and designing a solution that aims to a) offer extra security and b) promote the idea of respecting your matches on its platform.
Scope
Designing an additional feature
Role
UX Researcher
UX/UI Designer
Tools
Figma
Google Forms
Whimsical
Duration
2 weeks / 80 hours
Note
This is a project I completed for Designlab’s UX Academy. This is not a real feature for Hinge, nor was I approached by the Match Group. However, the research is organic and the design is based on real user voices, in combination with mentor and fellow student feedback 🤙
"How might we design a security feature that will serve both current and future users and reinforce a culture of respect?"
Project Goals
-
Design an security feature that would serve to protect both current and future users of Hinge from those who violate the app’s terms of use
-
Ensure the visual aesthetics and functionality of this feature are in line with Hinge's user interface
-
Showcase this feature to users in a clear yet unobstrusive way

1.
Research
-
Survey
-
Competitor analysis
-
User Interviews
2.
Define
-
My Solution
-
Storyboard
-
User Flow
3.
Design
-
Sketches & wireframes
-
Ui designs
4.
Test
-
Usability tests
-
Affinity map
1.
Research

Research Goals
-
Understand how often users experience harassment or inappropriate behaviour on dating apps
-
Identify the greatest frustrations users have with the current report process on their app(s) of choice
-
Establish whether or not dating apps do enough to ensure the safety of their users
-
Consider how I can introduce my security feature to users in a clear and non-intrusive way
Survey
Past conversations with friends meant I had long-since suspected that dating apps don't do enough to ensure the safety of their current and future users.
However, I knew I had to obtain definitive proof of this before going any further with my research. So, I created a survey and had 19 participants agree to help. My questions and answers are below.




Key Findings:
-
47% have had a negative experience on dating apps. Could this be because of past experiences of harassment or user safety?
-
67% believed that dating apps don't do enough to prioritise user safety. Have these survey participants experienced similar issues that would lead them to this viewpoint?
-
26% have been in situations where they have reported (or wanted to report) a fellow user
-
63% said their past experiences on dating apps will dictate whether or not they use these apps in future. If one app major app like Tinder or Bumble doesn't do enough to protect its users, might the entire market suffer?
These findings were eye-opening and confirmed to me that there was a clear need to improve user safety, if not as a moral obligation then a way of avoiding a crisis in confidence that users may have towards dating apps in future.
Competitor Analysis
Feedback from my survey and market research confirmed that Tinder is the most dominant app in the US, controlling well over a quarter of the market with Bumble not far behind**. Analysing these apps could help me understand why some users might be underwhelmed with the security features currently in place and what the current report processes are.
Note that from the chart below, it would have made sense to include Plenty of Fish in my study. However, due to the time contraints of this project, I chose to instead include The Inner Circle in my analysis as I had an existing account and was familiar with its interface.
**Source: businessofapps.com

With the data obtained above, I set about going through the report process on these apps, as well as browsing in the help centres to see what additional support they offer their users.
My main takeaway from this analysis showed that Bumble was the only dating app to offer its users a post-unmatch report feature.
I also noted though that Tinder and Bumble had a wide variety of resources in their respective help centres, offering users things such as visual guides on how to report users to interactive quizzes to test users' knowledge on how to best protect themselves when using these apps.

Interviews
With the findings from my competitor analysis, I began drafting a script for my user interviews, with the goal of both finding out about general user behaviour on dating apps and how these users try to protect themselves online.

Key findings
Goals


Frustrations


Needs


Motivations


2.
Define

My Solution
Having synthesised my research findings, I noted the following:
-
Survey – figures 1.1 and 1.2 confirmed to me that there is a clear need to improve user safety on dating apps
-
Competitor Analysis – Bumble was the only app I came across that had a post-unmatch report feature
-
User Interviews – Users have a need to feel safe and secure on any dating apps
With these findings, I believed that designing a similar post-unmatch report feature for Hinge would offer the best solution for the user.
Storyboard
How could I articulate the need for Hinge to prioritise user safety and wellbeing to stakeholders if they don't use dating apps?
So I decided to create a storyboard that I felt would explain this problem to the stakeholder.

User Flow
For this project to be a success, it was important to not only keep in mind the findings from my user interviews but also consider how some of these insights might translate into a real-life scenario.
Illustrating some of these frustrations and possible decision points in my user flow helped me to design a more comprehensive and realistic prototype in the design stage of this project.

3.
Design

Wireframes
With my solution in place, I considered the app's interface once more and my screenshots before creating wireframes to show my proposed feature.
I realised that a key visual element in my designs would be some sort of pop-up that notified the user that they had been unmatched. I considered using a modal but have experienced frustrations from these in the past whereby I was unable to navigate through to other screens because I needed to first interact with this alert.
Considering that the user's eye would naturally travel down to the bottom of the screen as this is where they go to type a message, I designed a simple message in a grey box and placed it in this bottom section, believing that would be difficult for the user to miss but not overly intrusive whilst they're in this chat screen.
Instant chat

Report screen 1

Report screen 2

Report screen 3

UI Designs
A key constraint of this project is that because I was adding a new feature to an existing application, I'd need to adhere to Hinge's style guide. This wasn't a negative however, as time was saved not having to create my own style guide for this project.
So, I referred once again to my screenshots from Hinge before copying the various elements in its interface, adding elements such as an accordion in report screen one to provide extra info to the user without requiring them to navigate elsewhere, and extra information in report screen 3 to provide feedback to the user and show them what happens next.
I also decided to take this report feature one step further. Match screen 1 - report status show how the user would be kept updated with regards to the report they filed – a key frustration uncovered during my user interviews.
Chat screen 1

Report screen 3

Chat screen 2

Match screen 1

Report screen 1

Match screen 2

Report screen 2

Report status

4.
Test

Preparing the Prototype
Now I'd created my UI screens, it was time to test my prototype with real-life users. Noting any obstacles they encountered would allow me to make further improvements on this case study.
Test Objectives
-
Navigate through the report process
Methodology
I interviewed 4 participants via moderated usability testing and had them undertake the above whilst sharing and recording their screens.
Test results
Participants:
-
4
-
Ages 23-32
-
All currently use dating apps or have used them in the past
Pros



Outcome (navigating through the report process):
-
100% completion rate
-
75% error-free rate
Cons



Affinity Map
I compiled observations and insights provided by my usability test participants into an affinity map.
This simple visual aid allows an onlooker to quickly decipher the success of the prototype and see if multiple users are making the same observation or not (as in instances such as these, I place these sticky notes on top of eachother).
From these insights, I then was able to prioritise my final iterations.
