Design Challenge: Music Player App

The Problem

My challenge was to simply “design a music player app.”

No instructions, no guidelines, nothing. It was up to me to decide what problem or concept I want to build the app around. Some limitations that I had to deal with:

  • Technical restrictions — no ludicrous ideas. Try to work with an idea that doesn’t require rocket science.
  • Time — I had just under 6 hours to brainstorm, wireframe, and build mockups before I had to present my ideas.

I first started tackling this challenge by looking at current music players: Spotify, Apple, SoundCloud, and Google Play.

Spotify • Apple Music • SoundCloud • Google Play Music

Features they had in common were: curated playlists, song radios, and some sort of recommendation feature based off an algorithm using user preferences. Most designs followed standard iOS protocol except Google Play which, of course, had to follow Google’s Material Design guidelines.

Here’s where I started doing user research. I surveyed 40 of my friends (1-on-1 and group chats through Messenger) to find out what kind of features they thought were missing from Spotify and Apple Music. Here are some of the requests I got:

  • Making playlists on mobile is a pain — can you make the playlist creation experience easier for users?
  • I want to be able to share songs and playlists easily with my friends, without having to send them a link.
  • I want to see my own listening metrics.
  • I want to see what everyone else is listening to so I can talk to people who listen to the same stuff as me.
  • I want to be able to collaborate on playlists with my friends easily.

The Solution

I saw two common themes between the features — Discovery and Social. College students seem to want new ways to discover music through their friends or some sort of recommendation feature, and a way to seamlessly share music with their friends. Analyzing this even deeper, I saw that I could build a music player app around the concept of shareability. The key is to make it apparent on each screen that the call to action is to share content with their friends. This way, users can discover music through their friends that share songs with them, or through other built-in recommendation features.

I laid out my app’s features using a mind map, categorizing them as either discoverability or social. Given the limited time, I only noted down features that were important and that tied together the concept of my app, so I may have missed typical features like Search, Library, and the Home screen.

Excuse the terrible handwriting and organization

Our Goal

The goal of this app from a business perspective is to get users to create sharable content. The two core features that will help us accomplish this goal is playlist creation and party queues.


We want to make it as easy as possible for users to create playlists so that they can share them with their friends quicker. If users curate good quality playlists, they can gain traction on it by sharing it with their friends and get followers. Eventually, users could monetize their playlists by charging their followers a subscription fee, which creates a business model for this app.

Messy wireframe for playlist creation

This is a typical user journey for creating a playlist:

Tap Call To Action → Create Playlist → Type Name → Add first song → Receive song recommendations based on what songs are in the playlist → Keep adding songs by searching or using recommendations until playlist is complete → Share with friends

By giving users song recommendations right after they add their first song, we make the playlist creation process a lot easier. We remove the need for users to navigate back to Search, type the song title, and clicking two or three times before adding it to the playlist. Since playlists usually follow a theme or genre, the recommended songs will be relevant for users and speeds up the process to merely one step.

Party Queue

In addition to playlists, we want users to share music with each other in real-time using a party mode queuing feature. I called it Party Queue.

Here’s a use case: let’s say you’re having a get-together with 10 of your friends, but not all of you have the same music taste. Instead of you (the host) having to collect song requests throughout the night, you could invite them to collaborate with you on a real-time queue. Invitees and the host can add songs to the queue, but only the host can re-arrange the order of the queue or delete songs from the queue.

I explored a number of web-based solutions for this same problem, but none on mobile. So, I decided to sketch up a rough user flow for this interaction.

Wireframes for the party queue user follow

Hosts would hit the Call To Action on the bottom bar, open up a queue and invite their friends on the app. The host and invitees get the ability to add songs to the queue by pressing the confetti-looking icon on any song card. Once songs are added to the queue, the host has the option of reordering the queue, selecting a single song to move to the top of the queue, or deleting multiple songs. The party queue interface can be hidden by pressing the chevron in the top left corner, minimizing it above the bottom nav bar.


At this point in the challenge, I had only two hours to create my mockups. I decided to focus on only the party queue user flow — the most unique feature of the app. I built the necessary screens for users to invite their friends, add songs to the queue, and select and remove songs.

The first screen shows how users see playlists normally. Right away, you’ll notice the call to action on the bottom bar. When the user clicks this, they will be presented with the option of creating a new playlist or a new party queue. I made this the biggest call to action because it aligns with the business goal of pushing users to create playlists to share with their friends. On the top right of the screen, there is a clear Share icon which will send this to a friend on the app.

The second screen illustrates the process of inviting friends to a party once the user creates a queue. Clicking the (+) button will select the friend, and hitting Invite on the top right will add them as a collaborator on the queue. Something I would change about this screen if I had more time is to remove the bottom nav bar, and replace it with an invite button. This way, this screen would let users work from top to bottom instead of having to reach back up to hit Invite.

The third screen shows how users would see playlists once they’re a host or collaborator of a party queue. Hitting the confetti icon on a song will add it to the party queue. Above the bottom nav bar is the minimized party queue interface.

After hitting the up chevron on the minimized party queue, the interface slides up to reveal the fourth screen. Collaborators are shown in a carousel, with (-) buttons if the host wishes to delete them as a collaborator (maybe their music taste was horrible). Deleting a collaborator will also remove the songs they’ve queued up. On the top right, you’ll see an icon that lets you invite more friends to the party in case you missed any (clicking this would bring you back to screen 2)

The circles on the left of each song are an affordance for selecting it. By selecting one song, hosts are given the option of playing next (moving the song to the top of the queue) or removing it. If the host selects multiple songs, they are only given the option of removing them. The reason they don’t get the option to Play Next is because users may get confused about how the songs get moved to the top. Will it be moved based on which songs were selected first? Or based on the order of the songs in the queue? Besides, it’s unlikely that the user would want to “play next” more than one specific song anyways, especially in a real-life party setting.


Here’s one improvement that could’ve been made: I experimented with making the “remove” bar completely red, which makes sense because the colour red implies some sort of delete function. However, I can’t make the bar red when “play next” is also shown because then the colour would not imply the correct thing. So the issue was deciding after selecting more than one song, whether to change the colour to red or not. I ultimately decided against it, but I was given feedback that this would have been the best screen I built in those 6 hours. If there was more time, I would’ve tried to find another way to display this.

Lessons Learned

Key takeaways from this challenge are to really be time-sensitive. I spent way too much time listening to feature requests from my friends when I should’ve narrowed down the feature set within the first hour. With challenges like this, it’s better to put more work into the final product (3–4 screens of UI) and working on little details including colours and making everything pixel-perfect.

Another thing to think about after designing this interaction was whether it’s worth creating an entirely new app based around this feature. It would be a lot more convenient to just tack this feature onto Spotify, as it would make sense with the direction they’re taking with social features and their collaborative playlists.

This concludes my case study. Thanks for reading — give it a 💚 if you were feeling the content or hit me with a response if you have something to say!