Tinder

Although dating apps have become a rather ubiquitous part of our lives today, the overall user experience unfortunately still leaves a lot to be desired. I led a team of UX Designers and Researchers in re-designing the user experience for Tinder over the course of 4 months.

Using the British Design Council's Double Diamond Design Thinking Model as our guide, we started the project with a deeper dive into the Problem by putting together a User Research Plan.

User Research Plan

Our analysis of the subject matter convinced us to apply a Qualitative approach to gathering data, with Surveys and Interviews becoming our leading choices for research methods due to our various time and budget constraints. We designed research questions that, when boiled down to their cores, essentially asked variations of the following 3 questions:

• What goals or needs do people have when they use dating apps?
• What constitutes a positive experience on dating apps?
• What in the design of dating apps makes them more or less conducive to positive dating experiences?

If the Discovery stage was used to develop insight into the problem, then it was during the Define stage where we were able to hone in on what the problem was (exactly) and who we were trying to help (exactly).

Detecting Common Themes

Affinity Diagramming helped us zero in on recurring themes, which allowed us to organize those themes into clusters.

Defining the Audience

In similar fashion, we analyzed our Survey data using affinity mapping as well in order to figure out who our intended audience actually was. From this analysis, we created the following Persona below:

James represented the nearly half of our respondents who identified as Male, under 30, or just seeking something casual. Our other persona, Anna (not pictured), represented the other half who identified as Female, over 30, or seeking something serious.

Synthesizing the Information

With a clearer idea of what the problem was and who we were trying to solve it for, we conceptualized what a typical user experience journey would look like for someone like James.

Developing Key Insights

As we prepared to move into the Ideation phase, we converged upon the following insights in order to help us deduce potential opportunity areas that we might want to focus on going forward.

Identifying the Problem

Our respondents wanted us to know that it wasn't just 1 or 2 problems that made the experience so poor but a combination of several (all seemingly working in tandem to create a sort of "dating experience vicious cycle"). As such, my team members became split on how to best tackle what was now developing into a rather complex and multifaceted issue (and, therefore, multiple viable potential solutions).

Ironically, I found I was actually able to use this split in opinions among my teammates to our advantage by allowing a bit of the Divergent Thinking process again.

• In specific, I asked each of them to argue their specific angles by creating their own How Might We statements (as many as they wanted) with which we could all better understand one another's positions.
• When we came back together to share our statements, we found it much easier to not only understand each other, but prioritize collaboratively and, in doing so, ultimately converge upon our final How Might We statement as we entered our Ideation phase.

What made the dating app experience so demotivating, we came to see, was not due to users not getting matches but because the experiences that followed after getting matched were so poor.

• It didn't really matter if the person you swiped right on failed to choose you too. Oh well, is what most users would think, as their momentary sense of disappointment evaporates.
• What led to real disappointment, burnout, and fatigue with the apps came after users were matched. Some matches would say terrible or weird things. Others were slow to respond. Or they were too shy to start the conversation and/or believed it was the other person's turn instead.

We didn't know how (or if we even thought it prudent) to moderate what people said in their conversations after matching. But those key moments of uncertainty that existed between users during their interactions with one another? Well...that, we could definitely find a solution for.

Drawing upon our findings from the previous two stages, we began our Development phase with some brainstorming and sketching. Towards the end, we converged upon a single idea and designed storyboards and scenarios to provide illustrative support.

Brainstorming & Sketching

Using our Key Insights as a guide, we came up with the following sketches as part of our early ideas:

• Behavior Badges: Perhaps profiles can come with badges that users earn through repetitive good or bad behavior.
• Feedback System: Users wanted a way to voice their thoughts and concerns, whether it was to other users or the company.
• Dating Coach: Maybe users are just unaware of the proper dating etiquette when it comes to online dating? What if they could be coached into realizing some of the mistakes they may be making?

Scenario & Storyboarding

We had a design vision at this point, but to complete our hypothesis, we created the following scenario and storyboard in order to illustrate how we imagined the experience could look like with our new solution. We would bring this idea to test in the next phase.

The final Delivery phase focused on prototyping, testing, (learning) and refining as often and quickly as possible. We knew we were on the right track, due to our careful analysis over the previous stages, but could we actually design the right thing as well?

Paper Prototype (Iteration 1.0)

We designed a quick low-fidelity paper prototype to provide a general sense of how the interactions of our new feature would work.

This first prototype was only meant for our own internal use, and it helped us spot a few discrepancies here and there early on.

Balsamiq Prototype (iteration 2.0)

We fleshed out the paper prototype with our second version, which we built using Balsamiq so that we could incorporate interaction elements and test its usability with potential users. With this second iteration, we began to hone in on our Recommitment feature (which we believe helps push interactions past stalemates) as well as our Feedback feature (which provides users with a sense of closure).

