Due to the nature of this project, I have not named the company in question (referring to them as “the company” throughout) and omitted identifying details.
I left the company while the project was still at a fairly early stage in its development. I have provided background to the problem and up to date information about my process for some sections of the product.
My role
Product Designer
The team
Project Manager, three Backend Developers, one Frontend Developer, Product Designer (me).
Background
The company inhabits a unique position in the music industry. Typically, a music label has control of master rights (the sound recording), and a music publisher has control of compositional rights (the underlying song itself). Normally, music labels and music publishers are separate entities. The company, however, acts as both publisher and label for much of its music catalogue, giving it full view and control of all rights associated with a song.
The company was already using a product called Transparency (T1). Like other products on the market, T1 was able to distribute music to online platforms (DSPs) like Spotify. It could then process the recording royalties that came back from DSPs and distribute these royalties to artists. It was built to meet the growing needs of the distribution team as the music catalogue grew.
The problems
We identified 3 problems with the current product:
- Royalty processing was a very manual task. This resulted in a monthly crunch to make sure all the royalties were processed in time. T1 also didn’t have any understanding of the rights associated with each recording. As these rights could impose limitations on where a song could be distributed, this meant that it was up to the users to diligently input the data correctly. We wanted to automate and streamline these processes to reduce the workload for the royalties team and the risk of human error.
- T1 was not set up to deal with publishing royalties. In other words, it would be able to pay the artist royalties for the sound recording, but separate software was required to pay the writer for the underlying composition (even if the artist and writer is the same person).
- The user interface was inconsistent, confusing, and at times required specific knowledge of the product’s quirks to make progress. While T1 did what it was built to do, it had a long way to go before it was able to properly cater to the company’s needs.
The vision
The company desperately needed a product that did a lot more. In addition to distributing music and royalties, our product team determined that the new product (T2) needed to:
- Store all relevant rights and information about recordings and compositions.
- Automate as much as possible and reduce the risk of human error.
- Unify the company’s royalty payouts so artists could understand more easily how much they were earning.
- Be simple and easy to use, requiring less specialist knowledge.
Background research
Before designing an updated product, I needed to deepen my understanding of each part of the music process. This required a deep-dive into how distribution, rights, and royalties all work.
I spent a few weeks holding in-depth conversations with my colleagues including the finance team, label managers, the publishing team, the distribution team, and the legal team. Each team knew how their individual part of the process worked so, by speaking to all of them, I could establish an overview of the entire operation - from the label team deciding to release a song, to distributing the music, to paying the artists and labels their royalties.
As I spoke to my colleagues, I was surprised to see how little everyone else understood the entire process. Each team stored data in their own way, making it difficult to keep track of what was going on day-to-day, which rights we hold, and where we could be doing more with our catalogue. There was a lot of inefficiency, data duplication and repeated questions coming up time and time again. It was clear that the process was due an overhaul.
Working closely with the product manager, I dug deeper into every stage of the process with each team, revealing more and more improvements to be made and thus, expanding the possible feature set for T2. At this point, the sky was the limit and we wanted to gain a detailed understanding of each team’s pain points before coming up with a strategy to solve them.
Having established the problems at the heart of the operation, I conducted a competitor analysis to see if a solution existed. I found that products exist which cover parts of the process (like T1), but nothing that exists covering the whole process.
Reviewing the process
With a clear vision of what we were trying to achieve, we (the product team) then asked ourselves the following questions:
- How might we scale output without scaling the team?
- How might we make rights and royalties easier to understand and more transparent?
- How might we reduce data duplication and the risk of user error?
Using the knowledge we gained from our initial research, we mapped out the current process from start to finish. We then identified pain points in the process and their causes. At a very high level, the process was like this:
- Label team hears a song they want to sign to the label.
- A contract is drawn up between the label and the artist, and the company agrees to release the music.
- The label team collects the audio assets metadata and stores it in their CMS.
- They pass this information to the distribution team who load it into T1 and send it out to DSPs.
- The monthly royalty statements come in and contractual royalty information (who gets paid and how much) is loaded into T1 so the statements can be processed.
- Artists are then notified and can invoice the company to receive their royalties.
With it mapped out in front of us, it was clear that the heart of the problem was the order in which things were happening. For example, all of the royalty payout information was being loaded into T1 at the point it was needed. This created a bottleneck. What if this information could be put in earlier? If it could be put in earlier, could someone else do it? If someone else could do it, did they need to be a royalties expert? That was our eureka moment. We needed to rewrite the process and start putting data into Transparency in a more logical and efficient way.
As a team, we came up with a plan for reordering the process and ultimately restructuring the teams within the company. And, after getting buy-in from the company’s senior leadership team, work on T2 was ready to begin.
As T2 was tackling such a large problem, we broke it down into more manageable sections. A lot of these sections are still ongoing or yet to be worked on, but below is a breakdown of how I went about solving some of the problems.
A new distribution process
The first step was to simplify and streamline the existing distribution and royalties process. This was the core of what T1 was built to do and we therefore had a foundation to build from.
We needed an intuitive UI that allowed non-expert label users to enter all the required data in a simple and streamline way. With this in mind, I wireframed some potential user journeys that would allow a user to input a song’s metadata, define the royalty splits between the artists, set the distribution settings and submit the song to DSPs. I reviewed the wireframes with the distribution and royalties teams, as they are the most familiar with the process and its requirements. After a few iterations and some refinement, we had a process that looked promising.
The set-up process that previously required input from three different teams now only required one. The new process moved the distribution and royalties teams into less operational roles where they would only need to oversee the process and to check for any issues. This new process would help achieve our goal of increasing output without scaling up the team.
I then created a high-fidelity prototype in Figma to test the process. We tested the prototype with a number of label managers from within the company. Based on feedback from our testing, the new process was a success. There weren't any major problem areas introduced and only a few minor issues in the information being gathered. After a few more tweaks and iterations, the process was ready for the final design stage.
You can read more about designing the final user experience and user interface below.
Recording and publishing contracts: Understanding the money flow
T1 was built to requirements provided by the royalties team. It required specialist knowledge of how the royalties process works in order to input the data correctly, and it wasn’t able to handle publishing royalties.
The first problem to tackle was removing the requirement for specialist knowledge so that anyone looking at the contract would be able to accurately and correctly input the data.
From my previous in-depth conversations with the teams, I knew there were different contract types with a wide variety of terms. I dug deeper into past contracts to find edge cases and the most complex deals we had. I needed to understand all the possible ways the money could flow. To understand the flows, I created a set of diagrams that clearly showed the waterfall of money and who got paid at which point.
The feedback on the diagrams was extremely positive, and they were instrumental in our understanding of all possible variations and getting the team aligned on the problem. They helped to simplify the complicated wording often used in contracts, allowing us to spot patterns and define the boundaries of what money flows the product needed to support. With the diagrams laid out in front of us, we noticed the same structure occurring each time, with variations in how much people were getting paid and at which point. This new understanding allowed us to come up with an approach to removing the requirement for specialist knowledge of contracts.
To support the vast majority of the contracts, we would be able to separate the contract information into two parts for each record label. The first part would be set up by the royalties team. This ‘base contract’ would act as a foundation for all of the label’s contracts and would set some of the base terms that label users don’t need to worry about.
The second part would be set up by the label users and involved inputting the artist's share of the money that was clearly written on each contract. This approach allows label users to input this information at a logical step. The money splits (and a few other terms) are individual to each recording, so it makes sense to input this data at the point of creating the recording inside Transparency. Combining both parts creates the full picture of the money flow within the contract.
I am still in the process of working on this part of Transparency and I am currently in the wireframing phase. To wireframe the solution, I put myself in the position of the label user and I am using past contracts to validate my ideas. I am focusing my efforts on a user flow that would cover the majority of use cases.
The final design
The new version of Transparency (T2) is currently being rebuilt from the ground up. As the sole designer on the team, I am responsible for all user experience and user interface design.
As we were kicking off defining the new process for T2, I was simultaneously using my own experience as a front-end developer and working with the other developers to decide how to build the user interface. I assessed many of the existing React UI libraries to find something suitable for what we were planning. However, for a product as complicated as Transparency, it was likely that we would need to build a lot of custom components, and we didn’t want to have to bend an existing UI kit to do something it wasn’t designed to do.
Ultimately, I suggested using Tailwind CSS and Tailwind UI. I arrived at this decision because of the speed and flexibility of developing with Tailwind, and their UI kit was just enough to give us a solid foundation, and flexible enough to not get in the way when creating custom components.
Using the Tailwind UI Figma file as a starting point, I began developing a design system to use. After a prototype is tested and approved, I add detail to each component. This involves designing all the possible states, appearance across screen sizes, and adding notes on how it should function or behave. I will usually link to references found in the wild, such as websites that inspired my ideas, or to React packages that could be useful in understanding the requirements.
Working with the front-end developer, I run through the notes for each new component to check the viability, and more importantly, get their expert opinion. In lieu of another designer on the team to discuss ideas with, the front-end developer is my go-to sounding board to make sure nothing is being overlooked.
