Reimagining Transparency: Building a Multi-Rights Music Platform

Overview

I led the UX design for a complete rebuild of a music rights management platform, transforming it from a basic distribution tool into a comprehensive rights management system. The project aimed to streamline complex processes across multiple teams while maintaining the integrity of intricate music rights data.

Context

Most music companies specialise in either master rights (sound recordings) or compositional rights (the underlying songs). This company operates differently, managing both types of rights for much of its catalogue. This unique position creates both opportunities and challenges in rights management.

The existing platform, Transparency (T1), handled basic music distribution and recording royalties. However, it had several limitations:

• Manual royalty processing created monthly bottlenecks
• No publishing royalties support
• No understanding of rights limitations
• An inconsistent interface requiring specialist knowledge

Understanding the problem

I spent several weeks conducting in-depth interviews with various teams:

• Finance team
• Label managers
• Publishing team
• Distribution team
• Legal team

A key discovery was how siloed each team's knowledge had become. Teams had developed their own methods for storing and managing data, leading to duplication and inefficiency. I came across spreadsheets in different formats, CSV files and Airtable databases all being used for similar and related data but kept completely separate.

Process mapping

Working with the product manager, we mapped the entire journey of a song, from initial signing to royalty payments. This revealed several critical insights:

The typical process involved:

Label team discovering and signing new music

Contract creation and negotiation

Audio asset and metadata collection

Distribution through T1

Monthly royalty processing

Artist payment management

Each step involved different teams, tools, and data requirements, with little coordination between stages.

Reviewing the process

After gathering this deep understanding of the current state, our product team focused on three key 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 gained from our initial research, we mapped the entire process from start to finish. This revealed a complex web of interactions and dependencies between teams. At a high level, the process looked like this:

Label team discovers a song they want to sign

Contract negotiation and agreement

Label team collects audio assets and metadata, storing it in their CMS

Information handover to the distribution team, who load it into T1 and send to DSPs (Digital Service Providers)

Processing of monthly royalty statements

Loading of contractual royalty information for payment processing

Artist notification and invoice management

With everything mapped out, we had our eureka moment. The core issue wasn't just the tools or interfaces - it was the order of operations. For example, royalty payout information was only being loaded into the platform when it was needed for processing. This created an artificial bottleneck. We started asking deeper questions:

• What if this information could be input earlier?
• If it could be earlier, could someone else do it?
• If someone else could do it, did they need to be a royalties expert?

We had the realisation that we needed to fundamentally rewrite the process and reconsider how data flowed through the system.

The solution

A new distribution process

The first step was to simplify and streamline the existing distribution and royalties process. This was the core functionality of T1, so we had a foundation to build from, but it needed significant improvement.

Our goal was to create an intuitive interface that would allow non-expert label users to enter all required data in a streamlined way. I began by wireframing potential user journeys that would guide users through inputting song metadata, defining royalty splits between artists, setting distribution settings, and submitting songs to DSPs (Digital Service Providers).

I reviewed these wireframes with the distribution and royalties teams, leveraging their deep understanding of process requirements. Through several iterations and refinements, we developed a process that showed real promise. What previously required input from three different teams could now be handled by one. The new process shifted distribution and royalties teams into oversight roles, where they would focus on process monitoring and issue resolution rather than data entry. This aligned perfectly with our goal of increasing output without scaling the team.

To validate the new process, I created a high-fidelity clickable prototype in Figma and tested it with several label managers from within the company. The feedback was overwhelmingly positive, with only minor issues in information gathering identified. After a few more iterations to address these issues, we were ready for final design and implementation.

Understanding money flow: Recording and publishing contracts

One of T1's major limitations was its reliance on specialist knowledge for data input. The platform required a deep understanding of the royalties process and couldn't handle publishing royalties at all. Our first challenge was to remove this requirement for specialist knowledge, making the system accessible to anyone with access to the contract details.

My earlier conversations had revealed the existence of different contract types with widely varying terms. To fully understand this complexity, I dove deep into past contracts, searching for edge cases and the most complex deals we'd handled. I needed to understand every possible way money could flow through the system.

To visualise these flows, I created a series of diagrams showing the waterfall of money and payment hierarchies. These diagrams proved invaluable in several ways:

• They simplified complex contract language into clear visual flows
• They helped the team spot patterns in seemingly different contracts
• They clearly defined the boundaries of what our system needed to support
• They created a shared understanding across different teams

Most importantly, the diagrams revealed that despite apparent complexity, the same basic structure appeared repeatedly, with variations primarily in payment amounts and timing. This insight led to a breakthrough in our approach to reducing the need for specialist knowledge.

We realised we could separate contract information into two distinct parts for each record label:

A 'base contract' set up by the specialist royalties team, establishing foundation terms that label users wouldn't need to worry about.

Artist-specific terms managed by label users, focusing on clearly stated shares from individual contracts.

This separation allowed us to collect information at more logical points in the process. For example, money splits specific to each recording could be input when creating the recording in Transparency, rather than waiting until royalty processing time.

The final design

As we began rebuilding Transparency from the ground up, my role as the sole designer encompassed both user experience and interface design. The complexity of the project demanded careful consideration of our technical approach.

Drawing on my background as a front-end developer, I worked closely with the development team to evaluate our UI implementation options. We assessed numerous React UI libraries, but it became clear that Transparency's complexity would require significant custom component development. We wanted to avoid forcing an existing UI kit to do things it wasn't designed for.

After careful consideration, I proposed using Tailwind CSS and Tailwind UI. This decision was based on several factors:

• Tailwind's development speed and flexibility
• Tailwind UI's solid foundation for basic components
• The ability to easily create custom components without fighting the framework
• The framework's support for consistent design patterns

Using Tailwind UI's Figma file as a foundation, I developed a comprehensive design system which allowed us to quickly build high-fidelity prototypes and test ideas. My process for new features follows a clear pattern:

Create initial prototypes and check feasibility with engineers and product fit with product manager

Test components and flows with prototypes

Detail all possible states and responsive behaviours

Document functionality and behaviour requirements

Include references to similar solutions or useful React packages

Review with the front-end developer again to maintain alignment

In the absence of another designer on the team, I've found the front-end developer to be an invaluable sounding board for design decisions. Our collaborative approach ensures we consider both user needs and technical constraints in every decision.