For the last edition of our UX Insiders expert interviews, we sat down with Ivy Mukherjee, former Product Design Manager for the online dating app Bumble, who walked us through designing applications that facilitate human connection.
Ivy’s been in this space for over nine years and has worked across several different industries within the tech ecosystem. Recently she led and managed Bumble’s Product Design team. Bumble is a mission-driven company that aims to create safe, healthy, and equitable relationships on both platonic and professional levels.
She also walked us through her experience of being a thought leader and how she was one of the founding members and lead designer of the Emerging Initiatives team.
Check out the best bits from our talk below or watch the full webinar.
Ivy’s philosophy as a designer
First things first, there are two primers of building a scalable and impactful product.
- One is finding joy in connecting the dots. How can you be a good designer? If you can understand why people do the things they do (be it related to a product, people, or processes and behaviors), you can form a lot of patterns and get very good insights.
- And the second part is more about not being able to grow alone. So things like how to build and nurture these work relationships as a leader.
How Ivy got started in the UX space
I did four years of Multimedia studies at university. I liked doing illustrations and graphic design. So I started as a graphic designer in lots of consulting or advertising agencies. I was good at my job, but couldn’t see myself doing that for the future.
And one day, I saw one of the artists whom I used to follow on Facebook. He posted that there was a fellowship opportunity that was happening in Israel. So I applied, got through, and went there for three and a half months. That was the first time I got to know about the startup ecosystem, the tech industry, what exactly a product is, etc. So I started working on some projects and that’s when I realized two things:
- I loved it because I could find a purpose: This is whom we are trying to do it for. And this is how it can solve a problem.
- I am not bad at what I do. So why not go for it?
So I started applying to some startups back in India and got my first UX role for a company called Blinkit.
The Night In feature project for Bumble
Bumble tried for quite some time to target Gen Z users and establish itself as a distinct dating platform where the fun happens. With this user base, we had the potential to add more value to bring them on board. We also saw that over 70% of Gen Z users liked using videos and immersive platforms to connect generally.
So the hypothesis was: Can we do a game-based interactive video call (which can be a great opportunity for user engagement)?
Bumble users kept saying Bumble was not fun enough like TikTok, for instance. A lot of people wanted to do vibe checks before meeting their match in real life. A lot of people rightfully also said that in doing only video calls, things got boring after a while. This was a huge opportunity for Bumble.
The duration of the project was just four to five weeks of design, which is not a normal situation. We wanted to adapt to user needs as fast as possible. Hence, this is the right time we had. Currently, the feature is live in six countries. It has a very good adoption rate and we acquired a Gen Z startup as well.
So my role was helping define the strategy, conceptualize the solution, define the design, the whole user experience from inception to launch, and a lot of the things under the sun. Later, I hired two more product designers to grow the product after the MVP launch.
Note: Ivy walked us through the entire process and funnels she used for this project so be sure to check out the entire talk.
How the design team worked together
Because the whole team was very new to Bumble and working together for the first time, there was a bit of a back-and-forth. Everybody had their approach to work so it took a bit of time for us to effectively collaborate with each other. That’s when I realized this was a great time to establish a “way of working” framework for all stakeholders. This acted as a foundation on what to expect from each other in different stages until we launched.
Once we set those expectations, we chose the Kano model as a prioritization framework to scope out the work and keep everyone accountable. And then the full team managed to brainstorm and come up with game ideas for the first dates under this feature. Then we ran a survey using these ideas with our potential users. Trivia won by 80% votes in the user survey results. We also gathered feedback from our team. While all of these things were going on, we did multiple concept tests and user testing with real users.
How were user safety and accessibility prioritized for Bumble’s projects?
We wanted to reassure people they’d always be in complete control of the whole experience. One part of safety is not feeling stuck with the game or with the person at all. So things like showing users how they can end the game or a call whenever they’re feeling uncomfortable.
And the second part was that they could even switch off or on their video or audio call at any point, like if they’d feel there was any disturbance in the background or somebody was knocking on the door. Plus, we also made sure to remember users’ preferences for future interactions with their matches.
We also received feedback that the app wasn’t inclusive for people using screen readers. There was also no ALT text for such a visual-heavy experience. And it was not just this feature. The entire app went through a complete accessibility audit afterward.
Tell us a bit more about the research aspect of the project
For this project, we had a user researcher from the start. That initial conviction came from a mixed methodology of qualitative and quantitative research. It’s always good to rely on different types of research because you want to mitigate bias as much as possible.
The user researcher and I held daily brainstorming sessions to decide on the kind of research that was required. Or we would build some form of wireframes.
We always wanted to know if we were building in the right direction or not. So we did concept testing on other gaming ideas as well to see how people would react. It was really important to ask the right questions and recruit the right users as well.
As an example, when we did our first beta testing in Canada, we looked at things like:
- How are they going through the feature?
- How many people are clicking on parts of our funnel?
- How many people are going through the funnel we had established?
- What’s the completion rate?
Handling the friction challenges of Bumble projects
Everyone should know that healthy friction is supposed to happen. One of my managers used to say “Don’t Argue To Win, Argue To Learn”. You’re not supposed to know everything. In this particular project, product managers weren’t that big of a challenge. It was mainly the operational side of things. Our team was very new so we didn’t know what our working model should be or what we could expect from each other.
Another challenge came just because we wanted to elevate the brand identity. This meant a lot more work for the engineers and the design systems part as well. We realized we weren’t just building this feature alone. We were going to use everything for different use cases within the app’s several other flows. You want to have buy-in from that aspect because nobody wants to do a lot of patchy work just for one feature. We had to build ten new components. Imagine those components not getting used. Nobody likes that.
How do you manage the expectations around timelines if they’re a bit unrealistic?
You don’t want to decide upon a timeline that people won’t know about. Generally, the timeline is something that you get to work on with the product manager and your day-to-day working buddies: engineers, researchers, content designers, etc. So it generally becomes realistic.
But not meeting the timeline which we agreed upon happens to all of us. What happens most of the time is that we uncover more facets while working on the designs or going through research. So you’ll always need some buffer time.
We might have assumed a project was a pretty simple straightforward thing, but there were more nuances to gender pronouns or rankings, for example. We worked with third-party people and realized that this was not how it should be done. So one week got added to the timeline. If you’re a good designer with experience, you’ll realize that if something takes, for example, two days for you, you’ll never want to say two days. Say three days or three and a half days to have some buffer for yourself as well.
How did you get the feature to be accepted in different countries? And how did users over the age of 25 feel about it?
We built it mainly for Gen Z and young millennials. But it’s open to everyone. So if you want to use it, go for it. The caveat is that it’s only for people who like video calls.
So what Bumble realized is that you can’t build every feature or every tool for every single one of your users. It’s not possible. Not every size fits all.
But how can you still have a meaningful base of users for that product? People wanted more games or at least more questions so we began building that. Our users generally liked doing something new and refreshing with a match on the app and just having a good time. So it was always good to get positive feedback but it was simply still not for everyone. If you don’t like video calls, you can’t do this thing.
