Timeline: 4 weeks, Personal Project

Role: Design, Fullstack Development

Technologies: Figma, React, Nextjs, TypeScript, SCSS, MongoDB

Overview: I revisited my favorite personal project for a major design and code overhaul.



As a huge fan of Spotify’s music platform, I got tired of waiting an entire year for Spotify Wrapped to be released for me to see my listening statistics. So, last year, I taught myself React and built a web-player that provided users with improved insights of their listening history and provided recommendations based on their current “moods”.


Although I’m glad that I pursued the project and saw the completion of all key features, there were plenty of issues that made it far from complete. So, I found myself itching at the opportunity to crack open the code-base and look at how my skills had developed in only a year.



After exploring the full capability of the Web API, I realized that I had barely begun to explore the potential applications of detailed track insights, monthly user listening statistics, and pairing my application with an external database and/or a websocket to stream data between simultaneous users.


Refactor: To redesign my previous application by prioritizing key features on the front page, using NextJS dynamic API routes on initial page loading to optimize network calls, and creating a clean, user-friendly interface that is consistent across the entire application.

New Features: Collaborative listening, exporting playlists, and most importantly, using user data to determine their “match score” with their friends.


To lay the foundation for MusicMatch, I took a look at Spotify’s vanilla web application, and what user features they weren’t reaching.

User Feature


Listening Statistics




Simultaneous Listening


Cloning Playlists


Exporting Music



I found that the only official listening stats released to users was Spotify Wrapped. It shows users their top five artists and tracks from that year, but it was only released in December.

As for music recommendations, Spotify had several options, however, none were very customizable. Users were given a weekly discover playlist with new tracks based on their short term listening history, daily mixes with familiar tracks based on their created playlists and saved libraries, and it suggested tracks to add to a playlist based on the five most popular artists in that playlist. All of these taken into account, the playlist recommendation was the most practical, however its implentation would often lead to skewed recommendations in very diverse playlists.

Although Spotify has detailed data about individual tracks such as “danceability” or tempo, the platform does not seem to use them for recommendation.

Given search functionality and detailed track insights from the API, I knew that MusicMatch could give users the option to do advanced searches for the types of tracks they wanted to hear. I could generate entire playlists given those search variables, and learn from the user’s music taste to provide better insights with each suggestion.

This data could then be used to create a unique score for the user, not to rank their taste but rather to classify it numerically. I could then take this score and use it to compare different users and determine their “compatibility”.





After releasing a working prototype, I conducted user research testing to gain insights on the friction points of 3 task flows:

1. Enable “clean music” mode for playback

2. Check your top artists/tracks

3. Browse and play an unpopular track from an obsure artist


1. Why do I still need to launch Spotify to use this?

One limitation of the API is its inability to begin playback on a specific device. Users were confused because they had to launch the app and begin playing music before the in-app player would appear, defeating the purpose of having only one application to use for Spotify. This is of course because my application cannot control a user’s device. I can, however, integrate the Spotify Web Playback SDK and link it with my application to play in-browser music, which is a future goal for the application.

2. Confusing navigation

I got feedback about two different navigation issues, the first being what was on the stat page. When I told users to check their top tracks and artists, they immediately assumed that it would be on a profile page. When their only navigation link was “stats”, it was worded too technical for the average user and they did not associate it with personal insights. As soon as the other new features are implemented, I will move them along with the playlists link to the profile page.

3. What is “clean mode”?

A feature I wanted to add to the application was a “clean mode”, which gave users the ability to skip explicit tracks in their playback. I thought it would be useful for professional gatherings or events where explicit music would not be appropriate, and it could easily be a feature toggled by a user through their expanded player. When I asked users to test the task flow of toggling it, every user asked where the settings were. Although my intention was to make this action easy to access and non-invasive through its placement in the expanded player, along with shuffle or repeat, users seemed to associate this feature with a settings menu. Also, users were confused by the wording of “clean mode”, so it has been changed with “skip explicit” for clarification while I test out a settings menu.



Track filter prioritized at the top for easy search in larger playlists. Can sort by date, artist, or track name.


Artist page now reduces the space of popular tracks through the use of a horizontal scroll, allowing more space for tracks, albums, and similar artists. The detail panel at the top also lists the artist’s popularity and associated genres, which will be used to improve the suggestion algorithm. As users look for more obscure artists in their preferred genres, the popularity indication serves as a marker.


Soon to be the profile page, the stats page exhibits your top tracks and artists, which can be selected by top of the month, past six months, and all-time. Genre will be the next feature to be added, which graph visualizations of an artist’s progression up and down this list as months go by.


1. It’s important to look back at your mistakes

Refactoring old code is a huge project by itself. Even though it was only made a year ago, I think it was very encouraging to look at how far I have come as a developer. I remember sitting in class last year, scouring Stack Overflow for answers and waiting for someone to comment on my Github issues for hours, only to be told I forgot to include a return statement in my API call.

Although I didn’t need to go back and fix this project, I realized that a product is never truly finished. I learned a lot more about Next’s framework in a week than I had working on a collaborative project in a month.

2. Never use someone else’s work if you can do it yourself

I used to have a naive mentality that there was no reason to do something myself if someone else had already done it for me. Although it saved me time and frustration, I was always restricted by the third party libraries I was using rather than my own knowledge limitations.

When it comes to design, there is justification in seeking inspiration and sticking to what is famililar with users, but there is also gratification when you take risks and try something brand new. I took inspiration from the design of popular music players in the market, and created an interface that prioritized the features that users wanted to see first.


1. Gamifying the Experience

As I continue progress on the matching algorithm, I want to target the competitive nature of having statistics associated with the user’s listening history. Users should have “top genre” badges on their profiles along with their favorite artists and tracks - which in combination can create a “leaderboard” of music taste on each user’s profile. The compatibility feature will lead in nicely with this sense of one user’s taste being “better” or “worse” than anothers, although of course this is all subjective to the user’s preference.

2. Prioritize accessibility

Something I take very seriously is accessibility. As I complete development work, I will use tools such as the WAVE accessibility extension to check that all of my code complies with A11y standards, and that the color contrast ration is above an 8 throughout the site to allow for friction-free ability to use the application. I am referring to Material Design UI guidelines for padding, line spacing, and button size for accessibility purposes as well.

3. PWA!

If I integrate the Web Playback SDK into my application, it could completely replace the Spotify application as the user’s primary tool for listening to music with their Spotify subscriptions. By converting the site into a progressive web application, users could download the app like any other onto their home screens for a faster launch.