Problem Space 

Music is ingrained in our culture. Around 90% of the world listens to it. We may not listen to the same things, but the mere act is useful to us in one way or another.

At its core, music is a means of forming and strengthening social bonds. However, with the recent invention of streaming platforms, everyone gained access to almost every song in the world. While this has changed music discovery for the better, it has also made listening to it a more isolated experience. 

Research and Insights

As research shows, people’s emotional responses to music are intricately tied to the other core social phenomena that bind us together into groups. To put it simply, the pleasure we derive from listening to music results from our need to connect. (Loersch, C., & Arbuckle, N. L. 2013.)

In a survey we did, 73% of respondents stated that other people had a significant influence (rated 6 or higher out of 10) in developing their music tastes. Throughout their experience of listening to music, there’s a tendency for users to depend on other users in finding songs that they like.

For example:

  • 55% of respondents cite other users’ music the most in discovering songs they like (either personal or other user playlists)
  • 75% of respondents are interested in seeing what other peers are listening to
  • 98% of respondents chose factors such as popularity and comments as the most useful criteria with song recommendations

Ultimately, we realized that discovering music we love is more engaging when other people are involved. The current problem is that streaming platforms lack the functionality to enable these social interactions between users, whether that be sharing recommendations or discussing songs in general. 

User Pain Points and Feedback

However, in addition to this insight, after speaking to several respondents, we learned that they are particular with the people that they share music with. It seems that interactions over music tend to be more personalized because factors such as taste, reactions, and opinion come into play. A respondent compared the experience to a “shared memory” because “in person they see how much i love it, and even if they don’t, they often download the song anyways.” 

Similarly, there was the pain point of creating a safe space for users to openly discuss music without being criticized for their choices. A respondent stated that they “would like everyday discourse about music to be more mutual. I often avoid discussions about music with friends, as I always feel that the other person is coming into the conversation with the sole focus of pushing their taste on to me.” 

Landing on the Solution

Explanation of the Solution

With these issues in mind, our primary takeaway was that people feel the need to connect over music, but only with those they trust. This insight would be our product’s north star and would inform our features the most.

Core Features: Post & Comment

We chose to build “Post” first because most interactions within the app happen through this feature. To best recreate the experience of sharing music in-person, we wanted to make posts as interactive as possible. To do so, we used a two-sided “card” format where we could implement multiple functionalities such as music previews, Spotify links, likes, or comments within a single post.

Feature#3: Rooms

While the post features allows people to share public recommendations, they’ve also emphasized how important a personalized experience is for them. In one of our interviews, they stated that their recommendations are “more suited for certain people…”. With the “rooms” feature, we wanted to create personalized chat rooms where users can exchange songs and messages with one another. That way, we create a more engaging way to discover music and preserve the intimacy of sharing songs at the same time.

Pivot#1: Post

In building “Post”, we ran into issues which prolonged our sprint for the feature. Emmanuel was uncertain about including music previews especially with the Spotify API we were using. He was concerned that Spotify’s playback functionality on multiple devices could cause bugs when users tried previewing a track on our app. However, the team thought that in a music social networking app, it was crucial that users could play music in any capacity, even if it was just a few seconds. As a result, we decided to prioritize building this core feature, even if it meant shortening our timeline for the others (Rooms, Comments).

Pivot#2: Comments & Profile

By the time we finished the “Post” prototype, we had roughly 2 weeks left in the program. Because of the time crunch, we looked at our high-fidelity mockups to evaluate which features we could still ship for our MVP. The “Rooms” feature was technically the most challenging to implement, so we ultimately chose to cut it from our initial release. From there, we chose to focus on building the “Comments” section since it was naturally part of the “Post” feature.

Design & UX

The creation of Jukebox started with a lot of brainstorming sessions to align the team’s vision on how the app should meet user expectations. As a team we primarily used Figjam to flesh out initial ideas and iterated on them further in Figma. Everything about our product from initial user flows, mockups, or even our brand logo underwent the same process.

Mariia decided to follow simple and minimalistic patterns in designing our product. We paid a lot of attention to following principles of simplicity and progressive disclosure, allowing our users to navigate the product without any information overload. Our goal was to encourage users to socialize within the app. We used vibrant colors to highlight community features, but also implemented minimalistic designs to not distract them from the interaction with friends. 

To test our final solution we’ve applied Guerrilla testing, which is a type of UX testing that brings quick, affordable and actionable results without a complex testing environment. Mariia tested our Figma prototype with a random sample of users. Fortunately, users immediately understood the app, but just needed clarity on how to interact with it. In the new version, we made some minor but important changes to fix the user experience:

  1. Create onboarding elements inside the home interface to help users learn the instruments and methods of the app
  2. Change the icon representation of “no preview” because it caused a confusion
  3. Decided on the final layout of a “Post” card, making it clean and minimalistic 

Here is the final iteration of the application interface that was designed in Figma with a lot of cross-collaboration effort from the team.

Technical Tradeoffs

In terms of the technical constraints, Emmanuel wanted to maximize accessibility and user experience because we were building a social platform. That’s why we decided to develop a mobile app.

Furthermore, for our MVP, Jesse proposed developing primarily for Android devices first. They could only test builds on that environment, and we also thought that it was too costly releasing an app on the Apple store. 

Finally, we also decided to only onboard Spotify users for now. With a 31% market share over music streaming platforms, we thought it was the most lucrative option to source our initial users. In addition to that, it was one of the easier APIs to integrate with in order to import the basic elements of our app such as a music database, song previews, and user profiles.

Future Steps

For the future, our primary focus is to build the “Rooms” feature since this is something proprietary to our app. In addition to that, we also want to make further use of the Spotify API and add functionalities such as exporting songs to a playlist, or displaying a user’s favorite artists/genres on their profile.


Product Manager Learnings:

Martin Guevara

  • Iteration is everything: it’s better to ship something in increments rather than as a whole because without execution, we end up planning over nothing
  • Communication is crucial: especially alignment, because everyone’s work informs the other’s. It creates constraints for our work and structures it
  • Brevity: In a cross-functional team, time is our most valuable asset. In meetings, I learned to be concise and ensured I did not isolate anyone in our conversations.

Designer Learnings:

Mariia Kraisman

  • Share what you know: We are here to learn so that’s why constant exchange is a great way to learn faster and understand the processes behind the scenes in your team
  • Connect with community: It was amazing to get to know other designers from Co.lab and discuss our work and progress during the program

Developer Learnings:

Emmanuel Otounye

  • Ideation & Research: Being involved in the processes leading to implementation is crucial to understanding the problem space
  • User Experience is Key: Always think about the product from the user’s perspective and choose the right combination of tools to provide that experience
  • Communication is key: Having a daily and weekly stand-up helped the team gain a clear-box view of the problem space

Developers Learnings:

Jesse Abuaja


  • Collaboration: In a cross-functional team, it's important to work together and collaborate effectively.
  • Continuous learning: Being a developer in a cross-functional team requires continuous learning to keep with new technologies and approaches. 
  • Flexible: it's important to have a flexible mindset and be willing to adapt to changes in the team's direction or focus.

Full Team Learning