Weekend Project – OkCupid Messaging Improvements – UI Mockup and Demo

  • report
    Click for Disclaimer
    This Project is over a year old (first published about 4 years ago). As such, please keep in mind that some of the information may no longer be accurate, best practice, or a reflection of how I would approach the same thing today.
  • infoFull Project Details
    info_outlineClick for Full Project Details
    Date Posted:
    Nov. 26, 2017
  • classTags
    classClick for Tags

Weekend Project – OkCupid Messaging Improvements – UI Mockup and Demo

Published: 11/26/2017

  • infoBackground (Click to Hide/Show)
    A common complaint for female users of almost any dating site is the constant barrage of messages from men that are unsolicited, inappropriate, and show that the senders didn’t even skim their profile information. I have heard this from others, and it also seems especially prevalent where I live, where the ratio of (single) females to males seems skewed so that there are more single males. This issue also works both ways, and I’m sure is not limited to the binary representation of gender either. Obviously, it would be best if society could fix the root cause, and everyone could agree to stop being rude and stop sending messages that are just the word “Hi” or “Ur 2 Htt, Msg Me Rt now”, without even reading someone’s profile, but I don’t have high hopes for that. However, I think that dating sites could do a lot to address this, and I’m a little surprised that OkCupid, which often is ahead of the trend, has yet to do something like this (at least that I’m aware of).


I came up with two simple solutions that they (OkCupid or another dating site) could implement in their User Interface (UI) to help reduce the quantity of low quality messages that certain users like to send out frequently and without discrimination. These would serve as “challenges” to make it more difficult for users to send generic messages without reading someones profile. Both of these solutions prevent a user from sending their first message to another user without having spent some time looking at the profile before initiating. Once the user completes one of the challenges, or if a message has been exchanged between the two users prior, these features/challenges should disable themselves. Demo for each solution was created using Javascript, and a fake profile page with user information replaced with dummy text.

Solution A: Timer

This is the easiest solution to implement, and to me, is a no-brainer. Requiring users to spend a minimum amount of time (in my example, 30 seconds) looking at a profile before sending a message seems like a completely reasonable thing to do, and I would be flabbergasted if anyone could come up with a solid argument *against* it. If you can’t spend at least 30 seconds reading what someone thoughtfully wrote in their profile, why should they spend 1+ minutes reading, thinking, and responding to your message?

Demo Video – Click Below to Play

Note that the developers console on the right is shown for demonstration purposes. In this example, the timer stops counting if something is hiding the profile from view. This stops users from simply leaving the error message about the timer up until the time passes, while looking at content elsewhere. This feature could be fleshed out further, and more requirements could be added, such as scrolling to the very bottom of the profile, expanding sections, etc.

Solution B: Custom Question

This solution is more complicated to implement than the first (simple timer). In this feature, a user (the receiver) can set a custom challenge and expected response. The user (sender) trying to send their first message to the receiver will be prompted to answer the custom question, and if their answer matches the one saved by the receiver, they will be allowed to send their message.

Demo Video – Click Below to Play

Note that the developers console on the right is shown for demonstration purposes. These questions could theoretically be automatically generated by the system – for example, if the user has indicated in their profile settings that they own dogs (a simple checkbox in OkC’s UI) the system could generate a corresponding question, “Does user [username here] have dogs?, Yes or No”. The complication with this feature is that it would require creating and exposing a new internal API endpoint to validate answers, since having the answer matching logic purely in client side code would make this easily defeat-able to any tech-savy users, and someone could easily release a chrome extension or bookmarklet so that any user could circumnavigate the custom questions.

Recap and Further Thoughts:

Although this is a working bare-bones demo/mockup, there is a lot of wiggle room on how this could be implemented. For example, instead of enabling this feature across all users, OkCupid could only trigger it for “suspicious” users. For example, if a user is sending a large volume of messages per day in comparison to the average, they could start seeing the 30 second timer while others do not. This would be similar to how ISPs might throttle the connection speed for users abusing bandwidth, or how Google ReCaptcha v2 can be set up to only show when suspicious user activity is detected. In addition, controls over the functionality of these features could be extended to the receiving users themselves – or adapted automatically. For example, the system could automatically turn on the feature for users that *receive* a higher amount of messages per day than others, but all users could get a toggle switch to turn it on if they want to.

Leave a Reply

Your email address will not be published.