Usability Testing

Due to time constraints, we were only able to test with 3 users. (In future iterations of this project, we would recommend testing with more users as well as more often.) One of the most surprising takeaways from this was how specific features that may have seemed desirable in theory were actually not very well liked when it was put into practice.

So what did we learn?

• Our data told us that users were interested in some form of mandatory feedback option (so that matches can know where they stand). During testing, however, users realized that they themselves could be on the receiving end of some potentially hurtful feedback, so they changed their preference to just making the feedback optional.
• Users overwhelmingly liked the presence of a "third-party facilitator" in their interactions. This automatic "dating coach" would send various prompts at specified times in order to "nudge" the interaction forward.
• Although users liked the concept of behavior badges in theory, seeing it in practice made them feel it was a little "punitive." Even though having more information on their potential matches was preferable to having less, they felt that the behavior badges was just a bit too far.

Figma Prototype (Iteration 3.0)

Using what we had learned from our usability testing, we designed a high-fidelity prototype using Figma. Click on the image below to try it out.

As this was my first time filling the role of being a Project Manager for a UX project, I felt that I learned quite a lot about myself and my own management/leadership skills (in addition, of course, to improving my design thinking skills as well). But if I had to select just a few learnings and discoveries that really stood out to me during this project:

Make the Process Yours

One of the biggest concerns I had as the PM was whether I was adequately adhering to the design process we had selected for this project (in this case, a modified Double Diamond). I could clearly see the logic of the model (such as why a Convergent Thinking process would make sense at specific times, or why it was ok to end the Define stage without having a solution in mind). But even the best models can't possibly account for anything and everything.

• For example, while the Double Diamond model is a linear "waterfall" process in that steps are sequential, build upon what came before it, and forward-moving, there were times when we revisited previous steps because of roadblocks that forced us to recalibrate our situation.
• At specific points along our process, I would have the team use the exact opposite process (Divergent vs Convergent) because I thought it may help push us past whatever standstills we had come to.

In those moments, I wasn't confident at all if I was leading my team in the right direction and so whatever successes would come as a result felt like flukes. It wasn't until we had nearly completed the project that I felt more comfortable about my relationship with design models, specifically in regards to modifying them according to the needs (and whims!) of the project (and the team).

Don't Cut Corners

One of the "stalemates" we came to as a team occurred at the end of our Define phase when we were trying to converge upon (more specifically define) the problem. By this point, we had thoroughly dissected our data and distilled them down to just a few specific and actionable insights. However, this was also the point at which we came to find that we each wanted to take the project in different directions, due to each of us having interpreted the "spirit" of the insights in very unique and, hence, different ways.

I felt a bit lost here. As the project manager, I wanted to steer the project forward in some capacity, but as a UX designer, I also wanted to make sure that we were "doing the right thing" before moving onto "doing things right."

There was some pressure to put things to a vote (in order to break the stalemate), but I inherently felt that turning this into a popularity contest might not necessarily be the right way to figure things out. In addition, I wanted everybody to be wholeheartedly onboard with whatever decision we made, not have half of them merely following along reluctantly.

So with no clear idea of how to push the needle forward, then, I had us all take a step back instead. (Although this ended up working very well for us in hindsight, at the time, it felt like the project was regressing and we wouldn't make any of our own deadlines.) We revisited the data to see if we could form different affinity groups that could lead to new insights. And as a result of this exercise, each of us ended up adapting or changing our original interpretations (perhaps due to being able to see how easy it is to unknowingly inject biases into our interpretations) and converging upon an unanimous narrative.

Sell Your Angle

One of my teammates, who I found to be very perceptive and thoughtful, connected the dots on things much quicker than the rest of us on the team. While having this kind of person on your team may seem like quite a boon, what actually ended up happening, more often than not, was that it put her at odds with the other members of the team. But for the sake of teamwork and collaboration, she was perfectly willing to defer to the decisions of the rest of the group and go along with whatever the majority decided.

I have always felt uneasy about making decisions solely according to majority rule because, as we all know, there is no real correlation between having a majority's support and being the right thing to do. In addition, I knew she must have had good reason to raise her point due to what I had observed about her while working alongside her. And oftentimes, all it took was a little bit more explaining or time for the rest of us to catch up to her point.

And so I learned two things from this particular experience:

• As a Designer: Know how to sell your "angle." In collaborative, team-oriented settings, it's tempting to go with the most popular idea (or, as I sometimes call it, the "least disagreeable idea in the bunch") but that doesn't mean it's necessarily the right one. Speak up and let your idea have its moment in the spotlight. It might be the one that makes all the difference.
• As a Project Manager: Push teammates to extrapolate on their ideas, no matter if they are the only one to think it's right.