SWITCHCHORD: SPLITS
Turning the messiest part of music collaboration, splits, into a chat where everyone can see, weigh in, and lock in their share together
ROLE
Lead Product Designer
DATE
2025
TEAM
CEO
Product Manager
Engineer
OVERVIEW
Switchchord is a music rights startup building an iOS app that helps songwriters and producers take control of their business: logging songs, managing publishing splits, and improving collaboration (contracts, metadata). The promise: all your rights, all in one place.
I was the sole Product Designer across three sprints where I designed experiences for account and profile set up, ingesting catalogs and managing dashboards, and then the hardest and most human feature: splits.
Given total creative freedom, I explored far and wide to reframe the awkward and messy "who owns what" conversation into an approachable, chat-based workspace where collaborators agree and "lock in" their shares together. Along the way, I build the app’s design system and created audience-segmented launch videos the team used for outreach. The app designs shipped to a TestFlight beta before the company shifted direction toward the legal contract side of the product.
The problem
Splits are where music collaborations can get kinda awkward
When people make a song together, the hardest part is splits: figuring out who owns what and how much each person should get.
Today that conversation lives in group texts, screenshots, and half-remembered studio promises, and gets formalized late, if ever. The CEO and PM, music industry veterans, described it as complicated and location dependent. In LA and New York it can be a tense negotiation over who deserves what; in Nashville it's almost always an even split and barely a conversation.
This is where I came in. My job for Sprint 3 was to reframe and design a solution for messy split conversations, while working within constraints.
The Opportunity
Help collaborators agree on splits before release, without it feeling like a confrontation or contract.
The brief
Total creative freedon, but inside constraints
The CEO and PM gave me a rare gift: go as far and wild as you want to make splits conversation feel less scary. But the freedom sat inside hard constraints I had to design around from day one.
Reuse web app
A web Workspace already existed. I had to reuse components and backend where possible: a light UI refresh, not a rebuild.
Cross-platform parity
A web Workspace already existed. I had to reuse components and backend where possible: a light UI refresh, not a rebuild.
Match Sprints 1 and 2
Whatever I made had to feel cohesive with the identity and catalog flows I'd already shipped.
MVP scope, real deadline
A TestFlight beta target meant every "wouldn't it be cool" idea got weighed against what one Engineer could build in time.
Going wide
If signing scares people, what if splits were fun?
The insight I kept circling: people avoid splits because it feels like signing a contract, and no one wants to sign. So instead of designing a cleaner form, I asked a different question... what would make this conversation something people actually want to open? I sketched in that direction:
1. Ownership as a pizza or spinny vinyl record
Each slice a collaborator's share, so the math reads at a glance instead of as a spreadsheet. Since Switchchord is a music right company, I thought playing music in celebration of a successful split would be a nice touch.
2. Pizza time bomb
A playful ideation emphasizing time of the decision, dramatizing the real stakes of holding out on a fraction of a percent, to nudge the group toward closure.
3. Voting rounds
Splits submitted blurred or as ranges until everyone is in. AI proposes "fairest" split options from the reasoning given, the group votes, and then it has to be unanimous or it goes to round 2.
Going wide wasn't wasted. The ideas reframed what the feature could be, opened the CEO and PM up to a less formal direction, and left two concepts that stuck:
1) casual, conversational language and
2) "locking in" a split together.
Zeroing in
The splits workspace: a conversation, not a form
Although we didn't go with the pizza bomb or the spinning record, the explorations helped us brainstorm and led us in a new focused direction: to make splits a chat.
The workspace leads with conversation in plain, casual language. Each person's percentage stays pinned and live at the top and when everyone agrees, they "lock in," with a little confetti to celebrate it.
Reuse & refresh
Same bones, warmer and touch-first
This wasn’t a blank canvas design. A web Workspace already existed and I was asked to reference and reuse it where possible, so I kept what worked and rebuilt the rest for mobile, which is exactly the constraint that made the design work interesting.
BEFORE: the web app Workspace given starting point with ownership details to fill out only. I carried over the split percentage and the button component layout, then rebuilt the experience for iOS.
AFTER: conversational splits, a sticky live total, lock in button, and native touch patterns. The same structure, but with a warmer and more approachable feel.
A decision that set the tone
Confirm, but never sign
The team wanted to steer hard away from anything that felt binding, because that's exactly what scares creators off. So we reframed a split as shared governance of a shared asset, not a contract. When I asked where signing should live, the answer was: it shouldn't. Once everyone hits “Lock in %” button on the bottom left, it automatically generates a shareable summary (with NO signatures) that lands in each person's Confirmed section in their Workspace. The trust comes from transparency and a clear record, not from a legal looking form.
Edge case
What about the collaborator who isn't on the app?
A split has no value if one collaborator can't join. The moment a workspace invited someone who wasn't an iOS user, aka an Android user or anyone without the app, the whole flow was at risk. This "edge case" was really the core case, and it drove a chain of product decisions.
We wrestled with the real questions: force a download, or let people in as guests? To what extent do we allow guests even do in a backend built for app users? Do we email them?
I pushed for the option that protects momentum: let guests collaborate in the workspace via the web app, so no one hits a dead end. To keep pulling toward the native experience, I added a dismissible sticky banner: "Get the Switchchord iOS app: Control your rights, contracts & catalog" and, to hold MVP scope, we consciously cut guest email notifications for launch.
Guest on web: parity for non-app collaborators keeps the split alive, with a gentle banner to nudge guest users toward the native app without blocking anyone.
The foundation under it
Sprints 1 & 2: identity, catalog, and a design system
Splits don't matter if you can't see what's yours. Before Sprint 3, I built the two layers underneath it and the design system that let anyone build on top.
Sprint 1: Identity + the design system
I began this project designing Switchchord’s profile/identity flow to establish the refreshed UI from the brand guidelines and build the app's iOS design system in Figma, since none existed, with documentation so the engineer and incoming contract designer could work from it directly.
Sprint 2: Catalog + dashboard
The heftier build: prove a creator's identity via their IPI number, confirm a few known song titles, then import their catalog with multi-select (song-by-song or all at once), so a songwriter or producer finally has one place that holds everything that's theirs, and their manager has a way to help manage it. I added a "Flag Split" action for collaboration, color-coded badges to distinguish between known / flagged / unknown splits at a glance, and a dashboard for catalog, to-dos, and approvals.
How I worked
Ambiguous problem, lean team, async build
This was 0→1 with no playbook and a team spread across time zones: me and the PM on PST, the CEO on CST, and Engineering in Asia. I couldn't always ask or answer questions in real time, so the handoff had to carry the design on its own.
1. Define: FigJam sessions
I mapped the splits problem and flows with the CEO and PM, using my sketches to open up the solution space before committing to the UI.
2. Design: Questions and options
My approach was asking a lot of questions and putting multiple concrete options on the table, which is how the creative direction got unlocked.
3. Deliver: Annotated async handoff
Labeled main flows, annotated interaction and dev notes on flows, and linked clickable prototypes so Engineering could verify intent without me on call.
Beyond the product
Launch videos, cut for each audience
I also produced Switchchord's beta launch promo videos: static designs in Figma, prototyped and screen-recorded, then edited with intros and transition screens. I cut them by audience: one for Managers/Rightsholders and one for Songwriters/Producers, so prospects saw the value framed in their own language, each ending on the PM's contact details. The team used them to build hype with leads.
MANAGERS
SONGWRITERS
Outcome
Shipped to beta, then the company pivoted
The designs were built and released to a TestFlight beta, and the promo videos went out to leads while the team prepped an investor pitch. Unfortunately, it didn't reach a public launch: the founder redirected the company toward enterprise clients and the legal-contract side of the product.
Reflection
The strongest move wasn't a screen, it was refusing to treat a sensitive, emotional negotiation as data entry, and going wide enough to earn a warmer solution. Owning an ambiguous 0→1 end-to-end also sharpened how I scope, build systems, and hand off to a team I can't just tap on the shoulder.
What I'd do differently: get closer to real users. I leaned on the founders' deep industry knowledge and one customer feedback session, but I'd fight to be a fly on the wall in customer calls and to pressure-test prototypes with actual creators. That feedback might have pushed us toward the higher-value contract experience sooner.