Context

This was the third and final project for my Google UX Design Certificate Program.

Problem

Playing music with friends is fun, but it’s a challenge to find people who play the right instrument and share your musical taste and skill level.

Solution

To help musicians connect with each other, I envisioned a social media platform for musicians, combining the traditional feed structure of Facebook with the matchmaking system from dating apps.

User Interviews

Before I began designing a social media solution, I interviewed two of my musician friends from college. By talking to real people, I could:

I was surprised how enthusiastic my musician friends were about “social media for musicians,” and how similar their vision was to mine. Based on these two conversations, a social media/matchmaking app looked like a great solution to help musicians connect with each other.

Pain Points

My interviews also helped me to identify specific user problems before I had even started to design solutions:

User Personas

Inspired by my interviews and guided by my experience inside the music community, I created two user personas. The goal was to distill the wide variety of needs, desires and behaviors in the music community into two characters, increasing empathy and aiding imagination.

Esteban

Age 19Jazz Saxophonist

Esteban learned saxophone in high school, and he loves to play Jazz. Unfortunately, his friends don't play instruments. He's looking for a mobile app to find other young Jazz musicians in his town.

“Why is it so hard to find other people my age who want to hang out and jam?”

Maria

Age 43Cellist

Maria is an amateur cellist who wants to get back into playing casual chamber music. She is hoping to find a website that can connect her to some other chamber musicians.

“Yes, I miss playing cello, especially with my friends. But most chamber music programs are just too expensive and too intimidating.”

User Journey Map

At this point, I needed to think through the step-by-step specifics of how someone would use a social media app for musicians. I needed to map out a user journey.

Three Challenges

As I was creating this user journey map, I discovered three major design challenges. First, I realized it would be difficult to solicit information about the user’s musical taste and ability without being tedious or invasive. Second, I discovered that the matchmaking feature and the feed/post feature were independent. In other words, someone might want to browse or post content, or they might want to make new friends, but there was no reason to assume that one person would be interested in both features, or that most users would use one part of the app before the other. Third, and this was the big one, how was I going to match musicians together?

The Big Challenge

So, how to match musicians with each other?

The most direct solution was this: show the user a screen with a selection of other user profiles, curated based on location, musical taste, instrument preference, and musical ability. The user could then select and direct-message the most promising match from among the profiles presented. Immediately, this raised questions:

Preliminary Solutions

While I was thinking about these questions, I came across a case study for a roommate matching app. The article proved immensely helpful, as they faced similar challenges. Among these challenges, one stood out: how to make reaching out to strangers on the internet comfortable, even automatic. With this challenge in mind, I began to answer the questions I had posed.

The “connect” tab in the app would show just three potential matching profiles per day. When a user “likes” a profile, it goes into a list of liked profiles. When a mutual like occurs, the two users would be added to each other’s friend lists, and the app would automatically start a direct message between them. As users accumulated friends, they could start group chats with multiple members. This would also allow users to introduce mutual friends to each other.

The home feed would show posts of friends by default, but you could “unfollow” friends to hide their posts (like on Facebook). Conversely, all posts would be public by default, so that one user could get a feel for another by looking at their post history. There would also be a way to explore posts from the public on the home feed, filtered by location and musical genre.

Wireframes

Armed with my ideas, I set out to wireframe the basic skeleton of the app. I decided to stick to a simple, three part structure: the home feed, the matching feature, and a messaging center. I also wireframed out a set of onboarding screens. At the top of my mind was how the app would collect, aggregate and distribute information about each musician and their preferences.

Low Fidelity Prototype

Once I had a set of basic screens, I strung them together in Figma to create a low-fidelity prototype. Try it out below:

Usability Study

I ran a small usability study with three participants. I wanted to know whether the onboarding process was too arduous, whether the overall layout of the app made sense, and whether I had forgotten any essential features.

The study proved useful. I came away with several smaller insights, but I also realized I needed to rethink the onboarding process and the matchmaking system.

Rethinking Onboarding

The onboarding process was not only long and tedious, it was unnecessary. Only a small amount of personal information was actually required to start using the app (to explore and post). Most of the detailed information about each musician was only necessary when trying to match musicians together.

My solution: Let users skip to the good part.

We could get basic information from a third party account (e.g. Google sign in), and allow users to start exploring the app right away. More advanced information could be filled on each user’s profile page as it became relevant. Developing a personalized profile page is a lot more exciting than filling out forms of information.

Rethinking Matchmaking

Rating other musicians is awkward, and too far removed from the goal of actually playing music together.

My solution: Focus on matching intent, not people.

The new system would work like this: users could create open invitations (later termed “Jams”) to play a specific kind of music at a specific location and at a specific time. Other musicians could browse these invitations and “join the jam” if they found one that looked appealing. Once a jam had some musicians in it, the original poster could start a group chat with any or all of the members.

Minor Insights

From the usability study I also gleaned some minor insights related to the app’s UI:

I addressed these problems in my new designs.

Information Architecture – Updated

The app still had a three part structure (feed, connect, messages), but the matchmaking system was now built around the concept of “Jams” rather than trying to match people directly.

High-Fidelity Design

After much experimenting with colors, I settled on a graphical theme. I wanted the tone to be friendly, maybe even exciting, but still be closer to formal than to juvenile. I reworked the whole app in high fidelity, adding in details that I had left out during wireframing, and adjusting my designs based on feedback from my usability study.

Dark Mode

After I had created light-theme designs, I was inspired to create a dark-theme as well. I was careful that UI elements conformed to WCAG accessibility standards for both light and dark themes.

Desktop Designs

Once I had worked out what the app would look like on mobile, I created designs for a responsive website. I wanted users to be able to use the app on multiple device types.

Let's Jam Desktop design

Project Impact

Over the course of the project, I received multiple comments from study participants expressing their wish to see this app in the real world. If this project reached the app store, people would download it.

Let's Jam App Mockup

Conclusion

Among other things, this project taught me the power of minimizing user choice. When users have to spend time trying to decide how to use an app, it creates friction that makes users want to leave. Good designs anticipate what users want so that they don’t have to spend time thinking.

Despite all I learned and all the designs I created, I still feel like this project is just beginning. If I were to continue working on the project, I would love to: