Designing Spotify for Artists
This case study is LONG. Feel free to start reading from “Competitive Analysis” to start reading about my process. Thank you!
Preface
For the last 10 years, Spotify has been focused on giving consumers the best streaming music experience. But according to Daniel Ek, the CEO, he wants to focus the next 10 years on bringing the best experience of music to the artists. Why’s that?
The answer can be revealed by the Net Promoter Score (NPS). NPS is essentially an index that measures the willingness of customers to recommend a company’s products or services to others. And while I can’t share the exact NPS that we calculated when surveying artists, let’s just say that they are pretty un-happy.
Why? The biggest reason that pops up is that artists feel like we rip them off by taking too much of their revenue. Taylor Swift and Spotify had some pretty Bad Blood regarding this issue (pun intended). While it’s true that a majority of artists aren’t able to make even minimum wage making music, there’s much more than just Spotify that contributes to this issue.
Currently, to get music up on Spotify, artists have to talk to their labels and the labels contact us to get their music. It’s honestly a nightmare for everyone since the process is so manual and requires lots of manpower. The worst part is that putting a label in between artists and Spotify means that labels take about 60–80% of revenue artists make from streaming. So somehow the artists who put in blood, sweat, and tears to create music end up on the bottom of the pay scale. In my opinion, it’s the most broken system in the music industry.
Enter Spotify for Artists
As a product design intern at Spotify, I was given the opportunity to work on an exciting platform called Spotify for Artists, or as we internally called it “S4A”. And S4A stands at the forefront of Daniel’s mission to improve our NPS. This tool delivers artists with things like music performance stats, audience engagement metrics, concert launch promotions, merchandise sales, and much more.
I specifically worked on a squad called Direct (DRCT) that tackles the issue regarding how artists feel like their getting ripped off. DRCT is a squad within S4A that is enabling artists to directly upload their music to essentially cut out the middle man. By doing this, artists are able to make more revenue and get more control over the songs they publish.
DRCT can be divided into 2 sub-squads: DRCT Upload & DRCT Royalties. DRCT Upload handles the flow to upload music, add metadata, and publish songs to Spotify. DRCT Royalties, which was my squad, builds the royalties dashboard to help bring clarity to the revenue artists earn to make actionable insights based on those metrics.
When I joined Spotify, DRCT was still in its early stages. The goal for my squad was to launch an Alpha version of the product by the end of my 10 weeks and then eventually roll it out publicly to more artists.
That was a really long introduction. I’ll start talking about the process from this point on.
Competitive analysis
Because Royalties was still a very early stage product, I started out by doing some competitive analysis. The thing with royalty dashboards is that it’s not that easy to see how other companies implement it. For example, if I wanted to test out the YouTube dashboard, I would have to be a content creator with a decent amount of views to get ad revenue. If not, my dashboard would just be an empty state. Therefore, I went through some FAQ guides and walkthrough tutorials of other products to see how they function. In addition, one of my co-workers happened to be a musician with a solid following so I had a chance to interview him and take a look at his dashboard.
For each dashboard, I wrote down what features it provided and what advantages/disadvantages it had. Then I shared it with my team to discuss what sort of UX flow we can approach Royalties with. What came out of this competitive analysis was that virtually all dashboards are difficult to use and seemingly gives too many features to users. That’s not necessarily a negative thing but by doing this, users can be overwhelmed by the amount of buttons, dropdowns, text, etc. and feel unmotivated to use it in the first place.
With Royalties, our target audience was DIY artists and this meant that they were generally not familiar with professional software. This competitive analysis made it clear to the team and I that we were willing to sacrifice features for a more friendly user interface.
Think-It Session
Whenever we kick-off a product at Spotify, we do something called a “Think-It” Session where all members of the squad get together in a room and discuss what we are trying to accomplish with the product and what features are necessary to satisfy that mission. We had a user researcher that did some interviews for DRCT to give us a better perspective of what frustrations users were feeling. After lots of back-and-forth discussion, the mission of our product was determined:
“Empower artists with royalty data to help them make well-informed actions for future growth.”
Next, we did a 3 x 3 mins of post-it sessions to write down what features were necessary to make our mission a reality. These were some of the ideas that came up:
- Show a chart showing a historical earnings
- Earnings breakdown by song, album, playlist, geography, free vs premium
- Royalties projection for the upcoming months
- Goal setting and gameification
Finally, we organized the features based on reward vs. effort. If a feature has a high reward and low effort, it’s a prioritized feature. If it has a low reward and high effort, it gets bumped down to the bottom. Using this method, we were able to categorize what we can implement for the Alpha, Beta, and public launch.
Design and Iteration
At this point in time I had a pretty good idea about what features should be on Royalties and it was time to explore some options on how I could visualize it. My approach with wireframing is that I don’t usually do it by pen and paper. I go straight to Sketch and start to roughly draw out what I have in my mind and keep duplicating artboards to make tons of iterations. This way, I can always keep different versions of my designs without having to redraw things with hand.
One of the most difficult things that I had with designing was thinking about multiple use cases. For example, how does the design look when there is no data yet to be shown? Or what if royalties calculations have been made and it’s just in the process of being sent? In many cases, a “this is the one!” design could collapse because it breaks down when asking these questions.
Another effective thing I did was test our designs with real data. I asked my data engineer to give me two number sets that contains Royalties data for two edge cases: a really big artist getting millions of streams and a really small artist that makes about a hundred streams a month. Testing with real data sets opened up interesting questions, especially for small artists. For example, How do we display Royalties metrics when an artist makes less than a penny for a song? I had to properly account for this edge case.
Consistency is another important part about working at company that builds many products. While Spotify has their own design system that sets guidelines on things like type and color, designers have to build unique components that often is not defined in the system. In these cases, I asked the design systems team to help me on expressing my idea without breaking the system.
During this entire process, I kept in close proximity with my mentor, engineers, product owner, user researcher, and UX copywriter to update them on what I was designing on. If they weren’t available in person, I used Wake to share my work and receive feedback that way. By doing this, I was able to keep my work in check and make sure that everyone’s vision aligned.
I also presented in the weekly Design Review, a weekly event where the entire design team critiques each other’s work. This was extremely helpful as I was able to get a fresh perspective since every designer in the room works on a different squad and on a different product. Moreover as designers, they noticed nit-picky details and inconsistencies that led to visual improvements.
Prototyping and Final Touches
After receiving positive feedback of my screens, I started working on a prototype to see how it could look like when adding interactivity to it. I used Origami to prototype my designs and it gave me a better sense of how Royalties flowed as a story. It especially helped me with hover states where it’s often hard to understand how it feels when you just design two static artboards showing hover and non-hover.
Final Designs
Over the course of 10 weeks going through multiple revisions, I completed the design that was going to ship for Alpha. Here are some of the highlights.
If a user hasn’t uploaded their music through DRCT, they will see an empty state that has a CTA to “Release Music”. Upon releasing music, Royalties tab will still have an empty state. Except in this case, the copy tells the artist that they could expect to see the page with data soon. While having 2 consecutive empty states is not the most desirable UX, we didn’t want to overload all the copy into one empty state. Taking the user step-by-step was a more friendlier approach.
Upon having your music up on Spotify for a few months, the Royalties page finally starts to blossom. The page starts with a graph that indicates how much money an artists has earned over the course of the past 6 months. One of the insights the user research emphasized was that the most important information artists cared about was the recent amount of payment they received. Based on this, I intentionally surfaced the “$271.33 in June” at the top.
A restriction I had to consider when designing this was that it takes a long time to process payments since DRCT has to go through the legal & finance division before initiating payments. This meant that even if it was the end of August, an artist may only see June as the latest payment. To account for this, I visually distinguished between paid and unpaid months to remove any ambiguity. We also added a range of earnings one can expect to be paid for a month that hasn’t been paid out yet (calculated by an algorithm). This was integral to Royalties since we wanted to allow users to make better financial decisions by providing them with latest earnings, even if it was a range showing an estimate.
Upon scrolling down, artists can get more granular data about what made up each month’s earnings. Earnings by release displays first, followed by earnings by song to give artists a sense that they are digging deeper as they scroll more. The dropdown menu enables users to switch between previous months as well.
Reflection
Looking back on designing Royalties, I’d have to admit that it was a long and time consuming process. Especially coming from a small product studio last summer, working at Spotify means that I had to be in constant check with other stakeholders and make sure that there was alignment with the rest of the company’s identity. Nevertheless, I’m grateful I was able to go through all of it. I learned that when having the opportunity to design for a product that is catered towards an audience of a million people, the process must be proceeded with tons of care.
Talking with user researchers, copy writers, product owners, designers, engineers, and so many other people ended up being an opportunity for improvement because it constantly made me step back and rethink the problem from another perspective. Moreover, being at Spotify taught me a lesson about the importance of scaleability, edge cases, and consistency within products. I’m incredibly thankful to be part of such a talented group of creatives and contribute to what is hopefully going to become the future of the music industry.
Thank you for sticking till the very end. Feel free to check out the rest of my work at www.YukiAsakura.com!
