How may we find potential matches for our users?

Project timeline

Each round of building & testing combine problems addressed in other case studies for this project. Later, you may see features in the screens that are not talked about here.

One problem our CEO identified in his competitive analysis of existing fetish dating apps (Whiplr, KNKI, Vanilla Umbrella) is that there is no way to find people who match with you in a reciprocal interest when it comes to fetishes that involve one giving and receiving.

For example, two people may be both into bondage, but do they like to do the tying or being tied up? It’s no use if we match two people who enjoy being tied up.

Let’s draw this out!

Eureka!

After drawing the problem out on my blackboard, I realized our problem can be abstracted into a graph theory problem.

We can rephrase our problem as…

Users are potential matches for each other, if there exist a path of length 2, between them. i.e: If we were to return matches for Gretchen: Jimmy would be a good candidate but not Edgar.

Users are better potential matches for each other, the more length 2-edge paths they have between eachother.

This realization, made the solution of finding matches for our users clear, since it’s already solvable using existing mathematics principles.

Solution

We can represent all fetishes as nodes in our graph database (Neo4j).

When users setup their profiles they can choose the way (give/recieve) they are interested in it.

Testing

After we made a quick profile setup UI, and a discovery (find users that share your same interest). We put our partial-app in front to users to test these core parts out.

This part of the flow in the profile setup was awkward and cumbersome. And it's a core part of our value proposition!

And we learned...

We realized the language directional provide/receive may not apply for all of them, making the sentence sound awkward. Also with each kink you like it leads to to another screen describing the kink and asking you to select direction. The process of checking things you are interested in got tiring.

Our initial implementation was very methodological, we it was almost a direct approach to how our graph database stores data. Most people stopped after selecting 5, even if there’s more they are interested in.

How one engages with their latex fetish, is very different from how they may engage with the desire for discipline.

New Problem Statements

• How do we accommodate for the different types of kinks in which the language use for them are vastly different?
• How do we make the extensive list of kinks less overwhelming?
• How can we let users selection for the directional nature of kinks, without having to take them to another screen or disrupt flow with an alert?

Solution? Segmentation!

Revisions

We went through our list and sorted everything into groups. We can now construct sentences with these groups. And let our user fill in the blanks with fetishes. This method reads more fluidly and does not make the user go from screen to screen.

The new select interest screens

until future improvements

Checkout other KinkedIn case studies:

• Define values with logo design
• Encouraging people to respect eachother
• Ensuring the safety of our community