A designer diving into the design of dating apps
A two months challenge
I wrote this article in 2017. Some months after I left my full time position at Fruitz and went to new adventures while remaining a consultant for Fruitz. I then came back to Fruitz in 2021.
In February 2022, Fruitz was acquired by Bumble.
In October 2017, a part of the Flashgap team decided to take some time to think about side projects that could be developed. We applied design thinking methods and covered different pain points in miscellaneous daily uses. Launching a QA app wasn’t the best time. Iterations led us to take a look at dating apps. We wondered what we could achieve in less than two months.
1. Back at it again with the empathy phase 🎉
We started by listing well known dating services used in France. We ended up with AdopteUnMec, Meetic, Gleeden, Tinder, Happn, OKcupid. The best approach was to dissect the experience. This allowed us to understand where these apps differentiate themselves from each other. It was also a way to compare how they solved the same problem and which problem they didn’t. Armed with our brand new stack of sticky notes, we pointed two crucial pain points in these 6 services. OKcupid and AdopteUnMec take the time to create a dense algorithm to make users match. It’s a long process at the beginning. But once a user matches with someone else, they are left to their own devices — pun intended. Two individuals share the same interests, but they don’t share the same relationship purpose. Wouldn’t it be a key element in the dating world where users are in a hurry? We wanted to start digging into this and see if we had a great insight.
We shared our personal feedback towards dating apps and if we experienced frustration. Speaking out loud and writing on sticky notes enabled us to create a template for our personas. What are the informations we need? What are these dating app users doing on a dating app? When? Why?
We were looking for answers. As we are four 25 years old men we wanted to swift to gather data to avoid prejudices. We combined the newly acquired data with recent articles to verify if the 2014 data was still relevant. Some examples of what we learned:
- Growth of social acceptation for dating app users
- It becomes mainstream
- There is a need of feeling safe
- It addresses a urban population
- Relationships’ purposes may vary during the year (christmas, new year, birthday, vacations, summer)
We imagined user scenarios based on our personas and we highlighted frustrations. They were the result of misinterpretations about the relationship purposes. Take Steve, a 26 years old man with no time want a date at the end of his work hours. Too bad, the individual he matched had no interest in any relationship, it was about ego boost. But what if Steve could have known what the other intentions were?
2. Looking for problems
[It’s not personal I promise]
We listed main problems:
- Fear of rejection
- Fear of social recognition
- Hard to make the first move
- Waste of time
- Misinformation about the intentions
- Harassment
- Obscenity
- Slutshaming
“How might we create a dating service that ensures 18–35 to quickly find a match in their local area with the same love interest without wasting time?”
What if…?
- People could outspeak what they are looking for without the fear of being judged
- People could change what they are looking for depending on their mood
- People could match only with people with the same interest in a spicy way
- Shy people could have ways to break the ice with ease
- Women had more power
Since we are aiming at an MVP we knew it would be a trap to try addressing all the problems at the same time. We decided to start solving the main problem we highlighted: relationships purposes’ mismatch. But it’s linked to another design problematic: “telling what you are looking for without the fear of being judged”. Thus we must design something else to lower personal engagement when expressing feelings and desires.
We decided to say it with fruits! Fruits embody healthy food, sun, summer, smoothies. They look innocent. At first we thought about cocktails, but it was too close to the alcohol context. Linked with a notion of love and sex, our final message could be misunderstood. Each fruit represents a desire. But hey, these are pure hypothesis, let’s destroy this sweet idea with real users feedback.
3. It’s prototype time
We started to ask ourselves what kind of feedback we wanted from potential users. Is it usability? Nah, too early. Is it UI? Mhhh, a little bit. What we want to know at this precise step of the process is desirability. Are the concept and our visual solution solving a problem potential users encounter? Are they appealing?
It was more strategic to focus on the core elements to get this feedback: the fruits selection and the fruit discovery. People in the street don’t have 15 minutes to speak with us; we wanted them to perceive this feature. To be efficient and to avoid the users to discover a brand new app in less than 5 minutes, I copied Tinder UX. So not only they focus and the new features added to an existing app, but they also project themselves in a context of dating app usage. What a loss of time if they were to learn the app from scratch.
I challenged myself to deliver the prototype in less than one hour. I knew that if we didn’t go into the street we would try to polish a little bit. It is time-consuming for a concept that maybe didn’t solve any problem. I made some sketches on our whiteboard then grabbed the UI kit TETHR from InVision. I borrowed some artwork from Scott Tusk and MadeByElvis, and then added my own element. TA-DA! One hour later we were in the street with a prototype on our device.
4. Testing sessions: going to the street now we here
During three days in a row we allocated 3 hours to talking to men and women fitting our user target. We had a survey but depending on the answer the conversation changed and we got some great insights. We also went to a company office working with us to get feedback from their employees. The result of the research grew into 150 Trello cards. I sorted these cards to highlight patterns leading to iterations on the product.
We validated the hypothesis stating that fruits conveyed a healthy and cute image. The description of each fruit was a success as we saw potential users laughing while reading it. We understood the great potential of the “IceBreaker feature” we wanted to implement. A user can send a suggested question with a binary answer into the chat. Then both individuals will see the answer of each other only when they both answered. We decided to put in place gifs to the chat. Yet we decided to post-pone this modification since it would need too much time from the tech team.
5. Delivering the product
We had 2 months to launch the product. Putting a timer is a valuable help since it increases the notion or urge and force us to make decisions. We used a matrice to decide which feature we were implementing or not. It was a matter of balance between impact and ease of implementation as parameters. Our CTO went with React.JS framework. Since we already restrict the use of the app to the area of Paris, we didn’t want to also restrict it to iOS. React enabled us to develop faster for both systems.
6. To Beta or not to Be
When we went to the street the product was at it’s initial step. A humble prototype that provided us great insight. The product was almost delivered. The team decided to send it to the store without telling anyone. We organised a party at a pub next to our offices in the city during three nights in a row. Users would get discount on drinks if they downloaded the app. Once again, we were confident with our fruits branding. We saw people laughing at the fruits definitions and sticking the fruits stickers on their phones!
We highlighted critical geolocalization bugs and corrected them during this event. Users raised awareness of the frustrations they had. For example: not finding their facebook friends on the app. What we thought was a good idea could also be a pain.
During the 11 days of beta we gathers 3000 users and achieved 159000 swiped. We then decided to release the product.
7. Preparing for future feedback
We don’t want to rush the product. We developed our MVP in 2 months and it passed it’s 10 days beta with interesting results. The app is only available in France, more precisely in Paris. It enables us to do better user analysis. We track users logging from another city. It helps us to determine where there is demand for Fruitz outside from Paris. Then we can scale our product and communication to others cities.
Julian, our CEO, talks to users through the app chat. He answers about 15 users each day providing us feedback with great value. We rewarded users who discovered critical bugs and crash since they avoided us a lot of work!
Julian and I are giving talks in business and communication schools as ESSEC as well as design schools such as Campus Fonderie de l’Image, École Multimédia, e-artsup, ECV Digital. It’s another good opportunity to meet with students interested by Fruitz and also how they would have done it better.
Conclusion
As a designer I enjoyed this design thinking sprint. Making quick decisions and developing strategies to gather valuable informations is crucial. I’m always amazed. Once a team starts to dig into a problem and make research about society, the team ends up with more problems and highlights human problematic. When we started this project I didn’t intend to focus so much on sexism in society, but it became part of our long term vision. And what a human and design challenge when you are a male designer raised into this coded society. It’s fulfilling not only to work for a refreshing product. To put our design and engineering skills at the service of great causes.
