Journey of Kinkedin

Alice Q
8 min readApr 23, 2018

--

Late 2016, I joined KinkedIn team as their technical co-founder, when Steve Dean, premier online-dating consultant, recommended me to their CEO because of my knowledge on online dating apps (from to my General Assembly project and helping him perform competitive analysis for his own work).
I fill into whatever roles my two other co-founders need me to be. Over the course of this on-going project, I have been the user researcher, UX designer, and developer. The visual design of this app has NOT YET been worked on, we are still hashing out some usability issues and server optimization issues.

Logo Design

De-stigmatize the marginalized

One of my first task on the team was to redesign their logo. Their existing logo was about boundaries, when and how to say no. We want to move forward as a company striving for the “enthusiastic yes”! My teammates wanted a logo that conveyed: connectedness, wholeness, and embracing queerness. The logo I designed for us is inspired by the shibari knot of a heart.

Problem Statement

How may we find potential matches for our users?

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:

Visualization of our problem using graph theory

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, if the number of paths that link them together are more.

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

Other Considerations

At the end of the day, we are still building a dating app. And so much of a user’s experience with the our brand is depends on things that happen outside the app. How do we address general dating app issues?

Can encourage our users to treat each other with respect?

How can we hold ourselves accountable for users’ safety?

Problem Statement

How may we encourage our users to treat each other with respect?

“Online dating sucks”, is a phrase you commonly hear from a New Yorker, regardless of gender or sexual orientation. When asked to ask why, the reason often refers to the way people treat each other in the dating scene.

Why do so many people sum their dating experience to be unpleasant?

Online dating opens doors, it shrinks the miles, bridges social divides. It brings people who may not have the chance to run into each other in their daily lives, into awareness of each other existence. However it also gives you the impression that your options are limitless. The better option may be just one swipe away. People become reduced to profiles.

Coffee Meets Bagel started their business by selecting for you one profile to review a day. As a result, their users often treat each other with more respect than users on Tinder or OKCupid, which gives user almost an boundless sea of fish. I decided to borrow a page from their book, with some modifications.

Feature Stories

Daily Matches!

Like Tinder, when you and another user like each other it’s considered a match! But you can only have up to 7 matches a day. After that we will stop showing you profiles, and encourage you to chat with your matches.

A phrase I commonly hear from one segment of the users is “Coffee Meets Bagel does not work!” Since women tend to be more selective of who they “like”, mutual matches are less common for lesbians and straight men. Instead of giving you a set number of profiles to review daily, we will show you as many users who fits your preference criteria. Until you’ve reached 7 matches that day.

Aftercare Check-in

Aftercare refers specifically to the time and attention given to a partnerat the end of a scene. It is the comfort one provides to other partipants after having an intense experience that can leave an individual, top or bottom, in a vulnerable state. — BDSM Wiki

The safety of our users is our priority, we want to be able to check in with users to make sure they are not endangered by being on our platform.

From interviews, I’ve learned a tactic people employ when they go on a date that my be a little sketchy is that they tell their friends about the date, and their friends will check in on them afterwards. Because some forms of kink is still a highly stigmatized practice, people may not have come out or be ready to their friends.

Our Aftercare service lets you let us know that you are going to meet with someone on our platform and also with whom. We will check in with you 12 hours after your scheduled date. Even if nothing went wrong, it’s still fun to gush about a good date!

The conversation flow our chatbot follows to help our user work through their feelings.

Lessons Learned

For this aftercare feature, we put together a team of trauma trained therapist, who together with our Content Director crafted the language of how we would communicate with our users when we check in with them.I was responsible for the flow, making sure logically the conversation fit together. From the script they spent me, I constructed the flow chart that would guide how I am to program out chatbot.

But I also had to put myself in the mind of a user who might have just got out of a traumatizing date to predict how they would respond to our messages. Empathizing with a traumatized user, through the several iterations of constructing a conversation flow proved to be an emotionally and physically draining experience for me. I have a new found respect for our community accountability team, who has to do this on regular basis as social workers

User Testing

Firstly, Fail Fast

Test the subset of features we focused on was setting up your profile, and viewing other users profiles and “liking” users.

One of the design challenges we’ve been having is figuring out how to make selecting the long list of kinks and fetishes intuitive. Our initial implementation was very methodological, we it was almost a direct approach to how our graph database stores data.

This part of the flow in the profile setup felt overall awkward and cumbersome.

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.

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

Select kinks screens

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.

Revisions

User discovery

Originally our profile screens was a very much like Tinder, where we present to you one profile at time.

User Interviews II

After our first round of user testing, I conducting a second round of user interviews. From those interviews, I’ve discovered people prefer the OKCupid method, in which they don’t have to make a decision about someone on the spot. There is a lot more go into consideration, when choosing a new play partner to engage in a scene with other than just physical attraction.

Feature Story: Vouching System

From the surveys, I’ve also come to learn that people are more likely to trust new people if they are vouched for by their friends. This is the selling point of Hinge, to leverage off mutual connections. Maybe we should allowed user to vouch for their partners and well as people they’ve matched with.

A user may vouch for either their partner or a connection. We ask the following questions:

  • Were they honest with the information (photos and bio) they provided in their profile?
  • Did they respect your boundaries?
  • Are they a good communicator?

Test Prototype

I made a prototype for the discovery part, so we test out how we can implement our findings from our second round of interviews ans surveys.

If someone if vouched for by other users, it will show on their profile card when you are scrolling through profiles. If someone is vouched for by either your partners or connections, we will also let you know.

From test results, I’ve learned we need to provide more feedback to when liked/skipped profiles are hidden. You can also test it out

Prototype Demo

Going forward

This is still an on-going project. Over the past year, I’ve been refining our Aftercare feature and working on server improvements.

Right now, I am prepping the app for another round of user testing in May

At the end, there is still the visual design work to do in making the app look consistent.

--

--

Alice Q

The journey of a computer scientist learning user experience design