Simple Splids
Democratizing Contracts for Musicians
The journey to a highly modular, deeply intuitive, and wholly gamified interface–designed to empower musicians do their own deals.
Roles
Product Designer, UX Strategist, Information Architect, Prototyper, & Legal Researcher
Product Designer, UX Strategist, Information Architect, Prototyper, & Legal Researcher
Roles
Designed and structured the database with developers and created the user interface, ensuring seamless data integration and flow. Played a crucial role in architecting the system to support scalable contract structures, with a focus on usability, transparency, efficacy, and ease of access for musicians.
The Problem
How do we empower musicians to draft and negotiate their own contracts? While optimizing for depth and addressing boilerplate legal terms, we must maintain simplicity.
Music contracts are messy. The basic terms themselves can be confusing (e.g., master, publishing) before even considering the convoluted conditionals attached to them.
Most users struggle to understand the terms and are often reluctant to put in the effort to learn.
This misunderstanding is the root of many issues—deals artists don’t fully comprehend, contingencies they’re unfamiliar with, and a lack of autonomy over their careers and finances.
There’s a lack of transparency in contract negotiation—while valuable at times, this mystique is often leveraged for unethical business practices.
Handling contracts in the music industry means paying for legal fees—fees that many musicians simply cannot afford.
The goal:
Empower users to handle their own deals—and get excited about it.
Guide them to understand the contracts they are drafting and negotiating.
Balance transparency and privacy.
Design an interface that can handle conditional terms in a seamless and future-proofed way.
Ensure modularity to support a wide range of contract types without complicating the experience.
Build the interface with a legitimate legal framework in mind to ensure the contracts are both accessible and legally binding.
Make it all intuitive and easy to use.
Welcome to the “Splid File Cabinet”. An interface designed to someday be the one-stop shop for all business on a song–from deals to distribution, someday this scalable interface will be housing quite a bit.
Version after version after version
-
![]()
Version 1–Standard Splid
The first attempt. This is where the first idea of gamification came from. I wanted to create a contract interface inspired by the ones in FIFA Career Mode when signing a player–that was always my favorite part of the game. While this design slightly cognitive overload inducing, it served as a great starting point.
-
![]()
Version 2–Easy splid
Ah–the easy splid–as the name suggests, this was designed to be unbelievably simple. With sliders and big numbers, we strived to automate the process of drafting a fair deal. For more info, see the detailed section below.
-
![]()
Version 3–Tinder-Esque (kind of)
We made the bold decision to make Splids mobile first. Big information for a little screen. I thought—How can I reduce cognitive overload and mega-scrolls? I settled on a Tinder inspired interface, allowing users to swipe between different terms and adjust them accordingly. Ultimately, this interface felt a little tacky—and our data structure changed at least 4 more times afterwards
-
![]()
Version 4–The Solution (or so I thought)
This felt perfect. I was similarly inspired by Hinge, and Tinder. This, like Hinge, was a cleaner, less busy look with much more white space. Similar to Tinder, I created the big colored buttons. This felt perfect visually, but the data structure later changed dramatically for scalability purposes. Looking back, as appealing as this was, it couldn’t naturally house the intricate conditional terms we intend to add—so we had to part ways.
-
![]()
Version 5-The Pre-Splid
Not everybody wants to shoot around contracts like they’re text messages. This is where the Pre-Splid comes in–designed to allow users to create enforceable contracts without fixed terms; instead granting them the right to negotiate on terms at a later date. We have kept this principle since its inception. In the current state, it is slightly altered.
-
![]()
Version 5.2–The Pre-Splid
Our new data structure revolved around terms as modules, and the flexibility to insert any combination of them into a deal. Through prototype testing with family and friends, I found that I needed to do a better job of specifying even the simple terms . This contract methodology permitted a unique opportunity for user education.
-
![]()
Version 6–Less pages, please.
Let’s make it a little more interesting, shall we? We aimed to consolidate everything to one page. This dropped me into a full-on brainstorming mode. How can I fit all terms, all toggles, all switches, and deal history on one page—without a mega-scroll? This was my first attempt—simply put, this wasn’t good enough.
-
![]()
Version 6.2–The Blob Approach
This was an enticing idea, but the visual unpredictability of adding terms was the real dealbreaker here. But realistically, it still wasn’t good enough.
-
![]()
Version 6.3–A Simplified Approach
This was the more ‘obvious’ approach. The idea being to treat each umbrella term as an accordion style container. While it worked, it felt like a contract—you know? Not good enough, once again.
-
![]()
Version 7–The Breakthrough
After days upon days of brainstorming, I stumbled upon this concept. A packed card with the deeper information hidden behind the scenes, while still providing overviews. This felt like the solution. It’s simple, intuitive, clean, and entirely modular. We are currently awaiting beta tester feedback to determine what needs to change, and if it really is that intuitive
The easy Splid
This design is not slated to be in our V1, but I believed this deserved honorable mention—this was one of the first Splidi designs I was really proud of.
Specific Problems it Tackles
When negotiating, people don’t know what’s “fair”. Everyone is familiar with the fear of asking for too much money—and everybody knows the frustration of having received too little.
Musicians don’t understand what master means. Many artists treat master as something they’re wholly entitled to without payment, despite the producer being the one who owns the files and often provides the recording environment.
Hidden budgets create a system where musicians do work expecting their rate, only to find out their rate wasn’t in the budget.
Full transparency isn’t feasible. Broadcasting budgets on contracts should be concealable information only to be revealed at a user’s discretion.
THE SOLUTION
With sliders, big numbers, and automated metrics, this contract almost does itself.
Intuitive Interface
The master fee slider was designed to provide users with a subliminal teaching lesson—when the fee goes up, the seller’s percentage goes down. This is how master rights work, but it is not currently seen in that way.
C.P.P., or cost per point, gives musicians a legitimate metric that tells them how much one point of their master ownership generally costs.
This makes fair deals easier to facilitate—users know what they can ask for
Creates the potential for collaboration matchmaking based on financial factors.
Builds user trust, ensuring that users are asking for what’s fair.
It allows users to get “raises” resulting from good work and career advancement.
Makes a Fairness meter possible
Master/Fee Slider & C.P.P.
Fairness & Likelihood Meters
The fairness meter gauges how fair a user’s deal is, based on deal history and other data metrics.
The likelihood meter tells a user how likely it is that the payor will accept these terms—based on deal history like previous expenditures and their tendencies towards certain deal structures.
The Aggressiveness Slider
If a user feels their C.P.P. isn’t giving them a high enough range of values, they can toggle the aggressiveness slider to increase their cost per point multiple.
They can turn down the aggressiveness slider to offer more generous deals.
Permits users to aim for deals they want without having to understand what they’re actually doing.
Templates
The Easy Splid has contract templates which users can create or toggle.
Provides a number of default templates aimed at giving users exactly what they’re looking for.
Ensures fairness in negotiations between significantly uneven budgets.
Autodrafts a deal at a reasonable, randomized middle point between two economic situations.
Meet in the Middle Button
Initial Master Percentage prior to negotiations is necessary for the C.P.P. How do you know how much you’re giving away without knowing how much you started with?
We tried many algorithms to try and accurately reflect C.P.P. without it, but it became too much of a task for V1.
Not enough data. The Easy Splid will work much better once users have deal history and objective metrics to base the interfaces’ metrics off of.
THE Shortcomings
We aim to integrate this design in future versions of the Splidi’s desktop app. It was a little too much to tackle in V1, and the concept is still not perfected. With that being said, it has the potential to have a lasting impact on how fair deals are facilitated in the music industry. By creating a system built to facilitate ethical, fair deals on an interface musicians can trust and understand, the Easy Splid could seriously change the game towards democratization of contractual agreements in music.
Conclusion
Results
Although the design isn’t finalized yet, this project has been a massive growth experience for me. It’s sharpened my design skills, honed my product thinking, refined my business strategy, and stretched my creativity to new heights. I’m proud of what I’ve achieved so far—an intuitive, a la carte music contract solution that balances complex contractual terms with modularity, scalability, and ease of use.
Key Achievements:
Gamified, user-friendly interface: With something as mundane and complex as contracts, this was one of the toughest challenges. The current system is optimized for ease of use with the goal of making negotiation fun.
Solution primed for growth: I created a framework that emphasizes usability while maintaining the feasibility to include later, more advanced features such as recoupment or dilution terms.
Granular control over deal points: Expanding on the previous point–while primed for improvements, the design and data structure allow for a huge variety of deals and edge cases–ensuring scalability for tomorrow and powerful functionality today.
Kept potential user friction to the absolute minimum: With perseverance, I kept the entire contract drafting interface within one scroll of one page–this was a remarkable challenge. The current design accomplishes this, allowing users to have depth and simplicity–the best of both worlds.
This was one of the toughest design challenges I’ve had to face in my time as the sole product designer at Splidi. Creating this system took months of conceptualization, countless revisions, and an unwavering tunnel vision towards ease of use–while under the weight of extreme complexity and never ending back-end iterations.
There are still some unanswered design questions–user testing being a large one. Our intention is to optimize the rest of the system based on user feedback, and have their responses dictate our decisions in the finalization of the interface.
While unfinished, I believe the Splid’s design development over time is a testament towards my product thinking, strategy, creativity, and unrelenting desire for perfection.
